Одна история оптимизации сайта, и как не надо делать? И почему jetcache + filter viever - это путь в Вальгалу ? Часть вторая.
Запись опубликована ·
3 890 переглядів
Порадовался я тут значит этой истории
Сделал промочку на вторую часть... И... Все опять накрылось медным тазом.
На следующий день после того как магазин зажил полной грудью он опять начал тупить при чем жестко.
И если фронт работал кое-как, то вот товары обновить возможности не было никакой.
Но давайте с самого начала.
С чем мы столкнулись.
Магазин на 65 000 товаров, самая большая категория на 10к товаров, у каждого товара 5-8 атрибутов. Из бредомодулей стоит jetcache и filterviewer.
Жил себе и жил этот магазин на обычном виртуальном хостинге, пока не начал потреблять порядка 30% физического сервера хостинга, превышая в пике допустимый лимит нагрузки пакета в 10 раз.
Когда я первый раз увидел этот проект, у меня было однозначное мнение, что это мертвый проект, так как скорее всего какой-то сеошник посоветовал сделать вот эти все посадочные под все со всеми и глаз пал на FV.
В чем печаль ситуации. Этот фильтр генерит явную ссылку на страницы фильтра в формате все со всеми атрибуты, опции, и еще вот это в наличии и по рейтингу. И вместо того чтобы сделать явными только посадочные, а остальные страницы спрятать за js-редирект, а еще бы и закрыть по какому то признаку в robots, как тот же ?mfp= в Мегафильтр, viewer такой возможности не дает. Так как это же сео, это посадочные, это сеошники так сказали.
В итоге боты прриходят и застряют в этом болоте из сотен тысяч мусорных страницы фильтра, вместо того чтобы приходить на нормальные страницы товаров, категорий и руками созданные размеченные посадочные с адекватными тайтлами и контентом. Ща прибегут хейторы и скажут йода опять несет чушь. Предлагаю любому хейтеру показать мне проект, где подобный финт ушами от вивер фильтра дали хотя бы +200 уников из органического поиска.
И еще, viver говорит, что ну че там - ну у меня ж ноиндекс на второй третий уровень вложенности. Это все прекрасно и волшебно, но для того чтобы увидеть этот ноиндекс все равно надо сгенерить страницу, а их я напомню несколько сот тысяч. На которые пришли гугл, яндекс и бинг бот.
Как говорит один мой знакомый, тут никакого сервера как у Пентагона не хватит.
Ну и поверху всей этой красоты еще стоит jetcache, который создает видимость спокойствия. Не ну а че.. Ну из файлика же быстро html подгрузился по готовому кешу. А то что 3+ секунды загрузка на холодную. Так ну то фигня - самое главное же из кеша быстро, все 5 страниц которые туда попали и еще 50 000 страниц фильтра, а нормальный контент как был туп так и остался. Как грузилась категория на 10 000 товаров 5-6 секунд так и грузится (там еще нон стоп обновления товаров) и весь jetcache ходит по бороде так сказать.
Но вот ложное чувство нормализации процесса давал.
Ок. что делать? Перенесли сайт на впс - стало хуже. Так как на шареде, можно было забираться по уши в ресурсы соседей, а тут два ядра - и только они.
И в этот момент владелец магазина обратился ко мне с вопросом, что же таки куда.
И самое удивительное, он признал с первого раза всю дичь логики работы фильтер вивер и согласился его убрать. И поменять на OcFiltere от @SooR.
После настройки серванта, после простановки индексов в базу, решения вопроса с кешами, выжигания filterviever и jetcache - у нас вроде нормализовалась работа. И получились вот те графики которые были в первой статье. Но это была только прелюдия....
Вчера опять проект лег в момент попытки обновить какие-то 6000 товаров.
Начали разбираться и обнаружили падение базы. Начали смотреть почему падает, обнаружили нехватку памяти. Начали смотреть куда девается память - обнаружили оверхед потребления php-fpm. Начали разбираться почему - обнаружили, что в момент импорта-обновления таблиц mysql хоть их и не блочит, потому что innodb, но начинает подтупливать, потому что перестраивает индексы на больших таблицах. И в момент тупняка базы, становиться очередь запросов на генерацию страниц из php-fpm потоков, которые резервируют под себя память и в какой-то момент watchdog прибивает базу, как самый жадный процесс по потреблению памяти и пытается ее перезапустить, естественно убивая импорт и создавая проблемы для пользователей. Ну и оно в целом все время висит в момент импорта.
Начали смотреть внимательней, и обнаружили в логах очень много зверей типа ahrefs, mj12 и других. Закрыли. Не полегчало.
Попросил я дообавить 2 гигабайта памяти к 2 существующим на сервер. Добавили полегчало. И мало того, еще перенесли VPS на сервер с физической частотой процессоров в 5Ghz и вот тут полегчало глобально, импорт пролетел за какие-то 70 секунд. Все отлично.
Прошли сутки. И сегодня опять мне прислали вот такой скрин:
Со словами - там в логах очень много гугл бота.
Я был готов уже проклять тот день когда я сел за баранку этого паровоза.
Но нет. Все решили. И сейчас вот так
И время ответа страниц без каких либо кешей 300-800 мс. С фильтрами, и всем остальным всем, что было до.
Вы спросите, а что же ты йода втираешь дичь. Типа. вот ты там решил потом не решил, потом опять справил и опять нет.
Ну вот такой вот я Йода, который не может предусмотреть все.
Но если вы не хейтор, а вам интересно что же это было и как исправилось. То я вам расскажу, и это очень смешно:
Помните мы убрали фильтр? А помните, по страницам фильтра боты ходили?
А теперь они увидели там 404, и что? Да пошли с утроенной силой чтобы проверить весь ресурс. На всю эту прорву мусороного контента, который был в очереди на сканирование. И был уже проиндексирован!
Просто всего ничего к нам зашло за день и только на html контент (обращения к статике в логе не учитываются):
Удивительно, чо же там с нагрузкой.
Ну ладно. Но у нас же проблема. Боты приходят на чпу ссылки. У нас нет хвоста site.com/filterviewer/какаятотупаястраницафильтра.
Так бы мы могли спокойно в nginx-конфиге заблочить сразу это все в 404 на корню и забыть про проблему.
Ок. Смотрим, что у нас есть в ссылках, а у нас там есть ~ в ссылках вида
023~500-031621~sp0720-8003-ts~500-0702701~500-0702702~2140-180~2141-228~2516-240~4152-250~4155-213~kr2300-205~tstr6-762ef~500-031616.
Проверяем таблицу url_alias, там у нас символа ~ нету. Волшебно, БИНГО. Через минуту после блокировки всех ссылок с таким признаком на уровне web-сервера, наша нагрузка пришла в норму и проект зажил ровно так как и должен работать, зарабатывая владельцу деньги а не геморрой и седые волосы.
Нам еще много предстоит сделать, чтобы гадкий утенок превратился в красивого лебедя. Но эта моя сказочка про конкретную историю, как бывает когда два неграмотных дополнения могут привести к остановке бизнеса на пару недель, и про то что не всегда стоит бежать покупать стопятидесятиядерные сервера, так как не разобравшись в корне проблем, решить вопрос железом может быть или слишком дорого или невозможно в принципе.
UPD: прошли сутки и у нас новое бинго
657 мать его тысяч запросов от гугл бота..
Как это развидеть! Viiver ты что курил, прежде чем написать этот бред?
Как тебя выпустили, я не знаю откуда, но людям тебя нельзя показывать!
-
9
35 коментарів
Recommended Comments
Створіть аккаунт або увійдіть для коментування
Ви повинні бути користувачем, щоб залишити коментар
Створити обліковий запис
Зареєструйтеся для отримання облікового запису. Це просто!
Зареєструвати аккаунтВхід
Уже зареєстровані? Увійдіть тут.
Вхід зараз