Комментарии 7
Спасибо за интересную и поучительную историю. Очередной раз убеждаюсь, что плагины не всегда являются панацеей на все задачи. Иногда нужно и ручками что-то прописывать.
Да, с плагинами нужно держать ухо востро. Их можно использовать, но нужно понимать как работают и какие еще дополнительные эффекты приносят. В каких-то ситуациях могут выручить, например, как с этим проектом из поста, на самом старте магазина заказчик все сам делал, без бюджета на разработку. Но когда проект становится большой и появляется серьезная нагрузка, неизвестные плагины могут устроить проблем.
То есть на каких-то этапах, когда ограничен бюджет, можно по-быстрому на плагинах "слепить", но с ростом проекта, лучше потихоньку приводить его в порядок, постепенно убирая лишнее и корректируя работающие куски.
Сразу в голову пришла мысль посмотреть диагностику БД. Обычно «топ самых дорогих (по cpu/ram/storage) запросов» сразу показывает, что и откуда надо выпилить. Так и недостающие индексы находятся, и кандидаты на кэш, и даже просто криво написанное.
Ох уж этот вордпресс. Напоминает как будто на пустыре построили ну допустим киоск роспечать. А потом к нему приделали лоток с овощами. А потом цветочный киоск. Шаурмяченую. Хостел. И через полгода там такой шанхай, трущобы и фавелы, что черт ногу сломит. И еще морду набьют если зайдешь не туда.
Имел я как-то опыт работы с этим монстром, примерно в таких же исходных, что описывает ТС. Плюс там еще автор был одержим понапихать в один проект как можно больше технологий, поэтому плюсом шла дополнительная базёнка монгоДБ, некоторые места фронта были написаны на ангуляре, и где-то сбоку торчала интеграция с 1С. Все обильно утыкано плагинами трех сортов: скачанные, самодельные и скачанные но потом руками поправленные и никому не известные где и как.
И вот автор как то быстро куда-то уволился, он вообще энтузиаст, а меня послали сопровождать тот шанхай. Тормозило оно знатно. Как на бэке так и на фронте. Периодически что-нибудь отваливалось. Я еще своих пару плагинов написал и поубирал лишние бд, прежде чем сам уволился. Потом они там вроде как заказали на стороне нормальный интернет-магазин.
Я правильно понимаю, вы пришли все пушистые, продали клиенту сопровождение и обслуживание, проработали маркетинговую компанию, судя по приросту заказов неплохую, но не удосужились собрать хоть какую-то статистику по производительности системы, посмотреть что куда ходит у вас, сколько запросов в БД на странице, не? Не говорю даже про какое либо минимальное нагрузочное тестирование.
А судя из текста у вас есть БД, в ней таблица раздутая по размерам с непонятными логами и это у вас не вызвало ни малейшего вопроса?
Мне просто интересен ход ваших действий при приёмке проекта в работу.
Рекламой сам заказчик занимается, у них в соц.сетях хорошие по размеру группы и для емейл рассылок база большая. Мы только дизайн и разработку делаем. Нагрузку проверяли, но не детально - по метрикам хостинга треть ресурсов использовалось в спокойные дни, проблем с ней не было. И несколько подобных акций пережил сайт без проблем с падениями. Беда случилась, когда БД заполнилась логами достаточно, чтоб увеличить нагрузку до критической. Согласен, можно было и в обычное время заметить лишние записи в БД, но случилось так, что не заметили и поэтому в авральном режиме пришлось разбираться. В вордпрессе, особенно когда куча плагинов установлено, не так просто убрать лишние запросы к базе – все переплетено между собой и просто так отключить лишнее не получится без доработок и переделок.
Внесу свою лепту. Есть достаточно известный и популярный плагин.
All-In-One Security (AIOS) – Security and Firewall
Этот тоже любит раздувать базу логами. Я как то при анализе расходуемого места обнаружил, что у меня есть несколько БД от сайтов с 3-5 страницами, которые раздуты до 5-6 гигов. При этом нигде в настройках никак не ограничить время хранения логов
Публикации
Пьеса о неудачном запуске предзаказа