Комментарии 70
Многие советуют скрывать версию WordPress, но на самом деле её всегда можно определить по другим косвенным признакам. Вот старенькая статья на эту тему: codeseekah.com/2012/02/20/the-wordpress-meta-generator-tag-paranoia/.

Мне для настройки безопасности очень нравится плагин iThemes Security: wordpress.org/plugins/better-wp-security/
А можете кратенько пояснить какие у него плюсы по сравнению с iThemes Security?
Лучше не скрывать версии, а подменять на старые. Сразу же отфутболиваются малолетние кулц-хакеры. Не разобравшись почему 2-х летняя xss не сработала, они обычно просто уходят.
>> Выбираем движок: MyISAM или InnoDB?
Прекратите насиловать труп!
Ребята, Вы даже не представляете на сколько Вы в тему с этим постом. Спасибо!
Подскажите, а почему бы не использовать один nginx, без apache вообще?
NGinx не работает с PHP, т.е. бекенд (Apache/php-fpm) для выполнения php-скриптов нужен будет в любом случае.
Забавно, что даже название статьи по ссылке «FastCGI Example (with PHP FPM)».
Это как-то противоречит моим словам?)
Ну либо я чего-то не понимаю, объясните, что именно подразумевается под «работой с PHP»?
nginx не умеет сам интерпретировать скрипты, написанные на php, что тут непонятного?:)
А если сформулировать по-другому.
Почему бы не использовать один веб-сервер в связке с PHP FPM, вместо двух веб-серверов, один из которых только из-за того, что он умеет PHP?
Это не формулирование по-другому, это другой вопрос.

php-fpm в качестве бекенда это очень хороший вариант, его легче настроить на производительность, не имея навыков администрирования.
Apache же более гибкий. Много нужного и часто лишнего их коробки.

В статье мы рассматривали Apache, потому что до сих пор часто ставится только он один. По этой же причине многие конфиги писались под Apache, хотя могли бы быть написаны под NGinx и тогда производительность была бы выше.
Кажется я начинаю понимать. Вы имеете ввиду что сам по себе nginx не работает с PHP?

Ну да, не работает, но вы же сами указываете php-fpm в качестве обработчика PHP.

Вот меня и интересует вопрос, какой смысл устраивать связку nginx → apache → php-fpm, если ее можно сократить до nginx → php-fpm, при этом исключится любитель кушать память на каждый запрос apache.

Собственно, я и хотел узнать, может в связке nginx+apache+php-fpm, действительно, есть какой-то необходимый случай?
У Apache стандартно php-скрипты обрабатываются модулем mod_php и необходимости проксировать дальше на php-fpm нету.

Речь шла не об этом, но вы уже изменили и статью. Ясно. Спасибо. Останемся каждый при своем мнении.

А по поводу вышесказанного, знаю что связка WP+WP Super Cache+nginx+php-fpm, будет работать, где apache уже ляжет напрочь. Тестировал лично.
В статье пока мы поменяли только опечатку с mysqlhunter.pl на mysqltuner.pl. ;)

Выше есть предупреждение о холиварах php-fpm/Apache.
Ну и касаемо WP+nginx.
Я хотел узнать в чем преимущество связки, а оказывается вон оно как.
Вы пишите, что:
MyISAM показывает хорошие результаты на выборках SELECT, что во многом обусловлено отсутствием поддержки транзакций и внешних ключей.


Но ведь 99% процентов обращений к БД в Вордпресс — это как раз селекты. Почему тогда лучше использовать InnoDB (с точки зрения производительности)?
Вообще Вордпресс создавая БД из коробки не использует никаких особенностей InnoDB. Поэтому Для Вордпресса, имхо, эффективнее MyISAM.
Т.е. если особенности InnoDB не используются, то MyISAM производительней?)
Нет. MyISAM в принципе производительней.
А если особенности InnoDB не испольщуются, то MyISAM — предпочтительней.
Ради интереса провел небольшой тест:
Померил выборки из MyISAM и InnoDB
root@blog:/home/www# time for i in {1..1000}; do mysql wordpress -e "SELECT * FROM wp_options" >/dev/null; done

real	0m14.314s
user	0m10.729s
sys	0m2.060s
root@blog:/home/www# free -m
             total       used       free     shared    buffers     cached
