Очень тормозит WordPress (900чел/сутки)

Фабула: есть сайт www.boardgamer.ru, установлен WordPress 2.8.3, посещаемость – около 900 человек/сутки.

В последнее время сайт очень сильно грузит сервер. И это при том, что плагинов установлено минимум.

В связи с этим несколько вопросов:

1) Может ли wodpress нормально работать на сайте с посещаемостью около 1000 человек в сутки? Какой для этого нужен сервер?

2) Может быть стоит переехать на другой движок? Посоветуйте на какой?

3) Если нагрузка 1000 человек/сутки для WP – нормальная, может быть дело в каком-нибудь плагине или ситуацию можно поправить как-нибудь ещё?

могу только поделиться таким же "горем":

Есть VDS на FirstVDS. На сервер привязано около 10 доменов, на 7 из них просто залиты HTML заглушки. три из них используются. на всех трех стоит WordPress. обозначим их так:
psp – примерно 300 посетителей, 450-550 просмотров в сутки.
music – примерно 500 посетителей, 1450-4600 просмотров в сутки.
wp – примерно 50 посетителей, 100-150 просмотров в сутки.

Вот так я с ними жил себе спокойно на "VDS-Разгон" почти чуть больше год. В один момент началась твориться какая-то дичайшая котовасия – сайты перестали открываться и корректно работать, в ISPmanager невозможно было войти. Замечу, что никаких модификаций или апдейта WordPress в это время не производилось, а трафик заметно не вырастал.

После продолжительной переписки с саппортом выяснил, что они ничего мне подробного сказать не могут, кроме того, что неожиданно(!?!) выросло потребление памяти. начали общаться:
1. сначала ссылались на индексацию сайтов поисковиками,
2. после того, как я отказался принять эту версию (поисковики не могут мучать сайт на протяжении 4 часов), сказали, что виноват сторонний форум, посылающий большое количество запросов к картинкам на моем сайта. посмотрев логи, я понял, что это форум, на котором я зарегистрирован и там у меня в подписи стояла картинка с сайта. картинку я удалил, но нагрузка никуда не пропала, да и не могла пропасть, так как нагрузка была на память.

В итоге, посоветовавшись с саппортом, я просто решил взять другой тарифный план, выбрав "VDS-Улёт", который в два раза дороже того, что был у меня.. выбрал, переключился. сайты поработали исправно около 10 минут и началось все также – проблемы при просмотре, невозможно просмотреть через браузер, зайти в админку WordPress и так далее.

от саппорта я получил ответ, что мне не хватает еще 326 мб(!). откуда WordPress мог сожрать памяти на 500 мб??? 160 тарифной + 326 нехватка. откуда? это же не крупные порталы, а всего-лишь блоги с небольшой посещаемостью, прошу заметить. Проблему я так и не разрешил, сейчас ищу другого хостера.

Фабула: есть сайт www.boardgamer.ru, установлен WordPress 2.8.3, посещаемость - около 900 человек/сутки.

В последнее время сайт очень сильно грузит сервер. И это при том, что плагинов установлено минимум.

В связи с этим несколько вопросов:

1) Может ли wodpress нормально работать на сайте с посещаемостью около 1000 человек в сутки? Какой для этого нужен сервер?

2) Может быть стоит переехать на другой движок? Посоветуйте на какой?

3) Если нагрузка 1000 человек/сутки для WP - нормальная, может быть дело в каком-нибудь плагине или ситуацию можно поправить как-нибудь ещё?

1. Может у меня в лучшие времена было свыше 1300 хостов в сутки. Все зависит от хостера. Мой не подвел. Правда тогда и версия была у меня 2.3.3, но это огромной роли не играет.

2.Попробуйте, их сейчас масса, но сомневаюсь что найдете лучше.

3. Да это нормально, у меня было и больше. Вариант сменить хостера или тарифный план. На моем к примеру, одновременно на сайте могут быть (в единицу времени) не более 50 человек, но это не сильно повлияло на посещаемость. Кстати одновременное количество пользователей на сайте гораздо важнее чем за сутки, для хостера. Меньше плагинов, меньше нагрузка, WP ресурсоемкий движок. Отменить ревизию, поиск обновлений и т.д это грузит WP, например у меня после отключения плагина Anti XSS атак, сайт стал работать значительно быстрее.

вообще-то играет, 2.3.3 в плане нагрузки был куда лучше последних версий.

слабое место WP это база данных. сам WP может и 10к посетителей в день держать даже близко не напрягаясь, но вот если базе данных не хватает ресурсов – блог будет сильно тормозить.
первым делом добавьте у себя в файл footer.php строчки:

