Облегчаем жизнь серверу и ускоряем WordPress сайт

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

Ранее я рассматривал техники полного кеширования сайта, настройку собственного сервера (часть 1, часть 2, часть 3), использование YSlow для ускорения сайта. Но это еще не все! Я также применял технику спрайтов (и не только) на своем сайте и включал zlib сжатие. Как видите, много всего я перепробовал и рассказал вам. Но и это не все…

Сегодня я нашел интересный , который не претендует на уникальность – существует он достаточно давно, но просто он не так сильно распиарен, как Super Cache. Да, это кеширования, и называется он DB Cache Reloaded. Оригинал этого плагина (DB Cache) перестал поддерживаться и обновляться автором, потому Daniel Frużyński создал версию Reloaded, которая рассчитана для 2.8.x-2.9.x. К сожалению, для WPMU+BP плагин не предназначен (я проверял – чуть не убил demo.сайт).

Итак, в чем особенность DB Cache Reloaded? Он кеширует, но не всю страницу – а лишь запросы к базе данных. Этим он экономит место на вашем диске и меньше нагружает винчестеры хостера. Я не буду вдаваться в технические подробности его работы (большинству это не нужно), кому будет интересно, тот прочитает обо всем на странице плагина. Просто скажу реальные результаты его работы.

Главная страница моего сайта очень нагружена – я отображаю 61 запись на ней (когда посчитал – был в шоке!), не считая блока комментариев и популярных записей в сайдбаре. Итого выходило на главной 129 запросов к базе данных и почти 35 мегабайт памяти. Многовато, не так ли? И это при том, что я не использовал ни одного плагина кеширования!

После активации плагина DB Cache Reloaded и настройке его на соответствующей странице (я выставил жизнь кеша в течение 60 минут) вот мои новые результаты:

Сейчас: 23 запроса за 1.797 сек. | В кеше 106 запросов | Память – 27.07MB

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

Скачать DB Cache Reloaded