Mem:          2012       1378        634          0        164        464
-/+ buffers/cache:        749       1263
Swap:            0          0          0
root@blog:/home/www# for n in `mysql wordpress -B -N -e "show tables;"`;do mysql wordpress -B -N -e "ALTER TABLE $n ENGINE=InnoDB;";done
root@blog:/home/www# time for i in {1..1000}; do mysql wordpress -e "SELECT * FROM wp_options" >/dev/null; done

real	0m16.113s
user	0m12.037s
sys	0m2.628s


2 секунды разницы на 1000 запросов. Т.е. MyISAM быстрее выполняет запрос на  0,002 секунды.
Если у вас такие объемы, что эта разница существенна, то вы не будете использовать MyISAM уже по соображениям надежности в Highload.
Вообще-то для показа одной страницы Вордпресс может выполнять десятки запросов к БД, так что 2 секунды на 1000 запросов это совсем не мало.
К тому же «SELECT * FROM таблица» — это совсем непоказательный пример, странно что вообще получилась разница.
99% это вы немножко загнули, 70-80%. Пишутся сессии и т.п.
Там была ссылка на тесты, где описаны варианты Read-only для MyISAM и InnoDB.
На шаред-хостиге, когда ваши данные из БД наверняка будут читаться с дисков, MyISAM может быть производительнее.
99% это вы немножко загнули, 70-80%. Пишутся сессии и т.п.


Какие еще сессии и т.п.? Речь про БД Ворпресса в MySQL.
Вы не собираете статистику о поведении пользователей?
Скиньте свой «mysqladmin status», посмотрим соотношение чтения/записи.
Я посмотрел на стандартном проекте соотношение чтение/записи — вы правы, извиняюсь. Почти 98%.
Однако InnoDB всё равно быстрее.
Можно, к примеру, посмотреть тест Oracle:
www.oracle.com/partners/en/knowledge-zone/mysql-5-5-innodb-myisam-522945.pdf
График RO — разница в 4,5 раза это очень много.
Я не специалист по MySql и не агитирую за MyISAM, т.к. до прочтения вашей статьи понятия не имел, чем он отличается от InnoDB. Но на основании вашего утверждения

MyISAM показывает хорошие результаты на выборках SELECT

я сделал предположение, что для Вордпресса имеет смысл использовать MyISAM.

Если «InnoDB всё равно быстрее», то это значит, что результаты InnoDB на выборках SELECT все равно лучше.

P.S. В тестах по вашей ссылке графики начинаются с шести процессорных ядер. Возможно, что на 1-2 ядрах MyISAM окажется быстрее.
Перестаньте путать людей. MyISAM/InnoDB — все зависит от конкретного проекта. Какую из таблиц в каком типе держать — зависит от каждого случая. От оъема данных, сложности архитектуры, собственно самих запросов. Блог или новостной портал, даже очень большой, будет использовать одни запросы. Интернет-магазин или каталог — другие. Появление запросов по meta_key, больших объединяющих запросов, сортировок по meta_value существенно изменит поведение, так как пойдет полнотекстовый поиск, вылезут узкие места с индексами. Если используются свои кастомные таблицы — отдельная история. Вот исходя из этого надо тестировать и выбирать наиболее подходящий тип для каждой конкретной таблицы. А для более-менее стандартного сетапа и среднестатистического сайта, коих большинство — нет никакой разницы. Так что эту рекоммендацию можно смело опустить.
Часто вы так тестируете? Поделитесь статистикой какой движек когда используете. Или расскажите в каких случаях что использовать. Какой смысл говорить, что всё меняется от случая к случаю и лучше тестировать? Это и так очевидно.
> MyISAM нужно выбирать только в случаях, когда нужен полнотекстовый поиск. Со всеми остальными задачами прекрасно справятся InnoDB

А почему не пользоваться полнотекстовым поиском в InnoDB? Больше года как доступен.
Кстати, в MySQL/Percona Server 5.6+ полнотекстовый поиск для InnoDB уже поддерживается.

Не все готовы пользоваться MySQL 5.6
И какие будут причины его не использовать? Стабильность на высоте, новые фишки прямо-таки говорят «юзай нас».
Плюсов много, согласен. Но сейчас 5.6 не является дефолтной версией в дистрибутивах ОС.
Очень многое переписано, от этого переход в дефолтную стабильную ветку не такой быстрый. Из опыта помню сам как повелся на mysql 5.5 и поставил его, а потом нарвался на баг и моя InnoDB-шная база покрашилась.
А какая разница, какая версия в дистрибутиве? В чем проблема обновить дистрибутив или поставить альтернативный источник?
Что касается стабильности, то 5.6 давно проверенная и стабильная версия.
Из 5.5 в 5.6 перешли баги, но не наоборот.