<small><?php printf(__(‘%d / %s’), get_num_queries(), timer_stop(0, 3)); ?></small>

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

вообще-то играет, 2.3.3 в плане нагрузки был куда лучше последних версий.

слабое место WP это база данных. сам WP может и 10к посетителей в день держать даже близко не напрягаясь, но вот если базе данных не хватает ресурсов - блог будет сильно тормозить.
первым делом добавьте у себя в файл footer.php строчки:

<small><?php printf(__('%d / %s'), get_num_queries(), timer_stop(0, 3)); ?></small>

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

40-45 запросов, 5-10 секунд

блин, а я вот свою проблему решить никак не могу. количество запросов малое, а задержка в секундах жесткая:
20-22 / 5.689-13.229

dc, смените тему на Дефолтную и отключите временно все плагины. Что будет?

Плагин WP Tuner, что показывает?

40 запросов за 5-10 секунд это очень много.
лично я при таких задержках звоню в тех. саппорт хостинга и начинаю ругаться.

проверьте насчет плагинов – иногда запросов от них мало, но зато они слишком затратные – например при
каждом запросе идет полная выборка по всей базе данных.

40 запросов за 5-10 секунд это очень много.
лично я при таких задержках звоню в тех. саппорт хостинга и начинаю ругаться.

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

Вот список плагинов:
Блокировка запросов на новые версии
Bookmarkz
cforms
Daiko’s Text Widget
Dean’s FCKEditor For WordPress
Latest Comments
MaxSite Ushki
No href in Comment Author
Ozh’ Admin Drop Down Menu
Post Template
Raven’s Antispam
Related Posts (modified)
StylePress
Subscribe To Comments
wp-cache
WP-PageNavi
WP-Polls
WP-Polls Widget
WP-PostRatings
WP-PostViews
WP-Table Reloaded
WP-UserOnline

Есть среди них подозрительные?

да тут не угадаешь. даже postratings нехило грузит базу.
вы лучше проверьте работу блога без плагинов, вернее время на mysql запросы.
может у вас сама по себе база тормозит, независимо от плагинов.

попробуйте поставить Hyper-Cach
может помочь

В связи с этим несколько вопросов:

2) Может быть стоит переехать на другой движок? Посоветуйте на какой?

Попробуйте МаксСайт.
http://maxsite.org/page/maxsite-cms-odin-god

[quote=0hk0]В связи с этим несколько вопросов:

2) Может быть стоит переехать на другой движок? Посоветуйте на какой?

Попробуйте МаксСайт.
http://maxsite.org/page/maxsite-cms-odin-god[/quote]
А при переходе на MaxSite CMS возможно импортировать комментарии, рейтинги, счётчики просмотров и внутренние ссылки в блоге?

да тут не угадаешь. даже postratings нехило грузит базу.
вы лучше проверьте работу блога без плагинов, вернее время на mysql запросы. 
может у вас сама по себе база тормозит, независимо от плагинов.

Отключил все плагины. Страница генерируется примерно за то же время. Запросов стало 29 (было 40-45).

Вопрос в ЛОБ! пробовали воспользоваться Hyper Cach?

Есть какие-то различия между wp-cache и Hyper Cache (и заодно DB Cache)?

Super Cache просит вписать несколько строк в .htaccess
Hyper Cach работает "из коробки"

Вопрос в ЛОБ! пробовали воспользоваться Hyper Cach?

По-моему, нет. А что, он намного эффективнее?
И, если у меня без плагинов 29 запросов за 3-8 секунд – это что значит? База тормозит или нет?

А при переходе на MaxSite CMS возможно импортировать комментарии, рейтинги, счётчики просмотров и внутренние ссылки в блоге?

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

[quote=Simulacrum]Вопрос в ЛОБ! пробовали воспользоваться Hyper Cach?

По-моему, нет. А что, он намного эффективнее?
И, если у меня без плагинов 29 запросов за 3-8 секунд – это что значит? База тормозит или нет?[/quote]
тормозит. если запросы выполняются больше 2 секунд, то это определенно проблема загруженности базы данных.
и переход на любой другой движок вам не поможет – пусть запросов там будет меньше, но база по-прежнему будет
их медленно обрабатывать.

или меняйте хостера или берите более мощный тариф.

и если уж на то пошло – начните с ограничения постов на страницу, хотя бы не больше 5.

Super Cache просит вписать несколько строк в .htaccess 
Hyper Cach работает "из коробки"

