Comments 92
Вы заново изобрели вот эту штуку: cache.maxsite.com.ua (осторожно, автор сильно увлекается политикой!).
Ну, или вот эту: wp-cache.com
Ну, или вот эту: wp-cache.com
осторожно, автор сильно увлекается политикой!К чему это? По ссылке нет ни слова про политику.
Вторая ссылка — битая (ну или у меня не открывается). Решение по первой ссылке, как я понял, платное. Так что смотреть как оно работает я не буду. Политики не нашел, автор увлекается в первую очередь деньгами.
Способ, описанный в статье, изобретён в плагине WP Fastest Cache лет уж 100 назад. Скорее всего, кто-то неправильно настроил плагин. В нём есть фича, которая сохраняет html страницу целиком при первом обращении и в следующий раз apache (а лучше nginx) отдаёт её как статику.
Всегда считал Wordpress жертвой своей популярности.
Переписывание похожего функционала на любой фреймворк дает минимум 10-кратный рост производительности. А все из-за его модульности, сама база написана не оптимально (по сравнению если бы писать скрипт под конкретный функционал, а не под комбайн, который может превратить блог в инет-магазин в несколько кликов). В коде куча лишней логики для обработки этих виджетов.
Иногда приходится включать жесткий html-кэш средствами nGinx — это единственный выход, если сайт статический.
Переписывание похожего функционала на любой фреймворк дает минимум 10-кратный рост производительности. А все из-за его модульности, сама база написана не оптимально (по сравнению если бы писать скрипт под конкретный функционал, а не под комбайн, который может превратить блог в инет-магазин в несколько кликов). В коде куча лишней логики для обработки этих виджетов.
Иногда приходится включать жесткий html-кэш средствами nGinx — это единственный выход, если сайт статический.
Я не сторонник WP, но не думаю что вина именно в нем т.к. любой другой даже самый лучший фреймворк который годами переходит из рук в руки и обрастает новыми зависимостями и каждый из разработчиков еще добавит несколько своих оберток к одному и тому же решению… то как бы результат очевиден. Просто проект разрабатывался и администрировался недостаточно качественно, возможно из за экономии средств, а возможно (любая другая причина).
Всегда считал Wordpress жертвой своей популярности. Переписывание похожего функционала на любой фреймворк дает минимум 10-кратный рост производительности
Да хоть в 100 раз. Любой программист средней руки может написать узкоспециализированное решение, которое будет летать.
Это решение будет летать в своей специализированной задаче. И только в ней. Расширение же функционала или переориентация узкоспециализированной системы — обходятся недешево. И что намного важнее — изменения вносятся недостаточно быстро.
Согласен, стоит ещё упомянуть периодический брутфорс админ-панелей Wordpress.
Переписывание похожего функционала на любой фреймворк дает минимум 10-кратный рост производительности.
На битрикс. /sarcasm
Не совсем понятно, почему не использовать кэширование nginx, я так понимаю, он там стоял. Как раз и делает подобное, «кэширует страницы».
Хотя в данном случае — задача решена, и теперь можно спокойно переделать по уму, сделать бэкапы, себе копию, её оптимизировать или передать wp-разрабам итд. Как аварийное решение — всё правильно сделано.
a varnish поставить не пробовали?
Спасибо, интересная статья. Запишу в копилку новый термин — "топор". И если в будущем буду искать место, где в WP прикручена некая магия, белая или чёрная, то начну поиск рядом с ob_start().
А если пользователь авторизован? Без запросов к БД здесь никак, и все пользователи будут видеть страницу от имени первого авторизовавшегося.
Это руководство, как превратить динамический сайт в набор статических HTML страниц :)
Если посетители только читают посты на главной, а комментарии на каком-то Disqus, то в принципе нормально для супер быстро обходного решения. С логинами некрасиво, но лучше, чем сайт просто лежал бы. Плагины делают тоже самое, только кешируя отдельные блоки, чтобы не было таких вот косяков, как с именем пользователя.
Если посетители только читают посты на главной, а комментарии на каком-то Disqus, то в принципе нормально для супер быстро обходного решения. С логинами некрасиво, но лучше, чем сайт просто лежал бы. Плагины делают тоже самое, только кешируя отдельные блоки, чтобы не было таких вот косяков, как с именем пользователя.
В данном конкретном случае на сайте нет авторизованных пользователей. Кроме администраторов сайта. Но последние были не в счет.
еще можно cloudflare подключить попробовать на какое то время пока не придумаете лучшее решение, он частично может помочь распределить нагрузку. правда там могут повылазить другие проблемы, все зависит от плагинов, настроек самого cloudflare и т.д. Например иногда у пользователей был виден админ бар из кеша :)
Как дополнительное решение — возможно. Удивительно, но я о нем даже не вспомнил в тот момент. Но есть шанс на то, что нагрузка упадет недостаточно, если ограничится просто применением CDN
Такое бывает, если кеш настроет через задницу. CF понимает ответы сервера.
Кеш на cloudflare для сайта с аккаунтами дохлое дело. Спрятат сайт — это оригинальное предназначение.
Только время ответа от сервера повышается, так как client -> CF -> server -> CF -> client.
Вот кеш сайта без публичных юзеракков — элементарно. Достаточно вынести админку на некешируемый поддомен (тоже за CF) и поставить пароль в nginx.
Ко мне обратился владелец одного тематического новостного сайта.… У сайта есть две проблемы.… он сделан на WordPress, причем довольно небрежно.
Я, мягко говоря, не очень люблю WordPress. И, что самое плохое в этой ситуации, не очень в нем разбираюсь.
Интересно. А хозяин сайта был в курсе этого, когда к вам обращался? И если да, то почему он выбрал именно вас, и, наконец, почему вы взялись за продукт, в котором не разбираетесь и который не любите?
Я, мягко говоря, не очень люблю WordPress. И, что самое плохое в этой ситуации, не очень в нем разбираюсь.
Интересно. А хозяин сайта был в курсе этого, когда к вам обращался? И если да, то почему он выбрал именно вас, и, наконец, почему вы взялись за продукт, в котором не разбираетесь и который не любите?
Автор вроде как проясняет этот момент в посте:
И так получается, что из тех, кто не спит в эту субботнюю ночь и что-то понимает в веб-разработке у владельца есть только яВполне может быть, что автор и владелец — друзья/знакомые, и произошла ситуация «Лёха выручай, тыжпрограммист».
А хозяин сайта был в курсе этого, когда к вам обращался? И если да, то почему он выбрал именно вас...
Хозяин сайта терял деньги каждую минуту, ему было все равно кто возьмется решать его проблему. На безрыбье… как говорится.
… и, наконец, почему вы взялись за продукт, в котором не разбираетесь...
Как показала статья автора, иногда поверхностных знаний достаточно, чтобы решить проблему. Плюс, есть люди, которые не бояться принять вызов.
… и который не любите?
Не всегда задачи, над которыми мы работаем, доставляют удовольствие. Иногда нужно набраться терпения и сделать. Это называется профессионализм. Имхо.
Одно из важнейших умений — отказывать, особенно, если оказывается давление.
А так, я бы попробовал стандартные подходы: cloudflare, varnish. Но и хостеру заявку на железо оставил бы сразу же — вдруг они окажутся быстрее, чем прочие эксперименты.
Отказать было невозможно. CDN, как мне кажется, не решила бы проблему в достаточной мере. Хотя, честно говоря, я даже не успел об этом подумать. Что касается Varnish — я о нем лишь слышал краем уха и забыл. Обязательно поиграюсь с ним. Хостер «проснулся» для решения проблемы с переходом на другой тариф только с утра, в 9.00 по Москве. Как, собственно и обещал: я выяснил это в первую очередь.
На cdn можно настроить, какие странички считать статикой и кэшировать. Собственно можно так закэшировать весь сайт — https://blog.cloudflare.com/introducing-pagerules-advanced-caching/
А отказаться можно всегда. Ваше описание клиента мне лично говорит о его неадекватности и, вероятно, прижимистости.
Оба плагина с которых начался пост с озвученной в продолжении поста задачей справляются прекрасно. Вероятно проблема была в их конфигурации
Скорее, проблема в том, как сайт сделан и поддерживался. В любом случае, как мне кажется, подобные решения (плагины для кэширования) должны работать «из коробки» с настройками по умолчанию хотя бы на условные 50%. В данном случае этого не происходило. Смена настроек на рекомендуемые в различных обзорах/инструкциях и т.п. тоже не дает особого улучшения. Это я проверил уже позже. Думаю, если разобраться с сайтом, то они будут прекрасно работать. Но на разбор у меня просто не было времени.
Нормальное решение:
Ставим xhprof/xdebug (strace, если хочется тёплого лампового свечения сисколов), рандомно включаем на 2-3 страницах, видим в чем проблема.
Обычно варианта три
1. Очень большие задержки от файловой системы. В 90% случаев не чистится файловый кеш(чистим, проверяем настройки плагинов кеширования и на всякий случай ставим соответствующий крон find… -delete раз в час для файлов старше CACHE_TIME*2)
2. Очень большие задержки по сети (конкретный плагин который делает запросы по сети, а удалённый ресурс тормозит). Обычно таких плагинов 1-2, после их отключения и/или впиливания кеширования конкретно в них всё работает.
3. Конкретный плагин который кладёт БД. Смотрим запросы в mysql -e 'show full processlist', проставляем индексы ну или запиливаем кеш где логически возможно.
4. Если ни одно из вышеперечисленных, убеждаемся что машине тупо не хватает процессора, добавляем немного ядер и спокойно изучаем проблему более детально.
Эти 4 пункта покрывают 99% случаев. Остальной 1% это самое интересное и выходит за рамки этого комментария.
Когда работал в хостинге решал такие проблемы десятки раз, на потоке диагностика занимала 5-10 минут. И что WP, что битрикс, что друпал всё одно примерно и проблемы одинаковые.
Честно говоря, это всё общетехнические методы, которые мне постоянно помогали и не только в php-приложениях.
PS шаг 0. Смотрим на htop и понимаем чем конкретно занимается машина и чего ждёт вообще.
Ставим xhprof/xdebug (strace, если хочется тёплого лампового свечения сисколов), рандомно включаем на 2-3 страницах, видим в чем проблема.
Обычно варианта три
1. Очень большие задержки от файловой системы. В 90% случаев не чистится файловый кеш(чистим, проверяем настройки плагинов кеширования и на всякий случай ставим соответствующий крон find… -delete раз в час для файлов старше CACHE_TIME*2)
2. Очень большие задержки по сети (конкретный плагин который делает запросы по сети, а удалённый ресурс тормозит). Обычно таких плагинов 1-2, после их отключения и/или впиливания кеширования конкретно в них всё работает.
3. Конкретный плагин который кладёт БД. Смотрим запросы в mysql -e 'show full processlist', проставляем индексы ну или запиливаем кеш где логически возможно.
4. Если ни одно из вышеперечисленных, убеждаемся что машине тупо не хватает процессора, добавляем немного ядер и спокойно изучаем проблему более детально.
Эти 4 пункта покрывают 99% случаев. Остальной 1% это самое интересное и выходит за рамки этого комментария.
Когда работал в хостинге решал такие проблемы десятки раз, на потоке диагностика занимала 5-10 минут. И что WP, что битрикс, что друпал всё одно примерно и проблемы одинаковые.
Честно говоря, это всё общетехнические методы, которые мне постоянно помогали и не только в php-приложениях.
PS шаг 0. Смотрим на htop и понимаем чем конкретно занимается машина и чего ждёт вообще.
Отличный комментарий.
Еще по делу могу добавить к пункту 3 — помогает очень сильно объектное кеширование. Ставится redis + плагин из репо для его поддержки, и можно перестать думать некоторое время о скорости базы.
За «пункт 0» — спасибо, как-то не подумал. С остальным согласен частично. Сейчас объясню почему.
Диагностика — это хорошо, но сколько бы заняло решение? А именно оно тут требовалось в первую очередь. Я согласен, что данному конкретному сайту требуется диагностика и последующее решение «всплывших» проблем. Но делать это на «падающем» сервере — с моей точки зрения не совсем правильно. Надо сделать локальную копию и далее сидеть, думать, разбираться. Это детективная работа, на которую, повторюсь, времени не было.
А теперь по пунктам:
xhprof/xdebug — не на «живом» сайте в момент падения сервера все-таки.
1) Изначально там не было (!) никаких плагинов кэширования. Ставить cron на файловый кэш — это тоже костыль.
2) Эти плагины нужно найти, затем понять зачем они и затем принять решение как пофиксить проблему. Просто отключить их на работающем сайте не понимая на 100% что и зачем они делают в его экосистеме — шанс нажить большие неприятности.
3) Это и есть корень зла в данном конкретном случае. На нормальное решение этих проблем уйдет довольно большое количество времени.
4) Как я писал в статье такой подход был невозможен: хостер не мог оперативно увеличить выделенные сайты ресурсы.
на потоке диагностика занимала 5-10 минут.
Диагностика — это хорошо, но сколько бы заняло решение? А именно оно тут требовалось в первую очередь. Я согласен, что данному конкретному сайту требуется диагностика и последующее решение «всплывших» проблем. Но делать это на «падающем» сервере — с моей точки зрения не совсем правильно. Надо сделать локальную копию и далее сидеть, думать, разбираться. Это детективная работа, на которую, повторюсь, времени не было.
А теперь по пунктам:
xhprof/xdebug — не на «живом» сайте в момент падения сервера все-таки.
1) Изначально там не было (!) никаких плагинов кэширования. Ставить cron на файловый кэш — это тоже костыль.
2) Эти плагины нужно найти, затем понять зачем они и затем принять решение как пофиксить проблему. Просто отключить их на работающем сайте не понимая на 100% что и зачем они делают в его экосистеме — шанс нажить большие неприятности.
3) Это и есть корень зла в данном конкретном случае. На нормальное решение этих проблем уйдет довольно большое количество времени.
4) Как я писал в статье такой подход был невозможен: хостер не мог оперативно увеличить выделенные сайты ресурсы.
Спасибо за комментарий и подробную аргументацию.
Я всё-таки настаиваю, что всегда стоит нормально делать диагностику(именно поэтому я и написал комментарий), а только потом чинить причину.
Также я исхожу из того, что главная задача — восстановить работу сайта минимально рисковыми телодвижениями. Ваше решение вполне вписывается в такую постановку (оно не лишено недостатков о большинстве вам рассказали выше).
Если причина конкретный функционал, проще всего выполнить его отключение штатными средствами. Это самый понятный для владельца сайта и для исполнителя путь.
>> Диагностика — это хорошо, но сколько бы заняло решение?
В 80% случаев 5-15 минут.
>> xhprof/xdebug — не на «живом» сайте в момент падения сервера все-таки.
Не соглашусь категорически.
На живом, и именно в момент падения (иначе как узнать реальную причину?). Оверхед если не писать каждый запрос около 2%(xhprof). Конечно, писать выборочно по куке/GET-параметру, собрать 10-20 образцов, отключить.
>> Изначально там не было (!) никаких плагинов кэширования. Ставить cron на файловый кэш — это тоже костыль.
Удаление заведомо просроченного кеша это правильный механизм. Кеш должен иметь TTL, но файловый кеш в условиях шаред хостинга, это не redis.
Удаление по крону это резервный механизм который много раз спасал. Кейс конкретный: плагин WP обновился, поменялись ключи кеширования и почему-то отключилась автоматическая очистка. Один из плагинов (я уже забыл название и версию) вообще никогда не чистил просроченные элементы по которым нет попаданий. Третий тёр файлы, но не тёр пустые папки.
Если бы все плагины имели корректно работающие механизмы очистки, это конечно же было бы лишним.
>> 2) Эти плагины нужно найти, затем понять зачем они и затем принять решение как пофиксить проблему.
Часто суть проблемы проще, чем кажется на первый взгляд.
В случае в внешними ресурсами даже часто править код не надо. Достаточно просто (на время до реализации нормального решения или отлипания внешнего ресурса*) через /etc/hosts сделать так чтобы проблемный внешний ресурс резолвился в, к примеру, 127.0.0.2, а соединение с ним быстро падало (а не после 10 секунд ожидания).
Конечно, отключение плагинов всегда согласовывается. У меня очень были случаи когда плагин реально несущий. Большинство поставщиков подобных проблем это плагины курсов валют, погоды, rss/twitter и прочая подобная ерунда. Особняком стоят биржи ссылок, но с этим добром отдельная история.
>> 3) Это и есть корень зла в данном конкретном случае
Да, такие проблемы иногда не решаются простыми способами. Но посмотрите внимательно на БД, вдруг после череды обновлений в таблицах нет в сравнении с новой чистой установкой нужных индексов или чего-то подобного?
Так или иначе, успехов в делах и новых интересных задач!
*) в зависимости от уровня перфекционизма.
Я всё-таки настаиваю, что всегда стоит нормально делать диагностику(именно поэтому я и написал комментарий), а только потом чинить причину.
Также я исхожу из того, что главная задача — восстановить работу сайта минимально рисковыми телодвижениями. Ваше решение вполне вписывается в такую постановку (оно не лишено недостатков о большинстве вам рассказали выше).
Если причина конкретный функционал, проще всего выполнить его отключение штатными средствами. Это самый понятный для владельца сайта и для исполнителя путь.
>> Диагностика — это хорошо, но сколько бы заняло решение?
В 80% случаев 5-15 минут.
>> xhprof/xdebug — не на «живом» сайте в момент падения сервера все-таки.
Не соглашусь категорически.
На живом, и именно в момент падения (иначе как узнать реальную причину?). Оверхед если не писать каждый запрос около 2%(xhprof). Конечно, писать выборочно по куке/GET-параметру, собрать 10-20 образцов, отключить.
>> Изначально там не было (!) никаких плагинов кэширования. Ставить cron на файловый кэш — это тоже костыль.
Удаление заведомо просроченного кеша это правильный механизм. Кеш должен иметь TTL, но файловый кеш в условиях шаред хостинга, это не redis.
Удаление по крону это резервный механизм который много раз спасал. Кейс конкретный: плагин WP обновился, поменялись ключи кеширования и почему-то отключилась автоматическая очистка. Один из плагинов (я уже забыл название и версию) вообще никогда не чистил просроченные элементы по которым нет попаданий. Третий тёр файлы, но не тёр пустые папки.
Если бы все плагины имели корректно работающие механизмы очистки, это конечно же было бы лишним.
>> 2) Эти плагины нужно найти, затем понять зачем они и затем принять решение как пофиксить проблему.
Часто суть проблемы проще, чем кажется на первый взгляд.
В случае в внешними ресурсами даже часто править код не надо. Достаточно просто (на время до реализации нормального решения или отлипания внешнего ресурса*) через /etc/hosts сделать так чтобы проблемный внешний ресурс резолвился в, к примеру, 127.0.0.2, а соединение с ним быстро падало (а не после 10 секунд ожидания).
Конечно, отключение плагинов всегда согласовывается. У меня очень были случаи когда плагин реально несущий. Большинство поставщиков подобных проблем это плагины курсов валют, погоды, rss/twitter и прочая подобная ерунда. Особняком стоят биржи ссылок, но с этим добром отдельная история.
>> 3) Это и есть корень зла в данном конкретном случае
Да, такие проблемы иногда не решаются простыми способами. Но посмотрите внимательно на БД, вдруг после череды обновлений в таблицах нет в сравнении с новой чистой установкой нужных индексов или чего-то подобного?
Так или иначе, успехов в делах и новых интересных задач!
*) в зависимости от уровня перфекционизма.
Спасибо и вам, я кое-что узнал и от вас.
По поводу недостатков моего решения — я полностью согласен, более того, я их полностью осознавал. И, действительно, один из главных факторов принятия конкретно этого решения то, что оно не могло навредить. Вне зависимости от того, что именно происходит внутри. Плюс оно было быстрым.
>> xhprof/xdebug — согласен, ляпнул не подумав.
За то, что плагины WP работают как придется и точной уверенности в том, что именно и как они делают нет, я их и не люблю.
Про внешние запросы — соглашусь, но мне все-таки не нравятся такие решения. Плюс в данном случае дело не в них.
С обращениями к БД, конечно, нужно разобраться. Но за полчаса сделать это качественно, как мне кажется, невозможно. Мое решение — временный экстренный костыль, я полностью признаю это.
И напоследок, самое забавное. Вам, думаю, понравится. Я скачал чистый дистрибутив той версии WP, что стоит на этом сайте. И сделал поиск изменений. В тех местах, где, по идее, хранятся «системные» файлы WP. Его «ядро». В которых, как мне кажется, вообще не должно быть правок. В них кто-то ковырялся. И сильно. Как, думаю, вы понимаете, это сразу ставит под сомнение штатность работы всей системы. И, соответственно, эффективность нормальных решений.
Вам тоже всяческих удач!
По поводу недостатков моего решения — я полностью согласен, более того, я их полностью осознавал. И, действительно, один из главных факторов принятия конкретно этого решения то, что оно не могло навредить. Вне зависимости от того, что именно происходит внутри. Плюс оно было быстрым.
>> xhprof/xdebug — согласен, ляпнул не подумав.
За то, что плагины WP работают как придется и точной уверенности в том, что именно и как они делают нет, я их и не люблю.
Про внешние запросы — соглашусь, но мне все-таки не нравятся такие решения. Плюс в данном случае дело не в них.
С обращениями к БД, конечно, нужно разобраться. Но за полчаса сделать это качественно, как мне кажется, невозможно. Мое решение — временный экстренный костыль, я полностью признаю это.
И напоследок, самое забавное. Вам, думаю, понравится. Я скачал чистый дистрибутив той версии WP, что стоит на этом сайте. И сделал поиск изменений. В тех местах, где, по идее, хранятся «системные» файлы WP. Его «ядро». В которых, как мне кажется, вообще не должно быть правок. В них кто-то ковырялся. И сильно. Как, думаю, вы понимаете, это сразу ставит под сомнение штатность работы всей системы. И, соответственно, эффективность нормальных решений.
Вам тоже всяческих удач!
Я всё-таки настаиваю, что всегда стоит нормально делать диагностику(именно поэтому я и написал комментарий), а только потом чинить причину.Особенно замечательно выглядит такой подход у врачей, когда пациент стонет от боли. Понятно, что можно потерять симптоматику, но все-таки лучше (с точки зрения пациента) вначале обезболить, а уж потом искать причину болей. :-)
Мне как-то кажется, что пары часов ожидание кетанова в приемном покое вам хватит, чтобы понять, как оно выглядит с точки зрения пациента.
Спасибо, посмеялся.
А по сути дела тут важно примерно понимать где проблема. Ну вы же не пойдёте к стоматологу, если у вас болит нога или не будете заливаться анальгетиками при занозе в руке.
А с сайтом непонятно, он, к сожалению(или к счастью пока), не говорящий.
А по сути дела тут важно примерно понимать где проблема. Ну вы же не пойдёте к стоматологу, если у вас болит нога или не будете заливаться анальгетиками при занозе в руке.
А с сайтом непонятно, он, к сожалению(или к счастью пока), не говорящий.
Ну я тоже не настолько говорящий, чтобы отличить почечную колику от печеночной или их обоих от атипичного аппендицита.
Повторюсь, пары часов личного ожидания в приемном покое — достаточно, чтобы понять, что стоит обезболить сразу.
В рассматриваемом примере критично время. Если вы верите, что исследования быстрее приведут сайт к работоспособности — исследуйте. Но… «вскрытие показало, что пациент умер от вскрытия».
Брутто-методы плохи всем, кроме одного — они решают проблему за прогнозируемое время. А лечение причины — может быть быстрее, а может быть и сильно медленнее. Поэтому я в своей жизни не раз сталкивался с ситуаций: директивно прекращаем искать/лечить причину и закрываем ошибку брутто-методом. А причину найдем и исправим уже без спешки, в с спокойной обстановке.
И чем больше денег мы теряем на простое — тем лучше использование брутто-методов.
В пределе — представьте, что каждую лишнюю (по сравнению с брутто-методом) минуту простоя вам оплачивать из своего кармана?
А что хочется всегда найти причину и исправить именно её — это правда. Особенно когда остались последние 17 минут работы ноута, а ты лежишь в канаве у полотна РЖД и пригибаешь голову от пролетающих мимо «сапсанов». Ну на то и опыт, чтобы дать себе по рукам и сделать брутто-способом.
Повторюсь, пары часов личного ожидания в приемном покое — достаточно, чтобы понять, что стоит обезболить сразу.
В рассматриваемом примере критично время. Если вы верите, что исследования быстрее приведут сайт к работоспособности — исследуйте. Но… «вскрытие показало, что пациент умер от вскрытия».
Брутто-методы плохи всем, кроме одного — они решают проблему за прогнозируемое время. А лечение причины — может быть быстрее, а может быть и сильно медленнее. Поэтому я в своей жизни не раз сталкивался с ситуаций: директивно прекращаем искать/лечить причину и закрываем ошибку брутто-методом. А причину найдем и исправим уже без спешки, в с спокойной обстановке.
И чем больше денег мы теряем на простое — тем лучше использование брутто-методов.
В пределе — представьте, что каждую лишнюю (по сравнению с брутто-методом) минуту простоя вам оплачивать из своего кармана?
А что хочется всегда найти причину и исправить именно её — это правда. Особенно когда остались последние 17 минут работы ноута, а ты лежишь в канаве у полотна РЖД и пригибаешь голову от пролетающих мимо «сапсанов». Ну на то и опыт, чтобы дать себе по рукам и сделать брутто-способом.
Поверьте, ожидание в приёмном покое у меня тоже было.
Я проклял всё. Но в принципе я уже потом всё обдумав понял что могло быть и хуже.
> Если вы верите, что исследования быстрее приведут сайт к работоспособности — исследуйте
Мой опыт потокового решения подобных проблем с популярными CMS (я думаю что это точно больше сотни кейсов только по WP) говорит о том, что диагностика важнее. Коллеги даже для SLA считали — в среднем 7 минут диагностика, полное решение 10 (разница небольшая, так как в основном даже правки по коду не нужны).
> И чем больше денег мы теряем на простое — тем лучше использование брутто-методов.
Не всё так однозначно.
Конечно, впилить костыль в результате которого закешируется страничка с админским айдишником сессии это намного лучше.
«Проблема решена — решена. А то что теперь рандомный пользователь может делать с сайтом что угодно, об этом в задаче не было.»
Я сейчас работаю с ресурсом(Alexa top 2k, alexa_RU top 100), где минутный простой стоит очень дорого, а косяк в результате которого будут слиты наружу пользовательские данные — ещё дороже.
Все такие истории это баланс скорости и рисков. Вот и всё.
ЗЫ ах эти времена с кнопочными телефонами и midp-ssh
Я проклял всё. Но в принципе я уже потом всё обдумав понял что могло быть и хуже.
> Если вы верите, что исследования быстрее приведут сайт к работоспособности — исследуйте
Мой опыт потокового решения подобных проблем с популярными CMS (я думаю что это точно больше сотни кейсов только по WP) говорит о том, что диагностика важнее. Коллеги даже для SLA считали — в среднем 7 минут диагностика, полное решение 10 (разница небольшая, так как в основном даже правки по коду не нужны).
> И чем больше денег мы теряем на простое — тем лучше использование брутто-методов.
Не всё так однозначно.
Конечно, впилить костыль в результате которого закешируется страничка с админским айдишником сессии это намного лучше.
«Проблема решена — решена. А то что теперь рандомный пользователь может делать с сайтом что угодно, об этом в задаче не было.»
Я сейчас работаю с ресурсом(Alexa top 2k, alexa_RU top 100), где минутный простой стоит очень дорого, а косяк в результате которого будут слиты наружу пользовательские данные — ещё дороже.
Все такие истории это баланс скорости и рисков. Вот и всё.
ЗЫ ах эти времена с кнопочными телефонами и midp-ssh
Если вы гарантируете SLA и SLA устраивает заказчика — разумеется, лучше лечить причину. Но у меня — совсем не сайты. Да. конечно, часто кажется, что можно найти и исправить причину за час-два. И двух третях случаев — это правда. А в остальных…
Ну как пример. Одна из ошибок, вылезших из генеральского эффекта, была найдена вообще через полгода (недели две чистого времени на ловлю). После обнаружения было рассчитано, что шансы на проявление — 1 раз в 3 года. Вылезла она на стенде за пару часов до перехода к опытной эксплуатации. Вы думаете стоило ждать её нахождения и ликвидации? :-) А брутто-методом я её закрыл за 5 минут.
Так что может быть в «популярных CMS» и вправду ошибки простые и быстро устранимые, но переносить это на весь остальной софт не стоит.
А впилить вторичную ошибку при брутто-методе — шансов меньше. То есть та ситуация, когда лекарство хуже болезни — оно больше при лечении причин. Брутто-методы обычно как-то безопаснее.
Ну как пример. Одна из ошибок, вылезших из генеральского эффекта, была найдена вообще через полгода (недели две чистого времени на ловлю). После обнаружения было рассчитано, что шансы на проявление — 1 раз в 3 года. Вылезла она на стенде за пару часов до перехода к опытной эксплуатации. Вы думаете стоило ждать её нахождения и ликвидации? :-) А брутто-методом я её закрыл за 5 минут.
Так что может быть в «популярных CMS» и вправду ошибки простые и быстро устранимые, но переносить это на весь остальной софт не стоит.
А впилить вторичную ошибку при брутто-методе — шансов меньше. То есть та ситуация, когда лекарство хуже болезни — оно больше при лечении причин. Брутто-методы обычно как-то безопаснее.
ЗЫ ах эти времена с кнопочными телефонами и midp-sshДико туплю — это вы к чему? Заодно — объясните, почему не стоит обезболивать занозу — это я тоже не понял.
Кушать кетанов при занозе это очень странно, по двум причинам: 1. чаще всего проще вынуть и без врача и она хотябы перестанет мешать дойти до врача и вызывать боль при прикосновении 2. есть местные антибиотики.
>> Дико туплю — это вы к чему?
Ваш комментарий про полевые условия как раз напомнил мне «те времена».
>> Дико туплю — это вы к чему?
Ваш комментарий про полевые условия как раз напомнил мне «те времена».
У нас высокоточный GPS, так что полевые испытания идут регулярно и в очень интересных местах.
Логика у вас забавная, судя по вашим текстам, вынимать надо обязательно с болью. Или с чем-то, чего дома обычно не бывает, типа рогатой ампулы с четырехлористым углеродом. :-) Мы уж лучше по старинке. Если болит так, что нужен кетанов, то сначала обезболить, потом к врачу.
Логика у вас забавная, судя по вашим текстам, вынимать надо обязательно с болью. Или с чем-то, чего дома обычно не бывает, типа рогатой ампулы с четырехлористым углеродом. :-) Мы уж лучше по старинке. Если болит так, что нужен кетанов, то сначала обезболить, потом к врачу.
Хм. На самом деле кэширования страниц с админскими данными не было. И, более того, не могло быть.
UFO just landed and posted this here
+1 еще и на php сэкономить можно таким образом.
Да, это решение. При условии (если ошибаюсь — поправьте), что нигде в коде не открывается сессия. Что нужно искать и проверять. А если такое есть — то исправлять и тестировать. Не уверен, что такой подход был бы быстрее. Про «правильность» я ничего не говорю — не до того было. Сейчас, за чашкой чая можно, конечно, выбрать оптимальный вариант. Но за вариант — спасибо!
Каждый раз читая заметку, «я не умею готовить WP, но вот этот костыль мне помог», недоумеваю, почему не прочитать нормальные инструкции как настроить WP, чтобы он держал любой более менее разумный траф.
При чем начать можно с базовой статьи: codex.wordpress.org/High_Traffic_Tips_For_WordPress
У меня 100К посетителей и более 1Tb трафа в день WP держит без намека на перегрузку.
При чем начать можно с базовой статьи: codex.wordpress.org/High_Traffic_Tips_For_WordPress
У меня 100К посетителей и более 1Tb трафа в день WP держит без намека на перегрузку.
Странно читать подобные комментарии. Где характеристики сервера? Какое ПО используется? И тд.
Комментарий про это:
Вторая проблема — он сделан на WordPressЯ не считаю это проблемой. Есть сайты на WP вроде www.bbcamerica.com с гораздо большей нагрузкой, чем мой…
Ну, базовая статья, если коротко, говорит: «не забудьте правильно подобрать и настроить сервер. Поставьте плагин кэширования. Следите за сайтом». Все это прекрасно, но в моем случае это было «пить «Боржоми», когда почки отказали». Это должны были знать, в первую очередь, те, кто довел сайт до его текущего состояния. Разумеется, сайту требуется оптимизация.
То, что ваш проект держит 100К посетителей в день — это хорошо. Но, если не секрет, на какой конфигурации сервера?
То, что ваш проект держит 100К посетителей в день — это хорошо. Но, если не секрет, на какой конфигурации сервера?
В вашем случае я бы действовал так:
Включил в WP режим обслуживания.
Поставил на выбор wp-super-cache или w3-total-cache
Включил в кеширование в статитку.
Выключил режим обслуживания.
Может потому что 99% проектов на вп это чистый говнокод с кучей костылей? Речь же не идет о приготовлении, вопрос в том как из горелой курицы сделать хорошую и вкусную, а это практически невозможно ;) А вообще делать на вп крупный проект в любом случае один геморой и гораздо эффективнее взять более серьезный инструмент
Вы поставили плагин для кеширования, и даже не разобрались как именно он кеширует. Все популярные плагины кеширования для WP имею 2 режима кеширования: статическое и динамическое. Статическое предполагает как раз описанный вами способ с хешированием и прочим, но требует либо Apache(внесение изменений в .htaccess), либо правку конфига Nginx. Динамическое кеширование как раз работает так, чтобы какой-то фарш можно было запустить на определенном уровне WP(например, логику GeoIP), и только затем отдача такого же статического контента. Второй способ более ресурсоемок, но все равно достаточно быстрый. Первый, когда отдается статика, понятное дело быстрее.
Чаще всего все тормоза WP связаны с большим количеством кривых плагинов. Возможно, какой-то плагин вообще ломал весь флоу в процессе кеширования, возможно просто вешал БД.
Я не говорю, что WP это супер CMS, я говорю, что каждую более менее сложную CMS нужно уметь правильно готовить. Попробуйте постройте приложение уровня и функционала WP — и оно точно так же будет задыхаться от наплыва пользователей.
Основная проблема WP это то, что у него почти нулевой порог вхождения. А поэтому для него пишутся какие-то универсальные плагины для того же кеширования. А написать грамотное кеширование для WP задача весьма нетривиальная, как и для любого другого приложения.
К слову, как-то раз я занимался рефакторингом одного проекта, который писали человек 5 в разные время. В итоге было проще все переписать заново. Стоит ли говорить, что на такой же конфигурации сервера заново написанный проект чувствует великолепно, даже без супер глубокого и продвинутого кеширования.
С общими принципами кэширования я, вроде бы, знаком. И рассчитывал, что упомянутые мной плагины быстро реализуют на сайте эти принципы. Чего, однако, не произошло. Причины — дело второе. На игры с настройками времени особенно не было: надо было оперативно решить проблему с наименьшими потерями. Кстати, как я потом уже проверил, переключение разных режимов кэширования в настройках этих плагинов ничего не дает. Думаю, причина в том, что где-то во внутренностях есть большой, сделанный кем-то, кто обеспечивал работу проекта ранее, косяк. Который, собственно, мешает нормальной работе этих плагинов. Его еще нужно найти. Опыты, как мне кажется, желательно ставить на локальной копии, а не на живом сайте с десятками тысяч посетителей.
«Кривых» плагинов там установлено море. Не мной. Более того, я даже примерно не знаю зачем установлены многие из них. Основная общая проблема — переизбыток запросов к БД, да.
По поводу «Попробуйте постройте приложение уровня и функционала WP — и оно точно так же будет задыхаться от наплыва пользователей» я не согласен. Во-первых, это уже теоретизирование с привкусом «сперва добейся», а во вторых я уверен, что возможно создать более разумную систему с не меньшими возможностями. Насчет «уметь готовить» — согласен, в чем и признался в самой статье.
Про то, что нужно разумно подходить к разработке, а всякие доработки по принципу «работает же!» — зло, я абсолютно согласен.
«Кривых» плагинов там установлено море. Не мной. Более того, я даже примерно не знаю зачем установлены многие из них. Основная общая проблема — переизбыток запросов к БД, да.
По поводу «Попробуйте постройте приложение уровня и функционала WP — и оно точно так же будет задыхаться от наплыва пользователей» я не согласен. Во-первых, это уже теоретизирование с привкусом «сперва добейся», а во вторых я уверен, что возможно создать более разумную систему с не меньшими возможностями. Насчет «уметь готовить» — согласен, в чем и признался в самой статье.
Про то, что нужно разумно подходить к разработке, а всякие доработки по принципу «работает же!» — зло, я абсолютно согласен.
Имхо, почти нулевой уровень вхождения не проблема, а киллер-фича WP, как и PHP в целом.
Кстати, проблема с недогрузкой скриптов вероятно связана с тем, что у загрузчика скриптов может быть свой уровень буфера, можно проверить их количество через ob_get_level()
Походу НЛО что-то не то кушало на НГ, отравилось и понаприглошало всякую х… мнэ… молодых и бурно развивающихся авторов.
И вам, дорогой мой, всего хорошего!
Ага, и тут выходите Вы с 0 публикаций и кармой -28, весь в белом и всех разоблачаете!
Ну, правда, посты «я ничо не умею в этой теме, и тут надо что-то сделать, я что-то сделал, что придумал, и вот, смотрите, написал про это пост на Хабр!» это все же как бы совсем не уровень Хабра.
Особенность исчисления кармы на хабре в том, что оно не стимулирует писать мало, но хорошо.
Зато стимулирует писать много в стиле «как я научился печатать буквы и побежал становиться Редактором GT».
У меня были статьи, но один неудачный комментарий — и все труды насмарку.
Зато стимулирует писать много в стиле «как я научился печатать буквы и побежал становиться Редактором GT».
У меня были статьи, но один неудачный комментарий — и все труды насмарку.
WP по умолчанию хранит черновики постов в базе и еще кучу всякого мусора.
Возможно стоит немного почистить и саму базу в 2Гб
Возможно стоит немного почистить и саму базу в 2Гб
собственно nginx fastcgi cache + fastcgi_cache_lock on; все решает.
А как твик для базы — перевести на innodb (если там старая myisam), далее настроить движок innodb в конфигах MariaDB & задать ключ wp_options для autoload, так как это поле почему-то не ключевое, но все время в запросах и там всего 2 значения.
Вы не смотрели в сторону кеширования на стороне именно веб-сервера (даже на хабре были посты, вроде такого)? Конечно, готовить кеш надо уметь, но, если не очень разбираться в WP, вам будет проще сделать кеш именно на веб-сервере.
Второй вариант — то же сделать через услуги сетей CDN, того же айри (не рекламы ради, просто общался с положительным результатом). Их работа как раз сделать так, чтобы до вашего сервера прилетало меньше запросов, а больше — отдавалось из их кешей.
Второй вариант — то же сделать через услуги сетей CDN, того же айри (не рекламы ради, просто общался с положительным результатом). Их работа как раз сделать так, чтобы до вашего сервера прилетало меньше запросов, а больше — отдавалось из их кешей.
было интересно почитать, спасибо.
Повествуется как батин жареный суп.
"Когда-то давно, когда я читал мануал к PHP я встречал там функцию «ob_get_contents()». Я никогда ей не пользовался, но тут она пригодилась." — что сказать если даже не читая документации к языку человек умудрился каким то чудом производительность улучшить и почему взялся что-то оптимизировать вобще.
То заголовок видимо нужно было более захватывающий писать и не на хабре, тут такую смелость наверное не оценят.
Хороший пример из жизни об использовании
ob_get_contents() и exit(), спасибо!
Вы поймали себя в свои же сети. Владелец не позволит Вам отключить этот "топор", т.к. с его точки зрения все работает хорошо. Но Вы заложили "бомбу" замедленного действия, которая сработает в самый не подходящий момент… Простой пример: владелец добавляет на сайт магазин покупок, и Ваш статик кеш все сломает.
Возможно я просто упустил информацию, может вы сами писали или кто-то уже спросил про это, но, может после активации плагинов кэширования вы проверяли будучи авторизованным пользователем?
В настройках по умолчанию авторизованным пользователям отдается не закэшированная страница, следовательно не авторизованные пользователи видели закэшированные страницы и все было хорошо.
Здорово то, что автор оперативно решил задачу в live-режиме, это здорово!
В настройках по умолчанию авторизованным пользователям отдается не закэшированная страница, следовательно не авторизованные пользователи видели закэшированные страницы и все было хорошо.
Здорово то, что автор оперативно решил задачу в live-режиме, это здорово!
Пост шикарный! Всегда интересны истории фаст-фиксов на огне!)
Пиши исчо!
Пиши исчо!
плагины эти, о которых вы писали в начале статьи (я просто не читал ее до конца, хочу по этой теме сказать) — fastcache & supercache — они держат миллионы хитов в сутеки. да какие сутки, в минуты! при правильнрой настройке естественно.
потому что они кешируют сайты в статику (в html, можно сразу пожатый), а там уже апач может выдать сотни тысяч, nginx миллионы…
из всех этих посетителей реальная динамика нужна десятке, в худших случаях сотне пользователей. они определяются по куке и их мы шлем бекенд, парралельно они же формируют в кеше html-ки, которые и отдаются потом обычным «юзерам» (сотнями тысяч/час).
подобные плагины есть в любой более-менее вменяемой cms… и изучать ее, часто, даже и не нужно — достаточно понимать основные принцыпы…
бывают конечно и тяжелые случаи — форумы, активно генерируемые камменты к постам и т.п. и даже этих, иногда, можно кешировать хоть на 15 сек — уже профит огромный…
не знаю, я наверное повторился… но тем не менее…
потому что они кешируют сайты в статику (в html, можно сразу пожатый), а там уже апач может выдать сотни тысяч, nginx миллионы…
из всех этих посетителей реальная динамика нужна десятке, в худших случаях сотне пользователей. они определяются по куке и их мы шлем бекенд, парралельно они же формируют в кеше html-ки, которые и отдаются потом обычным «юзерам» (сотнями тысяч/час).
подобные плагины есть в любой более-менее вменяемой cms… и изучать ее, часто, даже и не нужно — достаточно понимать основные принцыпы…
бывают конечно и тяжелые случаи — форумы, активно генерируемые камменты к постам и т.п. и даже этих, иногда, можно кешировать хоть на 15 сек — уже профит огромный…
не знаю, я наверное повторился… но тем не менее…
Интересно расписал, завис на картинке рабочего стола: искал дубли иконок, тип аля «Найди пару»
Автор молодец! Для данной ситуации и при текущем наборе инструментов я бы поступил так же!
Любопытная статья. На месте автора мог оказаться админ любого другого контент-ориентрованного сайта. Если, предположим, сайт был бы в разы популярнее? Или написан не на WP?..
Я для таких случаев знаю два решения: Akamai и Auto Scaling у Амазона. Первый — мощный кэширующий сервис, предоставляющий, в простейшем случае, все то же кэширование статического контента. Ну и тьму других плюшек e.g. защита от ddos, FTP хранилища, фильтрация по geoip признаку и все в таком же духе.
Со вторым понятнее: выросла нагрузка — ферма виртуалок тоже выросла, нагрузка упала — ферма уменьшилась.
Интересно было бы узнать, к автору часто по этой проблеме обращаются?
Я для таких случаев знаю два решения: Akamai и Auto Scaling у Амазона. Первый — мощный кэширующий сервис, предоставляющий, в простейшем случае, все то же кэширование статического контента. Ну и тьму других плюшек e.g. защита от ddos, FTP хранилища, фильтрация по geoip признаку и все в таком же духе.
Со вторым понятнее: выросла нагрузка — ферма виртуалок тоже выросла, нагрузка упала — ферма уменьшилась.
Интересно было бы узнать, к автору часто по этой проблеме обращаются?
Автор молодец, что справился и решил проблему быстро, как и заказывали. Плохо, что к решению проблемы привлекли неспециалиста… да и вообще там много стратегических ошибок хозяина сайта, которые привлекли к пожару, который пришлось тушить в авральном порядке.
Но. В итоге я проголосовал против статьи. Ничего личного, все молодцы — но я хотел бы на этом сайте читать про умные решения и не очень хочу читать про то, как неспециалисты тушат пожары. И может быть я пойду против мнения большинства, но мне жаль видеть эту статью в топе.
Но. В итоге я проголосовал против статьи. Ничего личного, все молодцы — но я хотел бы на этом сайте читать про умные решения и не очень хочу читать про то, как неспециалисты тушат пожары. И может быть я пойду против мнения большинства, но мне жаль видеть эту статью в топе.
В идеальном мире адекватный заказчик привлек бы специалиста, и дал бы ему время, хостинг, и любой другой необходимый ресурс, которых в идеальном мире достаточно.
В реальном мире постоянно находишь себя в ситуациях нехватки знаний и/или времени, и необходимостью выбора из плохих вариантов.
В реальном мире постоянно находишь себя в ситуациях нехватки знаний и/или времени, и необходимостью выбора из плохих вариантов.
Плохо, что к решению проблемы привлекли неспециалиста...
так судя по описанию внутренностей сайта, это основная стратегия заказчика)))
Мне очень понравилась статья. Я сам был в подобной экстренной ситуации. Когда сайт упал в ненужный момент. И пришлось поднимать собственными костылями.
Автор молодец.
Автор молодец.
Sign up to leave a comment.
16 тонн. Как я спасал гибнущий под нагрузкой сайт на WordPress, имея весьма поверхностные знания в области этой CMS