Comments 70
Многие советуют скрывать версию WordPress, но на самом деле её всегда можно определить по другим косвенным признакам. Вот старенькая статья на эту тему: codeseekah.com/2012/02/20/the-wordpress-meta-generator-tag-paranoia/.
Мне для настройки безопасности очень нравится плагин iThemes Security: wordpress.org/plugins/better-wp-security/
Мне для настройки безопасности очень нравится плагин iThemes Security: wordpress.org/plugins/better-wp-security/
Рекомендую присмотреться еще и к этому плагину — All In One WP Security & Firewall
Лучше не скрывать версии, а подменять на старые. Сразу же отфутболиваются малолетние кулц-хакеры. Не разобравшись почему 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, вместо двух веб-серверов, один из которых только из-за того, что он умеет PHP?
Это не формулирование по-другому, это другой вопрос.
php-fpm в качестве бекенда это очень хороший вариант, его легче настроить на производительность, не имея навыков администрирования.
Apache же более гибкий. Много нужного и часто лишнего их коробки.
В статье мы рассматривали Apache, потому что до сих пор часто ставится только он один. По этой же причине многие конфиги писались под Apache, хотя могли бы быть написаны под NGinx и тогда производительность была бы выше.
php-fpm в качестве бекенда это очень хороший вариант, его легче настроить на производительность, не имея навыков администрирования.
Apache же более гибкий. Много нужного и часто лишнего их коробки.
В статье мы рассматривали Apache, потому что до сих пор часто ставится только он один. По этой же причине многие конфиги писались под Apache, хотя могли бы быть написаны под NGinx и тогда производительность была бы выше.
Кажется я начинаю понимать. Вы имеете ввиду что сам по себе nginx не работает с PHP?
Ну да, не работает, но вы же сами указываете php-fpm в качестве обработчика PHP.
Вот меня и интересует вопрос, какой смысл устраивать связку nginx → apache → php-fpm, если ее можно сократить до nginx → php-fpm, при этом исключится любитель кушать память на каждый запрос apache.
Собственно, я и хотел узнать, может в связке nginx+apache+php-fpm, действительно, есть какой-то необходимый случай?
Ну да, не работает, но вы же сами указываете php-fpm в качестве обработчика PHP.
Вот меня и интересует вопрос, какой смысл устраивать связку nginx → apache → php-fpm, если ее можно сократить до nginx → php-fpm, при этом исключится любитель кушать память на каждый запрос apache.
Собственно, я и хотел узнать, может в связке nginx+apache+php-fpm, действительно, есть какой-то необходимый случай?
У Apache стандартно php-скрипты обрабатываются модулем mod_php и необходимости проксировать дальше на php-fpm нету.
Ну и касаемо WP+nginx.
Я хотел узнать в чем преимущество связки, а оказывается вон оно как.
Я хотел узнать в чем преимущество связки, а оказывается вон оно как.
Спасибо!
Очень полезно всё это иметь в одной статье.
Очень полезно всё это иметь в одной статье.
Вы пишите, что:
Но ведь 99% процентов обращений к БД в Вордпресс — это как раз селекты. Почему тогда лучше использовать InnoDB (с точки зрения производительности)?
MyISAM показывает хорошие результаты на выборках SELECT, что во многом обусловлено отсутствием поддержки транзакций и внешних ключей.
Но ведь 99% процентов обращений к БД в Вордпресс — это как раз селекты. Почему тогда лучше использовать InnoDB (с точки зрения производительности)?
Вообще Вордпресс создавая БД из коробки не использует никаких особенностей InnoDB. Поэтому Для Вордпресса, имхо, эффективнее MyISAM.
Т.е. если особенности InnoDB не используются, то MyISAM производительней?)
Нет. MyISAM в принципе производительней.
А если особенности InnoDB не испольщуются, то MyISAM — предпочтительней.
А если особенности InnoDB не испольщуются, то MyISAM — предпочтительней.
Ради интереса провел небольшой тест:
Померил выборки из MyISAM и InnoDB
2 секунды разницы на 1000 запросов. Т.е. MyISAM быстрее выполняет запрос на 0,002 секунды.
Если у вас такие объемы, что эта разница существенна, то вы не будете использовать MyISAM уже по соображениям надежности в Highload.
Померил выборки из 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.628s2 секунды разницы на 1000 запросов. Т.е. MyISAM быстрее выполняет запрос на 0,002 секунды.
Если у вас такие объемы, что эта разница существенна, то вы не будете использовать MyISAM уже по соображениям надежности в Highload.
99% это вы немножко загнули, 70-80%. Пишутся сессии и т.п.
Там была ссылка на тесты, где описаны варианты Read-only для MyISAM и InnoDB.
На шаред-хостиге, когда ваши данные из БД наверняка будут читаться с дисков, MyISAM может быть производительнее.
Там была ссылка на тесты, где описаны варианты Read-only для MyISAM и InnoDB.
На шаред-хостиге, когда ваши данные из БД наверняка будут читаться с дисков, MyISAM может быть производительнее.
99% это вы немножко загнули, 70-80%. Пишутся сессии и т.п.
Какие еще сессии и т.п.? Речь про БД Ворпресса в MySQL.
Вы не собираете статистику о поведении пользователей?
Скиньте свой «mysqladmin status», посмотрим соотношение чтения/записи.
Скиньте свой «mysqladmin status», посмотрим соотношение чтения/записи.
Собираю, конечно. В Google Analytics.
Я посмотрел на стандартном проекте соотношение чтение/записи — вы правы, извиняюсь. Почти 98%.
Однако InnoDB всё равно быстрее.
Можно, к примеру, посмотреть тест Oracle:
www.oracle.com/partners/en/knowledge-zone/mysql-5-5-innodb-myisam-522945.pdf
График RO — разница в 4,5 раза это очень много.
Однако InnoDB всё равно быстрее.
Можно, к примеру, посмотреть тест Oracle:
www.oracle.com/partners/en/knowledge-zone/mysql-5-5-innodb-myisam-522945.pdf
График RO — разница в 4,5 раза это очень много.
Я не специалист по MySql и не агитирую за MyISAM, т.к. до прочтения вашей статьи понятия не имел, чем он отличается от InnoDB. Но на основании вашего утверждения
я сделал предположение, что для Вордпресса имеет смысл использовать MyISAM.
Если «InnoDB всё равно быстрее», то это значит, что результаты InnoDB на выборках SELECT все равно лучше.
P.S. В тестах по вашей ссылке графики начинаются с шести процессорных ядер. Возможно, что на 1-2 ядрах MyISAM окажется быстрее.
MyISAM показывает хорошие результаты на выборках SELECT
я сделал предположение, что для Вордпресса имеет смысл использовать MyISAM.
Если «InnoDB всё равно быстрее», то это значит, что результаты InnoDB на выборках SELECT все равно лучше.
P.S. В тестах по вашей ссылке графики начинаются с шести процессорных ядер. Возможно, что на 1-2 ядрах MyISAM окажется быстрее.
Перестаньте путать людей. MyISAM/InnoDB — все зависит от конкретного проекта. Какую из таблиц в каком типе держать — зависит от каждого случая. От оъема данных, сложности архитектуры, собственно самих запросов. Блог или новостной портал, даже очень большой, будет использовать одни запросы. Интернет-магазин или каталог — другие. Появление запросов по meta_key, больших объединяющих запросов, сортировок по meta_value существенно изменит поведение, так как пойдет полнотекстовый поиск, вылезут узкие места с индексами. Если используются свои кастомные таблицы — отдельная история. Вот исходя из этого надо тестировать и выбирать наиболее подходящий тип для каждой конкретной таблицы. А для более-менее стандартного сетапа и среднестатистического сайта, коих большинство — нет никакой разницы. Так что эту рекоммендацию можно смело опустить.
UFO just landed and posted this here
Кстати, в MySQL/Percona Server 5.6+ полнотекстовый поиск для InnoDB уже поддерживается.
Не все готовы пользоваться MySQL 5.6
UFO just landed and posted this here
Плюсов много, согласен. Но сейчас 5.6 не является дефолтной версией в дистрибутивах ОС.
Очень многое переписано, от этого переход в дефолтную стабильную ветку не такой быстрый. Из опыта помню сам как повелся на mysql 5.5 и поставил его, а потом нарвался на баг и моя InnoDB-шная база покрашилась.
Очень многое переписано, от этого переход в дефолтную стабильную ветку не такой быстрый. Из опыта помню сам как повелся на mysql 5.5 и поставил его, а потом нарвался на баг и моя InnoDB-шная база покрашилась.
UFO just landed and posted this here
Посмотрите на ChangeLog и на длинные полотна под заголовком «Bugs Fixed»:
dev.mysql.com/doc/relnotes/mysql/5.6/en/
dev.mysql.com/doc/relnotes/mysql/5.6/en/
Данные в InnoDB/XtraDB кэшируются. Когда большая часть данных считывается из кэша, производительность InnoDB/XtraDB в разы выше, чем у MyISAM.
И у MyISAM кэшеруются, просто на уровне системы.
И почему вдруг отключение KeepAlive повысит производительность?
Скорее снизит расходы памяти и создаст лишние тормоза для клиента.
1) ОС кеширует не данные MyISAM, а страницы на уровне бинарников (Page Cache) и метаданные этих бинарников. Они же оттуда очень легко вымещаются.
2) www.opennet.ru/base/dev/keepalive_apache.txt.html
2) www.opennet.ru/base/dev/keepalive_apache.txt.html
Удивительно, но мне казалось что все эти действия многим очевидны. Оказалось нет.
Ничего нового не узнал, но все равно спасибо
Ничего нового не узнал, но все равно спасибо
Ещё следует добавить установку/активацию php-акселяторов типа opcache и xdebug.
А также специальные wordpress плагины типа WP Super Cache и W3 Total Cache.
А также специальные wordpress плагины типа WP Super Cache и W3 Total Cache.
Вы забыли упомянуть, что 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 под нагрузкой: масштабирование и отказоустойчивость :)
Связка 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/
Ах, ну и раз уж вы эту статью написали для того, чтобы в конце вставить:
Почитайте, что предлагают в услуге «Управляемый хостинг» буржуи rtcamp.com/wordpress-nginx/managed-hosting/, ценник там конечно другой немного, но думаю что будет интересно.
И как уже писалось, плагин 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 интересная, спасибо.
Это же написано в статье, читайте внимательнее.
> iThemes Security решает большую половину проблем с безопасностью
«Я закрыл половину дыр в безопасности, теперь всё ок».
Советы давались исходя из того как часто встречаются такие проблемы, а не для админов senior-уровня.
> почему ничего не написано про Wordpress+Nginx+Fast_CGI_Cache
Еще не написано про squid и varnish, про CDN, рассылку новостей по миллионам подписчиков и многое другое.
Ссылка на managed-hosting интересная, спасибо.
С большинством согласен, спасибо за комментарий.
Про размер InnoDB намеренно не говорил. БД редко бывают размеров больше 100G (в InnoDB), чтобы это стало существенно. Тем более в блогах. Даже если вы выделяете под MySQL отдельную дисковую подсистему из SSD дисков, их хватит в большинстве случаев за глаза и за уши.
Использовать же на таких объемах MyISAM без гарантий консистентности и с блокировками на полные таблицы как-то странно.
Размер бинарников может быть существенен, когда речь идет о резервном копировании. Вроде как чем меньше бинарников, тем быстрее все скопируется. Но здесь стоит упомянуть, что у MyISAM нет нормального механизма резервного копирования. Хотя это можно попробовать обойти через снапшоты — надо лочить всю базу на запись, сбросить кеш, создать снапшот и разлочить. Но у InnoDB можно без блокировок создать косистентный дамп.
Про размер 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) — это объем, потому я и затронул эту тему в моем предыдущем комментарии.
> БД редко бывают размеров больше 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, блокируется вся таблица на запись и на обновление.
Когда идет запись, ставится блокировка на чтение всей таблицы (в 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. Запишите видео доклада, я бы послушал.
Обязательно.
> Когда идет запись, ставится блокировка на чтение всей таблицы
Вы правы, только это происходит не всегда, см. 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 девайсах. :)
> Мультисайт: 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 :)
> поставил бы рейд из SAS-дисков или даже SATA в несколько Тб. Всё равно ведь используются реплики.
Так репликам ж тоже с дисков читать надо.
> не увидел там причины того, что базы под WP должны занимать 100G+. :((
Суть в том, что в режиме мультисайт вы можете поднять неограниченное количество сайтов под одной установкой ядра и БД WordPress. Если база одного сайта будет весить 1ГБ, достаточно лишь 100 таких сайтов, чтобы превысить ваш лимит.
Иными словами — сеть блогов любого университета, не говоря уже о крупных проектах как edublogs.org, happytables.com и т.д.
> Вот мы и пошли в сторону MyISAM :)
Ненене :) Мы решили, что надо базу уменьшать, а не бинарники) Кстати, там на больших объемах разница в размере далеко не в 4 раза.
> Так репликам ж тоже с дисков читать надо
Не увидел проблемы.
> Если база одного сайта будет весить 1ГБ, достаточно лишь 100 таких сайтов, чтобы превысить ваш лимит
В базу в 1Гб можно поверить, но в 100 таких проектов на одном сервере (с зеркалированием/реплицированием и т.п.) нет. Я достаточно проработал админом в одном из лучших шаред-хостеров России, чтобы утверждать, что вы скорее упретесь поочереди во все другие ресурсы, чем в размер дисков под базы.
Если будете оверселить ресурсы, то всё будет жутко тормозить и лагать, т.е. клиенты такого размера как вы описываете, просто свалят. Если не будете оверселить ресурсы, то на один сервер ну клиентов 20 влезет и то, базы у больше части не будут такие здоровые.
Если у вас базы уже дошли до 100G+ и вы используете 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 потребляет в несколько раз больше места на диске, лучше все-таки держать в голове.
Здесь речь идет не о шаред-хостинге :) WordPress.com это сервис на основе WordPress мультисайт, который развернут на более тысячи серверов в 6 дата-центрах на 3-х континентах. БД шардится на более 600 серверов MySQL, на каждый из которых приходится в среднем по ~ 400 запросов в секунду. Можете представить какой у нас объем.
Это конечно самый крупный публичный проект на WordPress, поэтому его можно назвать крайним случаем, и здесь вполне оправдан выбор MyISAM, несмотря на то, что InnoDB был бы эффективнее.
Тем не менее, возьмите типичный американский университет, где студентам и преподавателям предоставляется возможность создать сайт и вести свой блог. Такого объема как у WordPress.com у них в сети никогда не будет, но поверьте, 100 ГБ они быстро наберут, особенно если добавить элементы соц. сети, например с помощью BuddyPress.
В общем я не говорю, что нужно использовать MyISAM. Все знают, что у InnoDB будущее куда светлее, чем даже у MariaDB. Но тот факт, что InnoDB потребляет в несколько раз больше места на диске, лучше все-таки держать в голове.
UFO just landed and posted this here
> Спасибо автору, но после «Ubuntu 12.04» советы по оптимизации и безопасности — не воспринимаются серьезно.
Обоснуйте, пожалуйста.
Мы-то как раз не используем NGinx+Apache, у нас php-fpm стоит и CDN и много чего еще, но это другая история. Статья написана для клиентов, а Apache более универсальный. Иногда костыль удобней.
Обоснуйте, пожалуйста.
Мы-то как раз не используем NGinx+Apache, у нас php-fpm стоит и CDN и много чего еще, но это другая история. Статья написана для клиентов, а Apache более универсальный. Иногда костыль удобней.
А зачем выключать кипалайв?
Все говорят о том, что ngnix с php-fpm лучше Apache с mod_php, но почему?
Sign up to leave a comment.
Проекты на WordPress: советы по оптимизации