Я имел ввиду производительность и экономию ресурсов. Какой из них лучше будет взять? Или все зависит от настроек блога и поэтому стоит выбирать самому? 🙂

[quote=0hk0][quote=Simulacrum]Вопрос в ЛОБ! пробовали воспользоваться Hyper Cach?

По-моему, нет. А что, он намного эффективнее?
И, если у меня без плагинов 29 запросов за 3-8 секунд – это что значит? База тормозит или нет?[/quote]
тормозит. если запросы выполняются больше 2 секунд, то это определенно проблема загруженности базы данных.
и переход на любой другой движок вам не поможет – пусть запросов там будет меньше, но база по-прежнему будет
их медленно обрабатывать.

или меняйте хостера или берите более мощный тариф.[/quote]
А как мне правильно выбрать тариф? Какие параметры должны у сервера быть? А то перееду куда-нибудь, и снова столкнусь с тормозами?

PS: Спасибо за советы. Количество постов на странице уменьшу. Может быть есть ещё способы снизить нагрузку на сервер?

PPS: забыл сказать – на многие картинки на сайте (около штук 7 на главной странице) грузятся со сторонних серверов. Это как-то влияет на загрузку?

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

Кстати не факт, что тормозит именно база. Вы же смотрите время генерации страницы, а затраты на БД – только часть временных затрат. Даже если страница создается за 2-3 секунды (значение, которое показывает WordPress), то это нормальное значение, вполне комфортное для посетителей.

Отмечу, что дело может быть и не в БД, а в самом WordPress. Вот самые узкие места:

– Если вы испольуете «древовидные» рубрики (то есть рубрики-подрубрики-подподрубрики и т.д.), то это многократно увеличивает нагрузку. Идеально – только рубрики. Связано с тем, что WordPress в таких случаях использует рекурсию и из-за своей таксономии, где алгоритм не совсем оптимальный.

– Много статичных страниц (static). WordPress получает их все и всегда. Поэтому такие страницы должны быть небольшими и их должно быть немного.

– Вложенность страниц (родитель). Работает аналогично «древовидным рубрикам».

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

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

И последнее. Попробуйте поотключать плагины по одному и запишите результат на сколько уменьшаются показатели времени и sql-запросов. Если плагин создает более 2-х sql-запросов, то нужно задуматься о его использовании.

(Если строго, то практически любой сервер без проблем выдержит 1000 sql-запросов, но за небольшой промежуток времени (скажем до 30 секунд). Если же нагрузка постояная, то нужно стремиться к меньшему количеству обращений к БД. Посчитайте количество обращений к БД на сервере в минуту при 4000 хитах в сутки при условии, что на сервере 100 таких сайтов и для каждого посетителя создается 40 sql-запросов.)

Отмечу, что дело может быть и не в БД, а в самом WordPress. Вот самые узкие места:

- Если вы испольуете «древовидные» рубрики (то есть рубрики-подрубрики-подподрубрики и т.д.), то это многократно увеличивает нагрузку. Идеально - только рубрики. Связано с тем, что WordPress в таких случаях использует рекурсию и из-за своей таксономии, где алгоритм не совсем оптимальный.

- Много статичных страниц (static). WordPress получает их все и всегда. Поэтому такие страницы должны быть небольшими и их должно быть немного.

- Вложенность страниц (родитель). Работает аналогично «древовидным рубрикам».

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


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

И последнее. Попробуйте поотключать плагины по одному и запишите результат на сколько уменьшаются показатели времени и sql-запросов. Если плагин создает более 2-х sql-запросов, то нужно задуматься о его использовании.

Древовидные рубрики использую. У меня есть 10 рубрик 1 уровня и 2-3 сотни рубрик 2 уровня
. У всех рубрик 2 уровня родитель – одна и та же рубрика 1 уровня. В принципе, я их могу все сделать рубриками 1 уровня. Поможет?

Статичные страницы у меня есть. Они небольшие и их около 30. Это много или мало?

Из трёх десятков статичных страниц 3 – 1 уровня и 25 – второго. Как и в случае с рубриками у них у всех одна и та же родительская страница.

На главной странице вывыдятся 10 постов. Все – с катом (т.е. с тегом <more>).

Рекламы нет, сторонних скриптов, кажется нет. Проверка на новые версии отключена.

Плагины попробую отключать, но там и отключать-то толком нечего (список см. выше). Ну, можно попрощаться с postviews и latest comments, но больше, кажется, ни один плагин в базу не лезет.

Но поотключать их по очереди я попробую.

Anonymous
Отправить
Ответ на: