«Но часто каждая опция реализована в виде отдельного запроса get_option('name_option'), где 1 поле соответствует 1 значение, что порой является причиной лишних обращений к БД»
Раз вы взялись писать статью о wordpress, вы должны были бы знать что большинство настроек из wp_options забираются одним запросом при запуске скрипта, и очередные get_option забирают в любом случае из кеша. Возможно конечно запретить кеширование опции проставлением флага, но не вижу в этом смысла.
Возможно я не прав.
Из кэша беруться опции, которые уже вызывались. Стандартные опции беруться одним запросом. А вот пользовательские опции, которые используются в прмиум шаблонах и плагинах (в некоторых) вызываются отдельно и делают запросы. У нас жене все поля из таблицы опций дергаются при вызове get_option('name_option'). С добавлением новых плагинов или натроек в теме, часто в шаблоне дергают опции по 1. Вот, что я имел в виду.
Вопрос — почему 3-4 Мб, или даже 14 Мб памяти стоят этой работы?
Это какая-то сверхдорогая память или на случай если сервер хостит миллионы блогов одновременно?
Если у Вас свой выделенный сервер под сайты тогда Вам волноваться скорее незачем, но большинство среднестатистических сайтов на вордпрес размещены на шаред-хостингах и при посещаемости блога в 1000 и больше в сутки существует большая вероятность что Вас попросят переехать на ВПС или выделенку. Потому и оптимизируют ВП.
Да и посетителям приятнее когда сайт шустро грузится.
У меня на VDS мало оперативнйо памяти, это роскошь. Элементарно почему бы и не сделать меньше, если это можно. Думаю, вопрос «зачем улучшать» немного странный.
Какой работы, там дел-то 3 плагина поставить и активировать.
что-то мне кажется с eaccelerator вы напутали — у меня он всегда увеличивает потребляемую память процессами php, и это логично так как при дефолтных настройках он держит в памяти кэш байткода.
И еще вопрос у вас php как mod_php работает или как fastcgi?
Потребление памяти смотрел с помощью функции PHP memory_get_peak_usage(), вызываемой в самом конце скрипта.
Насколько я понимаю eAccelerator работает следующим образом:
1) если в кэше есть байткод для определенного файла — выполняет байткод.
2) если байткода нет — интерпритирует PHP код в байткод, кэширует байткод в ОЗУ и выполняет его.
Т.е. если в кэше храниться байт код, PHP код в ОЗУ не загружается, выполняется сразу существующий байткод.
А разве плагин WP Super Cache не закрывает вопроса с кэшированием страниц? Создается файловый кэш, каждой страницы, по экспайред-периоду он обновляется… Зачем нужны другие плагины для кэширования?
Вопрос стоит не о кэшировании старниц, а об оптимизации памяти и запросов.
Про полностраничное кэширование я писал. Ничто не мешает сверху сделать еще и полностраничное кэширование если хочется или не использовать динамический кэш.
Кэширование на уровне запросов имеет ряд преимуществ в интернете можно найти + и — кэширования на уровне запросов. Нет проблем с плагинами рейтингов или какими-то частоизменяющимися показателями на сайте.
Вариант с Pure PHP Localization достигает почти такогоже результата.
Это я и вы можете пользоваться английским ВП не напрягаясь. А вот пользователи, которые первый раз видят ВП не будут. Мало того, что это все для них сложно (сами когда-то начинали, вспомните (: ) так еще и на английском языке.
Вообщем, это вариант только для узкого круга пользователей, которые все это прекрасно и без меня знают ;)
Да ))
Но наши хорошие хостинг провайдеры быстро заставят его заинтересоваться этим вопросом, если человек на блоге активную деятельность развернет или женачнут выкачивать из него дополнительные деньги.
Оптимизация памяти и запросов в wordpress