В 5.6 их в два раза больше, хотя и в 5.5 много.
Приводите конкретные баги, мешающие вам жить, а не список всего-всего.
Данные в InnoDB/XtraDB кэшируются. Когда большая часть данных считывается из кэша, производительность InnoDB/XtraDB в разы выше, чем у MyISAM.

И у MyISAM кэшеруются, просто на уровне системы.

И почему вдруг отключение KeepAlive повысит производительность?
Скорее снизит расходы памяти и создаст лишние тормоза для клиента.
Удивительно, но мне казалось что все эти действия многим очевидны. Оказалось нет.
Ничего нового не узнал, но все равно спасибо
Ещё следует добавить установку/активацию php-акселяторов типа opcache и xdebug.
А также специальные wordpress плагины типа WP Super Cache и W3 Total Cache.
С каких пор xdebug является accelerator'ом? Вы его случаем с APC не путаете?
Думаю, что речь шла о XCache, просто опечатался человек в пятницу вечером)
Вы забыли упомянуть, что InnoDB потребляет раза в 4 больше пространства на жестком диске, и при большом объеме данных (раз уж речь идет о крупных и высоко-нагруженных проектах), это не всегда может быть оправдано.

Связка Apache + nginx используется в основном только тогда, когда клиентам хостинга необходимо предоставить доступ к файлу .htaccess, во всех остальных случаях nginx + php-fpm уже давно стал стандартом для WordPress.

> В новых версиях Wordpress появилась возможность выбора префикса при установке.

Ну да, в новых… Лет так 11 назад ;) core.trac.wordpress.org/changeset/664/

> Переместите файл wp-config.php.

Это делается далеко не из соображений безопасности, а только потому, что так работать удобнее если директория с ядром WordPress подтягивается и обновляется с помощью системы контроля версий, например Subversion или Git. Получается, что в самой директории ничего никогда не меняется, а меняется лишь wp-config.php и wp-content, которые оба могут находится за пределами директории ядра.

> Ключи используются для хэширования паролей

Ключи не используются для хэширования паролей, иначе при смене ключа у вас бы ни один старый пароль не подошел. Ключи используются для генерации куки аутентификации, и «одноразовых» чисел (nonce) в WordPress. Менять эти ключи можно когда угодно, при смене всех вошедших пользователей лишь «выбросит» из админки и им придется войти повторно. Более того, это хороший метод защиты, когда у вас например украли куки браузера.

> Удалите информацию о версии Wordpress

Как уже кто-то отметил в комментариях — это глупость. Версию ядра WordPress можно легко узнать из версий внешних библиотек, например jQuery, TinyMCE. Лучше не прятать версию а вовремя обновляться и использовать надежный пароль, возможно 2-уровневую аутентификацию. А наличие тега rel=generator помогает лишь сбору статистики.

Ботам, которые брутфорсят пароли от WordPress, или ищут уязвимости в темах использующие старый TimThumb совершенно не важно какая у вас версия ядра. Им даже не важно стоит ли у вас WordPress :) Есть ответ по 80-му порту — будут бомбить.

> Ограничьте доступ к папкам wp-content и wp-includes.

Может быть wp-content, но не wp-includes, там есть некоторые .php файлы, к которым необходим прямой доступ, например wp-includes/js/tinymce/wp-mce-help.php. Не исключено, что в новых версиях появятся и другие.

> Ограничьте доступ к папке wp-admin.

Тоже не совсем просто. В этой директории есть некоторые файлы, которые исполняются с фронтенда без необходимости авторизации пользователей в WordPress, например любые темы или плагины, которые используют AJAX в WordPress проходят через wp-admin/admin-ajax.php.

P.S. Если кому-то интересна тема высокой посещаемости и WordPress, крайне рекомендую: WordPress под нагрузкой: масштабирование и отказоустойчивость :)
Спасибо, Константин. Очень многое прояснили, особенно про «wp-admin» видно что человек который писал статью, написал немного из своего опыта, а потом просто передрал то, чего уже написано огромное множество, не опробовав советы самостоятельно.

И как уже писалось, плагин iThemes Security решает большую половину проблем с безопасностью WP, особо не напрягая при этом конечного пользователя.

