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