WordPress под микроскопом

Vladimir

которая и так забита – теми же рсс из дашборда

Те же RSS из dashboard было бы разумнее хранить в файле — не вижу смысла захламлять базу данных. Одна лента весит где-то 50К, 4 ленты будут весить порядка 200К. Плюс излишки на сериализацию. Как часто среднестатистический блоггер посещает dashboard? Не получается ли так, что закэшированный RSS в таблице успевает состариться? Ну грохнет его WordPress, но и создаст лишнюю фрагментацию в таблице. Часто ли блоггеры делают OPTIMIZE TABLE? Сомневаюсь.

В любом случае, обращение к файлу (в случае RSS) займёт меньше времени, чем обращение к базе.

то приходится жертвовать в пользу оптимизации “сверху”

Но при грамотном проектировании жертв меньше! Взять тот же кэш: на самом деле, очень тяжело написать кэширующий движок с высокой производительностью, учитывая архитектуру WordPress. WP всё время что-то кэширует, но ведь память-то не резиновая! У меня за одно обращение к главной странице в кэш почти 6 мегабайт попадает! Если использовать shm и хранить кэш в разделяемой памяти, рано или поздно (скорее, рано) встанет вопрос о том, что память нужно освобождать. Я уже не говорю о фрагментации и т.п. Для освобождения памяти будет использоваться какой-нибудь простенький алгоритм, и тут получается такая вещь: выпнул из памяти какой-нибудь блок, а WordPress он понадобился! А при использовании хорошего алгоритма приходится идти на дополнительные издержки, что выливается в ту же производительность: проверять в цикле тысяч по десять элементов с целью нахождения кандидата на вылет будет не всегда быстро. Да, это быстрее, чем лезть в БД при хорошей нагрузке, но медленнее, чем стандартный кэш WordPress (!) при низкой нагрузке. Я не тестировал акселераторы, может быть, там что-то изменится.

А что мешало разработчикам спроектировать нормальную систему классов и использовать несколько уровней кэширования? Те же опции: читаем их в локальный protected array один раз и используем в течение всей сессии. Нужно — отдаём кэширующему модулю, если он не возьмёт данные — а и хрен с ними, у нас есть их локальная копия, и в базу мы не полезем. Вот тогда можно было бы использовать более простой алгоритм в кэширующем движке, не переживая, что WordPress полезет несколько раз в базу за одними и теми же данными. С опциями это простой пример, но идея понятна.

Или еще пример: когда я разбирал запросы в get_calendar(), я нашел способ оптимизировать запрос: если бы мы убрали ORDER BY, MySQL не пришлось бы делать файловую сортировку. GROUP BY отсортировал данные в одном порядке, а ORDER BY сортировал их в другом. Не помню деталей, но EXPLAIN показывал, что без ORDER BY не было бы Using filesort. Просто WordPress пришлось бы просматривать массив в обратном порядке. Мелочь, согласен. Но когда таких мелочей много, то на их исправлении можно выиграть существенный прирост в производительности.

Я вводил избыточность в тестовую БД и переписывал запросы; в результате на большой базе производительность поднялась в 10 раз!