Также совет «Создайте пустой файл wp-content/plugins/index.html» тоже бестолковый, если он для пользователей которые не ковыряют конфиг сервера, тогда предыдущие по оптимизации явно не для них, а если он для админов, то лучше посоветовать закрыть просмотр директорий на сервере, чтобы не пришлось таких еще пустых файлов создавать по всем папкам плагинов :)

Опять же, не ковыряя сервер и не изменяя СУБД можно получить неплохой прирост используя например:

WP+Hyper-Cache

НУ и если углубляться, почему ничего не написано про Wordpress+Nginx+Fast_CGI_Cache? Очень толковый мануал вот здесь: rtcamp.com/wordpress-nginx/tutorials/single-site/fastcgi-cache-with-purging/

Ах, ну и раз уж вы эту статью написали для того, чтобы в конце вставить:

Со своей стороны мы всегда готовы оказать помощь по настройке и оптимизации сложных проектов на Wordpress в рамках нашего нового пакета услуг по администрированию серверов.


Почитайте, что предлагают в услуге «Управляемый хостинг» буржуи rtcamp.com/wordpress-nginx/managed-hosting/, ценник там конечно другой немного, но думаю что будет интересно.
> посоветовать закрыть просмотр директорий на сервере, чтобы не пришлось таких еще пустых файлов создавать по всем папкам плагинов
Это же написано в статье, читайте внимательнее.

> iThemes Security решает большую половину проблем с безопасностью
«Я закрыл половину дыр в безопасности, теперь всё ок».
Советы давались исходя из того как часто встречаются такие проблемы, а не для админов senior-уровня.

> почему ничего не написано про Wordpress+Nginx+Fast_CGI_Cache
Еще не написано про squid и varnish, про CDN, рассылку новостей по миллионам подписчиков и многое другое.

Ссылка на managed-hosting интересная, спасибо.
С большинством согласен, спасибо за комментарий.

Про размер InnoDB намеренно не говорил. БД редко бывают размеров больше 100G (в InnoDB), чтобы это стало существенно. Тем более в блогах. Даже если вы выделяете под MySQL отдельную дисковую подсистему из SSD дисков, их хватит в большинстве случаев за глаза и за уши.
Использовать же на таких объемах MyISAM без гарантий консистентности и с блокировками на полные таблицы как-то странно.

Размер бинарников может быть существенен, когда речь идет о резервном копировании. Вроде как чем меньше бинарников, тем быстрее все скопируется. Но здесь стоит упомянуть, что у MyISAM нет нормального механизма резервного копирования. Хотя это можно попробовать обойти через снапшоты — надо лочить всю базу на запись, сбросить кеш, создать снапшот и разлочить. Но у InnoDB можно без блокировок создать косистентный дамп.
Спасибо за ответ!

> БД редко бывают размеров больше 100G (в InnoDB), чтобы это стало существенно. Тем более в блогах.

О блогах это вы зря :) Именно в блогах и СМИ авторы публикуют по 200 записей в день, причем по 40 редакций и десяток внедренных объектов oEmbed в каждой, а уж если вы поддерживаете, скажем сеть сайтов в режиме multisite, то «отдельной дисковой подсистемой» можно и не обойтись, и прирост объема в 4 раза может хорошо сказаться на стоимости поддержки, именно поэтому WordPress.com до сих пор крутится на MyISAM.

> Использовать же на таких объемах MyISAM без гарантий консистентности и с блокировками на полные таблицы как-то странно.

Это совершенно не странно, во-первых потому, что несмотря на наличие транзакций и откатов в InnoDB, ядро WordPress ими не пользуется, ровно так же как и внешними ключами, которые вообще практически весь смысл теряют, как только мы переходим на шардинг данных.

Во-вторых, блокировка таблиц влияет только на запись, а для большинства крупных и высоко-посещаемых проектов на WordPress соотношение чтения к записи слишком велико, чтобы об этом даже думать, потому и сложно например встретить репликацию master-master с WordPress, несмотря на то, что такая репликация хорошо поддерживается тем же XtraDB Cluster.

> Но здесь стоит упомянуть, что у MyISAM нет нормального механизма резервного копирования. Хотя это можно попробовать обойти через снапшоты — надо лочить всю базу на запись

Если говорить о резервном копировании при таком объеме данных, то скорее это делается все на реплике на отдельном сервере, поэтому тип блокировки и наличие транзакций никакого влияния не окажет.