На данный момент 75 комментариев


  • Completed 1000 requests
    Completed 2000 requests
    Completed 3000 requests
    Completed 4000 requests
    Completed 5000 requests
    Completed 6000 requests
    Completed 7000 requests
    Completed 8000 requests
    Completed 9000 requests
    Completed 10000 requests
    Finished 10000 requests

    Server Software: nginx/0.8.20
    Server Hostname:
    Server Port: 80

    Document Path: /2010/01/08/privet-mir/#comments
    Document Length: 9891 bytes

    Concurrency Level: 100
    Time taken for tests: 82.406 seconds
    Complete requests: 10000
    Failed requests: 0
    Write errors: 0
    Total transferred: 101780000 bytes
    HTML transferred: 98910000 bytes
    Requests per second: 121.35 [#/sec] (mean)
    Time per request: 824.055 [ms] (mean)
    Time per request: 8.241 [ms] (mean, across all concurrent requests)
    Transfer rate: 1206.16 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 0 0 0.8 0 13
    Processing: 183 821 151.2 748 1595
    Waiting: 182 818 150.0 748 1592
    Total: 195 821 151.0 748 1595

    Percentage of the requests served within a certain time (ms)
    50% 748
    66% 796
    75% 863
    80% 891
    90% 1079
    95% 1113
    98% 1298
    99% 1329
    100% 1595 (longest request)

    а если example.com, то умирает после первых 20 запросов

  • Игорь,
    результаты в студию!:)


  • ab -n 10000 -c 100 http://uicrothuwepran.мойдомен.com/2010/01/08/privet-mir/#comments
    This is ApacheBench, Version 2.3
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking uicrothuwepran.мойдомен.com (be patient)
    Completed 1000 requests
    Completed 2000 requests
    Completed 3000 requests
    Completed 4000 requests
    Completed 5000 requests
    Completed 6000 requests
    Completed 7000 requests
    Completed 8000 requests
    Completed 9000 requests
    Completed 10000 requests
    Finished 10000 requests

    Server Software: nginx/0.8.20
    Server Hostname: uicrothuwepran.мойдомен.com
    Server Port: 80

    Document Path: /2010/01/08/privet-mir/#comments
    Document Length: 9891 bytes

    Concurrency Level: 100
    Time taken for tests: 85.676 seconds
    Complete requests: 10000
    Failed requests: 0
    Write errors: 0
    Total transferred: 101780000 bytes
    HTML transferred: 98910000 bytes
    Requests per second: 116.72 [#/sec] (mean)
    Time per request: 856.760 [ms] (mean)
    Time per request: 8.568 [ms] (mean, across all concurrent requests)
    Transfer rate: 1160.12 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 0 0 1.4 0 26
    Processing: 332 852 184.8 797 1926
    Waiting: 331 849 182.1 795 1904
    Total: 344 852 184.6 797 1926

    Percentage of the requests served within a certain time (ms)
    50% 797
    66% 863
    75% 893
    80% 932
    90% 1066
    95% 1174
    98% 1515
    99% 1708
    100% 1926 (longest request)

    Дальше:


    ab -n 10000 -c 100 http://мойдомен.com/index.php
    This is ApacheBench, Version 2.3
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking мойдомен.com (be patient)
    apr_poll: The timeout specified has expired (70007)

    даже не взлетает))

  • siege, в принципе то же самое, но видно что умирает после 15-20 строчек

  • Ребят, прошу, не используйте домен xxx.ru для примера. Вы видели, куда ведет этот адрес? Потому вас и банит акисмет.
    Используйте example.com – это международный стандарт сайта-примера.

  • Сейчас у меня стоит wpsc, который не предполагает обновление по заголовкам, wpsc+, предполагает, то есть если что-то обновилось, он принудительно выдаст свежую страницу и закеширует, но у меня начались траблы при входе и выходе из админки, сам не могу найти причину, буду пробовать, к чему я клоню, кешировать надо, наверное, но при определенной ситуации может сыграть не на руку http://blog.sjinks.pro/wordpress/601-wp-supercache-under-high-load-part-2/

  • Кешируйте на стороне веб-сервера и будет счастье… ;)
    а у меня кеширование идет везде где это имеет смысл – все супер!

  • slaFFik, вроде меня еще не банили :)

    Игорь,
    чтоб избежать arp_.. ошибок, пользуйтесь -n 10000 -c 5, обычно этого достаточно! и смотрите через top, – как “подыхает” сервер ;) то есть следующий этап закрыться от массовых обращений

  • Спасибо Александр, буду пробовать.

  • Добрый день. А у меня этот плагин не активируется. Пишет, что не правильный заголовок плагина. Подскажите пожалуйста, что можно сделать?

    • Lovedancer,
      Я же писал, что этот плагин не работает с WPMU – читайте пост внимательнее (конец третьего абзаца)!

  • Но если прочитать внимательно мой комментарий, то можно углядеть, что я там не писал, что у меня WPMU =) а если посмотреть внимательно на блог, то можно увидать, что у меня простой WP =) …и кстати заработал он ….вот только почему-то, такую мне нагрузку создал, что у меня сервак подвис….. =) пришлось его рубить… а у меня и без него нагрузка ай-яй-яй….я то решить вопрос пытаюсь этот, и делаю разные оптимизации, но это почти не помогает….кстати я ищу человека, который в паре бы со мной, смог бы мне помочь с нагрузкой моего блога…..конечно же за денежное вознаграждение….

  • Кстати, а как ведёт себя твоя социальная сеть?

  • Прочитал твои предложения, и просто возжелал эту соц сеть =) …пожалуйста, скажи, как у неё с нагрузкой и всё такое? Просто у меня сейчас аномально грузиться wordpress….возможно действительно он у меня скрытый WPMU =))))

  • Lovedancer,
    у slaFFik-a можно почитать мои советы по оптимизации сервера + советы от самого slaFFik-a по WP MU, BP..

  • Всё, читал, почти всё пробовал, и ещё миллионы других советов со всего инета…многое помогало, но чем больше становился траф, тем всё больше увеличивалась нагрузка…..чего я только уже не делал….у меня осталось несколько вариантов:

    1-купить более дорогой хостинг
    2-перейти на другой движок
    3-переустановить вордпресс
    4-улучшить сервер

    но…

    1-по финансам возможности особой нет, хотя заинтересовал хостинг avihost..я с ними уже списался..хотя я так же не знаю, выдержит ли он мой сайт.
    2-вот как раз заинтересовал budypress, но я так же не знаю, выдержит ли он такую нагрузку
    3-ищу как правильно это сделать
    4-хостер отказывается это делать

RSS лентаTrackBack URL

Включиться в обсуждение

XHTML: <blockquote></blockquote> <a href=""></a> <strong></strong>

Если нужно разместить код, используйте теги: <pre>php|html|js</pre>

Открыть Нечто !