Комментарии 23
Спасибо! Приятно видеть все «первоочередные» приемы в одной статье
Понравилось наличие в тегах memcache — наверное единственное, что не упомянуто в заметке :)
Перекиньте, пожалуйста, обложку журнала налево, так как сливается с рекламным баннером Хабра и… в общем, не самый лучший ракурс.
Возникают вопросы:
1. а тестирование не для IIS проводились?
2. а почему в несколько (десятков) раз за считанные минуты?
1. а тестирование не для IIS проводились?
2. а почему в несколько (десятков) раз за считанные минуты?
если есть ссылка на результаты тестирования не под IIS — с удовольствием ее приведу. Просто не нашел при поиске материала на эту тему.
просто описываете инструменты, ну да прикольно, возможно я к ним вернусь когда будет необходимость оптимизировать скорость моего блога. а в конце вы говорите что можно увеличить производительность в несколько раз. возникает резонный вопрос: чем докажете? :)
я не буквоед, просто мне кажется это несколько нелогичным.
я не буквоед, просто мне кажется это несколько нелогичным.
лично я использовал несколько инструментов из вышеуказанных — скорость увеличилась (в 2-3 раза). Очень сильно зависит от характера блога, нагрузки на него и параметров хостинга — насколько вообще можно улучшить ситуацию. Тут цифры могут и на порядок, и на два колебаться.
Специально тестирование по модулям кэширования не проводил.
Специально тестирование по модулям кэширования не проводил.
Думаю будет полезным описать ещё плагин кэширования: really static.
_http://wordpress.org/extend/plugins/really-static/
Всегда было интересно, как такие плагины работают с комментариями. Повился плагин, закэшировали снова?
_http://wordpress.org/extend/plugins/really-static/
Всегда было интересно, как такие плагины работают с комментариями. Повился плагин, закэшировали снова?
ну как на самом деле скромно написано. единственное чего коснулись действительно нужного — это оптимизация базы данных, но и то написанно два параметра которые ни к селу ни к городу.
по сути надо было разделить настройку на серверную и клиентскую. не у ввсех есть свой сервер или впс чтобы настроить его. многие на шареде и им прежде всего ваша статья, как ни странно.
надо было подробнее расписать как оптимизировать mysql сервер для больше кеширования запросов, как увеличить его буфер.
как правильно сконфигурировать акселератор и хоть поверхностно сравнить их. почему eaccelerator, а не apc или memcache.
совершенно пропущен мимо ушей вебсервер. отнего тоже зависит ой как много. можно же тюнить сам апач, а на отдачу статики повесить nginx — вот вам ускорение в несколько раз сразу. либо вообще отказаться от апача и полностью перейти на nginx, благо апач не критически нужен вордпрессу и только от лени переписать реврайты под него.
воощем по серверной настройке — незачет.
а по клиентской — тут тоже особо америки не открыто. зачем так мучаться сжимая css и js, извращаясь с CSS Compress и PHP Speedy, если они только один раз подгружаются броузером и далее при серфинге по сайту беруться из кеша? ну да, сжатый и оптимизированный css (js) будет весить не 50 килобайт, а 30. только что это даст по сравнению с кучей графики которая напихана в шаблон?
вообщем, могли бы и сильнее постараться. а так больше похоже на пиар журнала чем полезную статью. угадал? :)
по сути надо было разделить настройку на серверную и клиентскую. не у ввсех есть свой сервер или впс чтобы настроить его. многие на шареде и им прежде всего ваша статья, как ни странно.
надо было подробнее расписать как оптимизировать mysql сервер для больше кеширования запросов, как увеличить его буфер.
как правильно сконфигурировать акселератор и хоть поверхностно сравнить их. почему eaccelerator, а не apc или memcache.
совершенно пропущен мимо ушей вебсервер. отнего тоже зависит ой как много. можно же тюнить сам апач, а на отдачу статики повесить nginx — вот вам ускорение в несколько раз сразу. либо вообще отказаться от апача и полностью перейти на nginx, благо апач не критически нужен вордпрессу и только от лени переписать реврайты под него.
воощем по серверной настройке — незачет.
а по клиентской — тут тоже особо америки не открыто. зачем так мучаться сжимая css и js, извращаясь с CSS Compress и PHP Speedy, если они только один раз подгружаются броузером и далее при серфинге по сайту беруться из кеша? ну да, сжатый и оптимизированный css (js) будет весить не 50 килобайт, а 30. только что это даст по сравнению с кучей графики которая напихана в шаблон?
вообщем, могли бы и сильнее постараться. а так больше похоже на пиар журнала чем полезную статью. угадал? :)
тут тогда надо цикл статей писать, а не основные (=наиболее эффективные) направления указывать
я вас огорчу. но вы написали не наиболее эффективные. отнюдь. ну конечно не считая упоминания что надо включить supercache. а gzip к вашему сведению — жрет процессор когда сжимается… и на сжатие и распаковку тоже нужно время как ни странно. тут двоякая ситуация. если инет быстрый (а он почти у всех уже быстрый) то сжатие лишь притормозит загрузку. а если инет, это модем на 56к — то тут конечно будет заначительный прирост :)
я делал оценку издержек для gzip
webo.in/articles/habrahabr/30-gzip-versus-broadband/
— оптимум наступает при 1Мб/с — далеко не у всех такой интернет :)
webo.in/articles/habrahabr/30-gzip-versus-broadband/
— оптимум наступает при 1Мб/с — далеко не у всех такой интернет :)
На шареде вам дадут настраивать фронт-энд сервер? Где?)
на своем проекте сделал примерно тоже самое месяц назад — нагрузка с 80%-100% упала до 20%-30%
единственное я еще установил nginx
единственное я еще установил nginx
1 автор живет в прошлом году. указанных команд
define( ‘ENABLE_CACHE’, true );
define('CACHE_EXPIRATION_TIME', 900);
уже нет начиная с версии 2.5 (точнее т олку от них нет)
2 пхп-спиди работает криво. после того как я установил у себя его — весь сайт (на выделенном достаточно мощном сервере с apache+nginx+eaccelerator) просто тупо вис словно его заддосили. время генерации страниц возрастало почему то в несколько раз. помогло только удаление плагина.
3 css-компрессоры работают часто криво. на первый взгляд вроде было нормально, но потом полезли глюки в разных браузерах. в итоге плюнул на это и оставил все стили несжатыми (сжимаются они nginx на лету)
define( ‘ENABLE_CACHE’, true );
define('CACHE_EXPIRATION_TIME', 900);
уже нет начиная с версии 2.5 (точнее т олку от них нет)
2 пхп-спиди работает криво. после того как я установил у себя его — весь сайт (на выделенном достаточно мощном сервере с apache+nginx+eaccelerator) просто тупо вис словно его заддосили. время генерации страниц возрастало почему то в несколько раз. помогло только удаление плагина.
3 css-компрессоры работают часто криво. на первый взгляд вроде было нормально, но потом полезли глюки в разных браузерах. в итоге плюнул на это и оставил все стили несжатыми (сжимаются они nginx на лету)
черт, не знал, что я еще не совершеннолетний :)
По поводу Speedy — попробуйте Web Optimizer. Хотя ставится не как плагин, а как отдельное приложение, но на порядок мощнее.
CSS-комрессоры обычно работаю криво на кривых CSS-файлах :)
Скорее всего, там было довольно много настроек, что и как сжимать, но определенная их комбинация «сломала» CSS. По поводу сжатия CSS/JS: gzip — наиболее оптимальный выбор
webo.in/articles/habrahabr/11-minifing-javascript/
webo.in/articles/habrahabr/07-gzip-all/
По поводу Speedy — попробуйте Web Optimizer. Хотя ставится не как плагин, а как отдельное приложение, но на порядок мощнее.
CSS-комрессоры обычно работаю криво на кривых CSS-файлах :)
Скорее всего, там было довольно много настроек, что и как сжимать, но определенная их комбинация «сломала» CSS. По поводу сжатия CSS/JS: gzip — наиболее оптимальный выбор
webo.in/articles/habrahabr/11-minifing-javascript/
webo.in/articles/habrahabr/07-gzip-all/
Если не полениться, то можно самому собрать все файлы CSS и JS в 1 файл и сжать. Также посмотреть какие плагины подгружают CSS и JS, обычно они через фильтры вешаются в шапку. И если знания позволяют, то сдлеть для себя поправить немного плагин, а стили вынести в глобальный файл со стилями (если оно того стоит). Если вы не так часто меняете темы, то это наверное в плане производительности будет лучше.
Я делал прямой перевод вордперсс 2.6.5, тем самым страница генерируется быстрее и блог кушает меньше. Это тоже можно использовать при «разгоне» своего блога.
Я делал прямой перевод вордперсс 2.6.5, тем самым страница генерируется быстрее и блог кушает меньше. Это тоже можно использовать при «разгоне» своего блога.
_http://wordpress.org/extend/plugins/really-static/, а это кто нибудь пробовал, вроде не плохая вещь.
Плагин Pure PHP Localization позволяет уменьшигть потребляемую wordpress память на 3-4 Мб!!!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разгоняем Wordpress