Производительность WordPress
Пятница, 3 ноября 2006 г.
Просмотров: 3565
Подписаться на комментарии по RSS
Нередко в Сети встречаются высказывания, что WordPress очень "прожорлив" и сильно "грузит" сервер. В качестве "доказательства" приводят количество запросов к базе данных. Действительно, на каждую страницу WordPress может потратить 20-40 запросов к базе данных. Но, является ли это таким важным параметром, как это представляют критики? Попробуем разобраться.
[upd] Всё-таки я вынужден отметить, что данная статья написана в то время, когда WordPress действительно потреблял ресурсов в разумных пределах. Начиная версии 2.5, разработчики практически не уделяют внимание этому вопросу внимания и новые версии требуют всё болье и больше php-памяти sql-запросов. Проблема здесь кроется в неоптимальном алгоритме подключения библиотек, отстутствие нормального кэширования и т.д.
Однако, для того, чтобы оценить производительность WordPress, необходимо для начала понять его алгоритм работы. То есть нужно понять по какой такой причине WordPress создает столько запросов к базе данных и почему (а то критики WordPress утверждают, что некая система X делает "тоже самое" всего за 2-5 запроса)?
Связка PHP и MySQL
Представим себе, что у нас уже есть блог с набором страниц. База данных блога - это библиотека, где книги - это отдельные страницы-записи рассортированые по полкам (рубрикам, авторам и т.д.).
Теперь наша задача получить одну книгу (запись) по какому-то критерию, например названию. Сделать это можно двумя способами.
Первый - мы берем всю библиотеку сразу и получаем отсортированных список всех книг. Этот список мы с помощью PHP пролистываем и проверяем совпадение с нужным названием.
Второй способ работает по другому. Мы просто даем свою заявку библиотекарю, который знает где и что лежит и сразу получаем нужную нам книгу.
Как видите, в первом случае мы вынуждены использовать дополнительное программное время (PHP) на проверку нужного условия, а во втором полностью полагаемся на интеллект библиотекаря (MySQL).
Это упрощенный пример, но он показывает, что можно сделать систему управления сайтом (CMS) "нагружая" либо PHP, либо базу данных (БД).
Оптимальный вариант
Так всё-таки, что лучше: использовать дополнительный запрос к БД или написать дополнительный PHP-код? Ответ очень прост: использовать БД. Почему? Да потому что база данных для этого и предназначена! Что такое база данных? Это специальная программа-драйвер, которая определенным образом хранит, обрабатывает и обновляет данные. Физически данные хранятся в виде файлов, но БД имеет средства получения нужной выборки гораздо быстрее, чем просто считывание этого файла, а потом его обработка. Базы данных обладают различными механизмами, позволяющими сделать выборку практически мгновенно, например за счет индексирования таблиц или кэширования.
Известно, что PHP имеет не самую удачную реализацию функций по работе со строками. Например, таблица опций WordPress (wp_options) может составлять 500-600Кб. Представьте себе, что вам нужно получить каких-либо 20 опций (значений). Если делать это через один запрос (то есть считать весь файл целиком), то на PHP придется перебрать в цикле все 200-300 существующих записей, чтобы создать массив из нужных. При этом будут задействованы медленные функции для строк. Эта же задача с помощью MySQL решается элементарной стандартной выборкой. Правда в этом случае мы создадим дополнительно 20 запросов. Однако и в первом случае, эти же самые запросы, по-сути, будут просто сымитированны, но уже средствами PHP.
Оправдано ли использование базы данных? Да, и на это есть несколько причин. Прежде всего необходимо отметить, что базы данных допускают одновременный доступ сразу множества пользователей. То есть когда вы грузите страничку и получаете выборку, то одновременно с вами это могут сделать десятки, сотни или тысячи посетителей. Встроенные механизмы БД распределяют нагрузку таким образом, чтобы обеспечить собственную работоспособность и не "завалить" сервер. Передавая нагрузку на MySQL мы обеспечиваем и быстрое выполнение PHP-скрипта, таким образом снимая нагрузку на сервер.
Вторым фактором является то, что база данных позволяет делать сложные выборки с использованием разнообразных условий. То есть когда нужно получить только номера последних записей, совершенно не обязательно выполнять запрос и получать все данные, включая текст, название, автора и т.д. Мы просто указываем нужное нам поле (ключ) и получаем уже готовый результат.
Третий фактор - PHP имеет мощную поддержку MySQL. Таким образом отпадает необходимость "изобретать велосипед" - с помощью PHP мы можем не только сформировать нужный запрос к БД, но и получить его в виде, сразу пригодном для обработки или вывода. То есть отпадает необходимость использования медленных функций, сложных циклов и рекурсий.
Сколько нужно запросов?
Возникает резонный вопрос, а зачем WordPress'у столько запросов к базе? Если выводится 10 записей, да список рубрик, то хватит и 15-20. Откуда же берется 30-40? На самом деле здесь нет никакой тайны - множество запросов осуществляется для получения разных настроек, например адрес, название, описание блога, формат даты и т.д.
Всё это конечно же хранится в базе данных, следовательно без дополнительных запросов просто не обойтись. Причем разработчики WordPress применили алгоритмы, позволяющие уменьшить количество запросов, если вы получаете данные с помощью определенных функций, например bloginfo().
Для того, чтобы реально оценить количество запросов к базе данных, а также увидеть что это за запросы, я решил провести небольшое исследование. Мне интересно было узнать реальное количество запросов, оценить эти запросы, а также увидеть количество преданных данных (записей, rows) из БД.
Методика исследования
Для получения нужных данных я использовал программу MySQLAdministrator. Это довольно сложная утилита, которая позволяет не только настроить MySQL, но и получать логи (отчеты).
За основу я взял WordPress 2.0.5 своей сборки. Отключил все плагины, установил стандартный шаблон (default). Пермалинки (ЧПУ, постоянные ссылки) были включены. В качестве тестовой площадки я использовал свой локальный блог и был залогиннен. Количество записей на главной странице - 8.
Количество запросов с кэшем и без
Первым делом я отключил кэш. В этом случае количество запросов составило 40 (это генерация главной страницы). После включения кэша, количество запросов уменьшилось до 15. Это говорит об эффективности использования кэша. Причем размер кэша на диске составил в сумме всего 8Кб.
Что грузим?
Больше всего меня интересовало "качество" запросов. Здесь я привожу список групп запросов. (Кэш отключен).
- Запросы к wp_options (siteurl, home, hack_file, active_plugins, permalink_structure, category_base, date_format, template, wp_user_roles, rewrite_rules, html_type, blog_charset, posts_per_page, gmt_offset, what_to_show, gzipcompression, blogname, stylesheet, kubrick_header_image, kubrick_header_color, kubrick_header_display, blogdescription, use_smilies, links_recently_updated_time).
- Запросы к таблицам пользователей wp_users и wp_usermeta (user_login, meta_key, meta_value).
- Запросы к таблице всех записей wp_posts (вначале выбираются последние 8 записей, после этого получаются категории из wp_post2cat и wp_categories).
- Запросы к данным записей wp_postmeta.
- Запрос на получение всех постоянных записей (полностью все данные).
- Запрос для формирования архива.
- Запрос на формирование списка рубрик.
- Запросы на формирование списка ссылок по категориям.
Оптимизация запросов
Нужно отметить, что запросы на выборку сделаны корректно. Везде где возможно, установлено ограничение на количество записей (LIMIT, DISTINCT) и уточненны условия (WHERE). То есть получаемые данные сразу готовы для PHP-обработки и вывода (собственно это видно по коду самого WordPress).
Объем выборки (rows) не вызывает опасений - лишние записи не берутся из базы данных и не обрабатываются.
Проблемные точки
Однако, это не означает, что у WordPress нет проблем. Самая очевидная из них, это получение всех постоянных страниц (SELECT * FROM wp_posts WHERE post_status = 'static' ORDER BY post_title ASC). Этот запрос означает, что при каждом обновлении будут браться из БД все постоянные страницы со всем полями. Если их много и они большие, то это действительно может привести к существенной нарузке. При этом бессмысленную - нет смысла получать полный текст (а это основной объем). Причем при включенном кэше всё равно происходит повторная выборка.
Итоги
Думаю, что эта статья отчасти развенчает миф о якобы большой нагрузке, создаваемой WordPress'ом. Если посмотреть на возможности WordPress, то становится вполне объяснимым и количество создаваемых запросов к базе данных. Ведь они нужны не просто так, а для обеспечения его функциональности. А если учесть эффективность кэширования, то вопрос о нагрузке вообще отпадает. Единственным минусом являются постоянные страницы, так что здесь есть над чем работать.
В следующей статье я рассмотрю вопросы оптимизации шаблонов WordPress.
Комментариев: 28
Грамотно. Но чего-то не хватает для убедительности. Не могу понять чего. Моё такое мнение, что для тех задач, которые призван решать WordPress, он подходит вполне. Ему же не надо обрабатывать 200 запросов в секунду.
Интересно, а сколько посетителей одновременно может выдержать блог на WordPress? Или это зависит от хостинга?
Конечно от хостинга. Но, обычно если нагрузка действительно большая, хороший хостер предлагает купить выделенный сервер, а плохой просто блокирует аккаунт.
очень хорошая статья, Максим ;)
Удивляюсь как ты не поленился столько всего написать и сделать
)
+1 !
Сейчас выложу и вторую часть
ну при небольшом количестве постов DISTINCT действительно полезен, а когда их становится много, цитирую:
"использование операции DISTINCT к фукнции SELECT вызывает потребление гораздо большего количества процессорного времени, чем обычный SELECT. DISTINCT пытается искать уникальные значения, зачастую производя множество сравнений, подстановок и расчетов. Причем, чем больше становится объем данных к котором применяется DISTINCT (ведь ваша база со временем растет), тем более медленно будет выполняться такой запрос и рост ресурсов, нужных для выполнения такой функции, будет происходить далеко не прямо пропорцонально объему хранимых и обрабатываемых данных, а гораздо быстрее."
(с) http://www.ultrahost.ru/support/mysql_opt.php
столкнулся с этой проблемой, пытаюсь найти выход из ситуации...
Я посмотрел логи и получается, что выборки с DISTINCT получают до 30 записей. То есть это мизерная нагрузка на сервер. По правде говоря, я не нашел на официальном сайте подтверждение вышеприведенной цитаты. Существует лишь описание (на dev.mysql.com), что DISTINCT работает как эквивалент GROUP BY. При использовании DISTINCT MySQL останавливает сканирование при первом совпадении, поэтому БД нет нужды обрабатывать запрос целиком. (линк)
В любом случае производительности MySQL достаточно, для всех запросов WordPress - они простые. Вот здесь пишется, что на Pentium II 400MHz выполнение 1000000 простых запросов занимает 0.32 секунды. :wink:
Спасибо. Я, собственно, заметил пост только сейчас, однако, прекрасно понимаю, откуда растут у него ноги. Действительно, все очень и очень приемлимого качества. Тем более, учитывая, что и как выбирается. Я погорячился, снимаю шляпу. Браво!
Однако, мне до сих пор кажется, что такая информация как адрес сайта или его название, вовсе не должна браться из БД. Скорее, все это дело стоит записывать в какой-нибудь options.php в виде инициализации, скажем, ассоциативного и подключать его на лету. Потому как это информация, изменяемая чертовски редко: проще перегенерировать один файл, чем постоянно тискать БД. Собственно, в то время, когда я еще использовал WordPress, я именно так и делал, слегка переписав вызовы, само собой ;) Можно считать это субъективным добавлением к соседнему посту.
Максим, все описанное тобой конечно достаточно грамотно, но есть один нюанс - ты сравниваешь две вещи работу с базой и работу без базы. Сейчас совсем мало CMS работающих без базы и следовательно убеждать в полезности базы - особого смысла нету. База данных, несомненно, нужна и важна. Другое дело - в количестве и качестве запросов к это базе и, вообще, в возможности доступа к базе в определенный момент времени.
Замеченная тобою проблема по статичным страницам - далеко не единственная, но в то же время легко решаемая - если страница статичная, вобще нет смысла ее хранить в базе как таковую (можно как раз хранить кэш статичных страниц в базе на случай, например, поиска, но в обычных случаях просто отдавать страницу с файла - она же статичная).
Теперь вернемся к другим проблемам с WordPress (многие другие к сожалению тоже имеют эти проблемы). Более важная проблема - это недостпуность сайта (иногда частями, иногда, что хуже, целиком) при недоступности базы данных (иногда база данны может упасть на пару-тройку часов). А пользователь в итоге (особенно тот, который пришел с поисковых систем, где система выдала ему сайт, на котором точно есть необходимая ему информация) приходит на сайт и видит что он не работает (на пользователя, посетившего сайт впервые, это может оказать большое отрицательное воздействие - вероятнее он уже не придет на этот сайт). Поэтому целесообразней хранить кэш динамических данных на диске на случай недоступности базы.
То есть идеальная система управления сайтом должна хранить:
- динамику в базе, а ее кэш в файле,
- статику в файле, а ее кэш в базе.
Позволю себе прокомментировать.
У меня нет такого сравнения. Речь идет о работе с базой данных, но двумя способами. В одном случае мы экономим количество запросов и переводим нагрузку на PHP, во-втором - увеличиваем нагрузку на MySQL, но получаем быстрое выполнение PHP.
Поэтому речь о НЕиспользовании БД даже не идет.
Термин «статичная страница» я использую именно как это принято в WordPress. То есть это совсем не статика (как HTML-файл). WordPress хранит все записи в одной таблице и отличие между статической страницей (static) и обычной записью (post) только в том, что у них различен статус (post_status) (в 2.1 еще есть post_type). Статус является лишь указателем того, как следует обрабатывать страницу, например post нужно вывести в ленте новостей.
Использовать же кэш для страниц или записей (то есть уже заранее сгенерированных) не получится. Проблема в том, что при "отдаче" текста, WordPress применяет к нему различные фильтры (php-функции). Поэтому если отдавать текст из кэша, то уже невозможно его обработать фильтром, поскольку он просто окажется отключенным. В любом случае, такие попытки уже предпринимались, но из-за описанных проблем свели пользу на нет.
Скорее это уже из области надежности сервера.
Теоретически можно написать скрипт, который будет генерировать все записи в виде html-файлов, и при каких-то условиях, WordPress будет их использовать вместо обычной работы с БД. Но, поскольку сервера обычно работают без проблем, то практический смысл опять же сводится на нет.
Спасибо, Максим, за столь быстрый отклик. Но не стоит так резко.
Позволю себе не согласиться с
поскольку в статье есть строчки:
Как мне кажется здесь есть именно сравнение с текстовым файлом и с базой. Я думаю сделать выборку все таблицы из базы без условий сделает только тот, кто впервые сел за PHP, но никак не профессионал, который разрабатывает CMS. Или я в чем-то неправ?
Обратимся к другому моменту. Статика - она и есть статика, как ее не назови. И, я полагаю, никто не осмелится назвать динамической страницу статичной и наоборот. Если страница статична - значит в ней автоматически не меняются никакие данные (различные поля шаблона с меню, рекламой и т.п. не в счет - это ложится на процессора шаблонов страницы). А если страница статична(а таких, как правило, у среднестатического сайта их бывает более 60% всего контента). Даже вот эта статья на данной странце - есть, по хорошему, статика, а комментарии к ней внизу может исполнять другой модуль CMS, который отвечает исключительно за комментарии читателей к данной странице (к данному URL). Следовательно, статичная страница в базе данных (которая, замечу, по умолчанию, считается хранилищем динамических данных) - это относительный нонсенс и лишняя нагрузка на базу данных.
И что ж с того, что данные для статичной страницы будут взяты из дискового кэша? На сколько я понимаю, к любым данным, полученным будь то из базы или прочитанным из файла, можно применить php-функцию (в прочем,я сомневаюсь, что для обычной неизменяемой (статичной) страницы эта обработка вообще нужна).
Ну на надежность сервера надеяться нельзя никому, знаешь ли пословицу "на бога надейся, а сам не плошай"? А потерянный посетитель - это крайне плохо. И к тому же, я не говорил, что дисковй кэш динамических данных должен преставлять из себя готовую html-странцу, скорее наоборот - кэш - это данные для генерации страницы (в определенный шаблон, с определенными шаблонными полями, в которые могут быть вставлены также и динамические данные).
Так я ж не против.
Если бы был механизм, позволяющий сделать такое кеширование, то это было бы замечательно. Но у WordPress'а есть только один способ вывода данных, поэтому чтобы его отключить нужно переписывать файлы "движка". В какой-то мере эта негибкость не позволяет например сделать свой вывод, где можно было бы придумать и кэширование, и переключение на статичные файлы. Даже если обмануть WordPress и "обнулить" первоначальные запросы к БД (они происходят автоматически), то все равно будет выполнен пусть и небольшой, но все-таки запрос к БД. Так, что здесь все не так просто, как кажется.
Когда-то для WordPress 1.5 был плагин «PreFormatted» (http://vapourtrails.ca/wp-preformatted), который делал такой кэш, правда в базе данных. Принцип его работы был простой. В таблице постов добавляется новое поле с уже готовой "статичной" страницей. При публикации или редактировании, плагин выполнял все форматирование, нужные фильтры и результат заносился в это поле. После этого на сайте запись бралась уже подготовленной и выводилась "как есть".
Минус, как я уже говорил в том, что те функции, которые подключаются либо через плагины, либо в самом шаблоне оказываются отключенными. Например на этой странице были бы отключены все метаполя, например отметку "Читали ... раз".
Но еще раз хочу отметить, что я использую термин "статичная страница", как это принято в WordPress. То есть речь не идет о статики в виде готового html-кода.
Ну так значит в WordPress есть над чем работать и система пока несовершенна
А плагины (по типу "Столько-то раз читали статью") - это же всего лишь динамически меняющася часть страницы (поле шаблона), которая может грузиться отдельно.
Спасибо за интересную беседу
Любая система несовершена, особенно открытая.
По плагину и "днамической" части вы ошибаетесь, скорее всего вы просто недостаточно хорошо знакомы с принципами работы WordPress. :wink:
Вы так относитесь к WordPress, что снимаете со счетов тот факт, что она является CMS?
Судя по вашим ответам, вы ищете оправдание, мол это работает не так, а это не работает, а под этими понятиями мы имеет в виду другие понятия. Делаете вид, что все сказанное про WordPress не имеет никакого отношения к системе управления сайтом, мол так и так, тут все по-другому и принцип другой. А между тем требования, предъявляемые к CMS одинаковы для любой CMS. Различия, думаю, стоит делать только на профессиональные и непрофессиональные системы (которые, по хорошему, должны заключаться только в интерфейсе).
Следовательно, такие требования как быстрота выдачи страницы, нагрузка на сервер (и на базу и на PHP и на сам Apache), гибкость и стабильность предъявляются ко всем CMS без исключения. А как уж называть внутренние механизмы и как им следует работать - это уже дело разработчика такой системы.
А вот ссылаться на то-то и то-то в виду отсутствия того-то по причине тех-то неустранимостей - это ничто иное, как поиск оправданий почему система не работает так как требуется.
Если нужно исправить код - его нужно исправить. Если нужно переписать ядро системы - ее нужно переписать.
И не надо говорить, что любая система несовершенна, и поэтому мы не будем править то, что явно не работает / работает не так.
Это не решение поставленной задачи.
Но... у каждого свои подходы. Кто-то просто закрывает глаза.
При чем тут все CMS??? Я пишу конкретно про WordPress. Рассуждать про абстрактную идеальную систему можно до бесконечности. Если бы такая была, то все давно бы уже на ней и работали. Хотите переписать WordPress? Пожалуйста, никто вам не мешает.
Хорошенькое завершение разговора и статьи
Ну да конечно, вы пишете конкретно про WordPress... Еще раз кстати подтверждаете, что говоря о WordPress, вы говорите как о чем-то особом, отстраненном, еще маленьком, неспелом и неконкурентноспособном. Ну да конечно, обсуждать баги систем управления
вы правы. А толку-то от обсуждений проблем? Надо говорить о методах решения проблем, а так получается простой обзор проблем, который кстати всеми силами пытается завуалировать эти проблемы, чтобы их не поднимать - потому что поднял - надо предлагать решения. Как в анекдоте - закрываем занавески в купе недвижущегося поезда и говорим "Спокойно, товарищи - едем"Мне переписывать эту систему смысла нет - вы ярый сторонник этой системы
Вам и карты в руки.
Совет: не делайте скидку при оценке WordPress на то, что это WordPress.
А то правда получается примерно то же что и с конкурсом, где среди взрослых участвует один ребенок - и ему отдают предпочтение: да типа плохо у ребенка получилось, но у него получилось для своих лет лучше, чем у остальных у остальных для своих. Это неправильно. И нечестно.
В первую очередь должна быть твердая независимая объективная оценка.
У нас беспредметный разговор, поскольку вы оперируете какими-то фантомными вещами, которые у меня, ну никаким образом не связываются ни с WordPress'ом, ни с данной статьей. Если вы хотите что-то доказать, то нужна конкретика: четкая, ясная и на примерах. А "поезда" и "дети" - это пустая риторика - этим вы ничего не докажите.
На сегодняшний день, WordPress не только конкурентен, но еще и фору даст другим CMS. (Но наверное, вы и здесь не в теме - тогда взгляните на отчеты Яндекса.) Если бы вы работали с WordPress, то наверное смогли бы сказать что-то конкретное. А так вы просто путаетсь в его терминологии. О тех же проблемах, которые на мой взгляд являются важными, я не только рассказываю, но и привожу способы решения. Почтитайте внимательно сайт.
На тему производительности вы не совсем правы.
При больших нагрузках - порядка 200000 пользователей в день - имеет смысл делать кеширование.
Иначе... Все сложится домиком...
Вообще вордпресс немного для других целей. ;)
Единственный плюс WP в данной ситуации - что его можно просто подружить с демоном memcache на уровне шаблонов - если уж случилась такая нагрузка ;)
На своей машинке я WP подружил с nginx + php-fastcgi. Причина - у меня мало памяти у сервера на апач + сайты. В чем то выглядит поприятсвеннее.
А с выходом новых версий wordpress с производительностью движка при работе с постоянными страницами что-нибудь в лучшую сторону изменилось?
Например, если сайт будет содержать порядка 1000 страниц.
Боюсь вас огорчить. Скорее ухудшилась. :( Если речь идет о постоянных страницах, то придется переписывать часть функций на свои.
Очень жаль. И кэширование не помогает?
Сам WordPress стал прожорлив. А кэширование нужно всегда.
Добрый день Максим!
а вот действительно, если сталкиваешься с такой проблемой - что файлов разделов дофига, сайт набирает посещаемость, и вот хостер кричит - охерели вы батенька, можно ли соптимизировать как то работу блога, что бы не выкупать сервак?!
дороговастенько пока это для меня, а вот пару бы дней на работу потратил, что б что то посносить. пока что нарыл в интернете - не собрано. пытаюсь найти это у вас, может на момент поиска, мой запрос здесь актуальным не будет, но все же - если вы сгруппировали в какой то статье условно назвав ее "как оптимизировать блог на вордпрессе что б не злить хостинг" - и дадите ссылочку здесь - на перед благодарю
:smile:
Откуда такие цифры? Ну это очень большой конфиг в 500-600 кб.
Конфиги обычно не нужно перебирать все записи в нем. Достаточно обратиться к нему по ключу (ассоциативные массивы), а это опериция достаточно быстрая.
Имхо для выскоконагруженных сайтов база данных только тормозит, потому что рапералелить скрипт легко, а вот бд намного сложнее.
А если еще для каждой настройки обращаться к базе данных это ввобще караул.
а как созданный запрос разместить на странице? в WordPress