Во время резервной копии реплику можно вывести из продакшн, тогда на работоспособность сайта это никак не повлияет, или же просто остановить репликацию на время копирования, тогда будет небольшой лаг, что для большинства проектов совершенно не критично и не заметно.

Плюс, как вы сами отметили в статье, MyISAM позволяет скопировать базу данных на уровне файловой системы, что гораздо быстрее, чем любой mysqldump.

И все же, InnoDB это круто :) и главная причина по которой WordPress.com до сих пор работает на MyISAM (и частично на MariaDB) — это объем, потому я и затронул эту тему в моем предыдущем комментарии.
1) > Во-вторых, блокировка таблиц влияет только на запись...
Это не так и это очень важный момент.
Когда идет SELECT, блокируется вся таблица на запись и на обновление.
Когда идет запись, ставится блокировка на чтение всей таблицы (в MyISAM таблица — минимальная еденица блокировки). А это жуткие проседания времени ответа при обновлении данных или добавлении новых постов. Вы приводите пример с огромным ресурсом, где данные переваливают за 100G, значит записи в базу идут с достаточно высокой скоростью. И тогда варианта два — или изменяемые таблицы постоянно недоступны для чтения или часто изменяемые данные (как например таблица с коментами) переводится в InnoDB. Если таблицу с коментами на таком ресурсе не перевести в InnoDB, то будут большие задержки на сайте и попросту будет забиваться очередь запросов в MySQL. Если забьется очередь, то сляжет всё.
Если допустить, что мы таблицу с коментами перевели в InnoDB, т.к. в неё идет много записей, то стоит вспомнить, что у таблицы с постами есть поле comment_count, которое обновляется при каждом добавлении или удалении комента. И не только оно постоянно обновляется, но и to_ping и pinged.
Т.е. локи идут и на таблицу с постами.
Интересно у вас, как у Wordpress core-developer-а узнать, что вы с этим делаете в MyISAM.

2) Всё таки я не понимаю, что может занимать такие размеры (100G+) в БД. Медиафайлы же хранятся не в базе.

3) > Если говорить о резервном копировании при таком объеме данных, то скорее это делается все на реплике на отдельном сервере, поэтому тип блокировки и наличие транзакций никакого влияния не окажет.
Если вы пишете бинлог, то из MyISAM никаких увеличений скорости вы не выжмете.

4) > Плюс, как вы сами отметили в статье, MyISAM позволяет скопировать базу данных на уровне файловой системы, что гораздо быстрее, чем любой mysqldump.
Прочитали? А теперь забудьте про этот метод бекапа)
Если вы так бекапитесь, что у вас почти 100% будут недописанные данные. А я напомню как MyISAM восстанавливает поврежденные данные — он их просто удаляет.
Вот так вы обновляли значение количества комментариев под постом, а в результате пропал весь пост.

P.S: вы скинули ссылку на конференцию, где вы будуте рассказывать про масштабирование WordPress. Запишите видео доклада, я бы послушал.
> Когда идет SELECT, блокируется вся таблица на запись и на обновление.
> Когда идет запись, ставится блокировка на чтение всей таблицы

Вы правы, только это происходит не всегда, см. dev.mysql.com/doc/refman/5.0/en/concurrent-inserts.html

Но дело даже не в этом. Когда слейв читает с мастера, он группирует запросы на изменение таблиц последовательно, поэтому на реплике они выполняются гораздо быстрее, чем на мастере. При этом на крайний случай всегда есть --low-priority-updates или возможность приостановить слейв на время. Опять же, самое худшее, что мы можем получить из этой ситуации это лаг.

> Всё таки я не понимаю, что может занимать такие размеры (100G+) в БД. Медиафайлы же хранятся не в базе.

Мультисайт: wpmag.ru/2014/wordpress-multisite/

> Если вы так бекапитесь, что у вас почти 100% будут недописанные данные.

Мы так не бэкапимся :) тем не менее: STOP SLAVE; FLUSH TABLES;

> P.S: вы скинули ссылку на конференцию, где вы будуте рассказывать про масштабирование WordPress. Запишите видео доклада, я бы послушал.

Обязательно.
По первой части — я бы посмотрел решение проблем с блокировками более детально, думаю это уже не совсем стандартный WP. Так навскидку не вижу возможности играться с приоритетностью без потерь. Я бы, честно, пошел в сторону уменьшения размера БД или (если надо подешевле) поставил бы рейд из SAS-дисков или даже SATA в несколько Тб. Всё равно ведь используются реплики.

> Мультисайт: wpmag.ru/2014/wordpress-multisite/
Простите, может я что-то проглядел, но не увидел там причины того, что базы под WP должны занимать 100G+. :((

> Мы так не бэкапимся :) тем не менее: STOP SLAVE; FLUSH TABLES;
Могу дополнить — если выводите реплику и с неё бекапите, то нужно еще засинкать логи и перемонтировать раздел в RO (обычного sync после флаша таблиц недостаточно, хотя уже лучше). MySQL 5.6 умеет подниматься на RO девайсах. :)
> Я бы, честно, пошел в сторону уменьшения размера БД

Вот мы и пошли в сторону MyISAM :)

> поставил бы рейд из SAS-дисков или даже SATA в несколько Тб. Всё равно ведь используются реплики.

Так репликам ж тоже с дисков читать надо.

> не увидел там причины того, что базы под WP должны занимать 100G+. :((

Суть в том, что в режиме мультисайт вы можете поднять неограниченное количество сайтов под одной установкой ядра и БД WordPress. Если база одного сайта будет весить 1ГБ, достаточно лишь 100 таких сайтов, чтобы превысить ваш лимит.

Иными словами — сеть блогов любого университета, не говоря уже о крупных проектах как edublogs.org, happytables.com и т.д.
> Вот мы и пошли в сторону MyISAM :)
Ненене :) Мы решили, что надо базу уменьшать, а не бинарники) Кстати, там на больших объемах разница в размере далеко не в 4 раза.

> Так репликам ж тоже с дисков читать надо
Не увидел проблемы.

> Если база одного сайта будет весить 1ГБ, достаточно лишь 100 таких сайтов, чтобы превысить ваш лимит
В базу в 1Гб можно поверить, но в 100 таких проектов на одном сервере (с зеркалированием/реплицированием и т.п.) нет. Я достаточно проработал админом в одном из лучших шаред-хостеров России, чтобы утверждать, что вы скорее упретесь поочереди во все другие ресурсы, чем в размер дисков под базы.
Если будете оверселить ресурсы, то всё будет жутко тормозить и лагать, т.е. клиенты такого размера как вы описываете, просто свалят. Если не будете оверселить ресурсы, то на один сервер ну клиентов 20 влезет и то, базы у больше части не будут такие здоровые.
Если у вас базы уже дошли до 100G+ и вы используете MyISAM для экономии места, то это архитектурная проблема, которая всё равно вылезет потом.
> Если будете оверселить ресурсы, то всё будет жутко тормозить и лагать, т.е. клиенты такого размера как вы описываете, просто свалят.

Здесь речь идет не о шаред-хостинге :) WordPress.com это сервис на основе WordPress мультисайт, который развернут на более тысячи серверов в 6 дата-центрах на 3-х континентах. БД шардится на более 600 серверов MySQL, на каждый из которых приходится в среднем по ~ 400 запросов в секунду. Можете представить какой у нас объем.

Это конечно самый крупный публичный проект на WordPress, поэтому его можно назвать крайним случаем, и здесь вполне оправдан выбор MyISAM, несмотря на то, что InnoDB был бы эффективнее.

Тем не менее, возьмите типичный американский университет, где студентам и преподавателям предоставляется возможность создать сайт и вести свой блог. Такого объема как у WordPress.com у них в сети никогда не будет, но поверьте, 100 ГБ они быстро наберут, особенно если добавить элементы соц. сети, например с помощью BuddyPress.

В общем я не говорю, что нужно использовать MyISAM. Все знают, что у InnoDB будущее куда светлее, чем даже у MariaDB. Но тот факт, что InnoDB потребляет в несколько раз больше места на диске, лучше все-таки держать в голове.
НЛО прилетело и опубликовало эту надпись здесь
> Спасибо автору, но после «Ubuntu 12.04» советы по оптимизации и безопасности — не воспринимаются серьезно.
Обоснуйте, пожалуйста.

Мы-то как раз не используем NGinx+Apache, у нас php-fpm стоит и CDN и много чего еще, но это другая история. Статья написана для клиентов, а Apache более универсальный. Иногда костыль удобней.
НЛО прилетело и опубликовало эту надпись здесь
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

11 сентября 2007 г.

Местоположение

Россия

Сайт

selectel.ru

Численность

201–500 человек

Дата регистрации

15 марта 2010