Оптимизация форума на IPB {экспертиза}

battle

Оптимизация форума на IPB {экспертиза}

Итак, я немного пришел в себя и могу вам поведать первую часть эпопеи с Опенкартфорумом.

Как вы все знаете, последний месяц он себя не очень чувствовал с технической точки зрения. Что там происходит политически, и еще как либо — мы тут обсуждать не будем.
А переезд на новую версию грозил обернутся полным коллапсом.

Так вот имеем вводные. Ресурс на IPB, на котором одновременно онлайн бывает до 600-700 посетителей. 70 000 постов, которые регулярно сканируют боты и совершенно непонятно кем, когда и как настроенный сервер, нагрузка которого валила в 100% без остановки и падала немного только ночью. Доступов у меня нет ни к чему, только к фронтенду, как у банального посетителя.

Первое, что надо делать в такой ситуации, производить экстренную реанимацию и искать возможные способы снизить нагрузку максимально прямо здесь и сейчас.

Площадки у нас что forum.opencart.pro, что opencartforum.com, стоят на одном движке IPS (раньше это называлось IPBoard), поэтому некоторое представление о его работе у меня есть.

В IPB  встроены механизмы, которые позволяют это реализовать «прямо сейчас».
Во первых у движка есть кеширование статических страниц для гостей, во вторых кеширование системных наборов данных в хранилища типа memcache или redis.

Сначала пришлось определиться с хранилищем для статики. Движок на выбор предлагает либо mysql, либо файловую систему. Mysql мы сразу отметаем — так как она бедная итак ели шевелилась, да и хранить статичные файлы в базе данных — не кошерно.

Дальше был выбор между APC, Memcache и Redis. Здесь тоже однозначный выбор — исключительно в пользу Memcache, так как работает он быстрее всех.

Также у Ipboard есть механизм popup-сообщений (почти автоддос), механизм внутренней поисковой индексации (почти встроенный сфинкс) и механизма запуска системных событий вызываемый при обращении к фронту а не через крон (можно переключать крон/фронт).

Попапы — классно, но когда сидит 250 человек онлайн у всех открытые браузеры, которые каждую минуту стучаться за новыми данными — это ужас. Бедной системе  итак плохо, а тут нагрузка удваивается пропорционально активным подключениям. На время мы это все отключили.

Перевели системные процессы на запуск по крону и пытались дождались момента пока закончит перестроение  поисковый индекс (на старом сервере — не вышло, не хватало ему критически ресурсов).

Следующим этапом была проверка конфигруации Nginx Apache и Mysql. Как выяснилось от недостатка ресурсов для буфферизации индексов, база не могла полноценно обрабатывать сложные выборки, и при правильном конфигурировании, опять же немного снизилась нагрузка. Nginxу были добавлены worker процессы ну и по мелочи он был доконфигурирован, чтобы держать как можно больше подключений. Опять же это все по фотографии, руками анонимного одмина, который то появлялся то пропадал в сумраке.

Это были даже не полумеры. Это была попытка надышаться перед смертью.
Нагрузка все не хотела падать меньше 80% и при этом так и норовила добежать до 100.

Продолжив поиски любых возможностей сделать что-либо еще по горячему, вдруг мне на глаза попалось отсутствие robots.txt.

И это уже было что-то, создав нормальный роботс и отбив ботов с большей половины страниц куда они неустанно долбились, получилась более-менее стабильная картина в 50% общей нагрузки на ресурсы сервера.

Но счастье было недолгим. Буквально на следующий день, все 16 ядер процессора оказались опять загружены по полной, и стало ясно, что в такой конфигурации дальше система просто рухнет. Оптимизация «по фотографии» была закончена. Нужно было проводить более подробный анализ, искать бутылочные горлышки, анализировать общий входящий трафик, разбираться со структурой БД и проектировать систему, на которой можно было бы оживить проект. К сожалению даже десяток самых быстрых VPS от AdminVps  мало чем помог.

А что было дальше, откуда взялась опять нагрузка, куда мы  в итоге переехали, и почему пришлось два раза перестраивать все с нуля, узнаете в следующей серии.

А  пока вот вам красивая картинка (здесь нет данных по первоначальнй площадке):

cpu_op_f

 

Первый кто правильно скажет куда делась нагрузка system(зеленый график), получит от меня 1000 рублей, там как раз завалялось с донатов.

Хуйнаныр(41)Очко(0)

Запостить высер

Стучать мне на мыло
avatar

Сортировать:   Свежие | Тухлые | Хуйнанырные
the larva Skynet
робот-вертер
the larva Skynet
2 месяцев 16 дней назад

Судя по ушам — «Перевели системные процессы на запуск по крону»+iptables+fail2ban )

OldAine
робот-вертер
2 месяцев 15 дней назад

За оптимизации, спасибо. Форум летает.

Когда вернут возможность видеть список покупателей? Чтобы все были на одной странице, без пагинации? Я не могу проверить покупал человек или нет. Не знаю оказывать поддержку или нет…

Dinox
робот-вертер
2 месяцев 15 дней назад

Ну какбы есть такой раздел https://opencartforum.com/clients/sales/ уже давно все им пользуются

OldAine
робот-вертер
2 месяцев 13 дней назад

Точно, я просто древний. Ничего не могу найти в новом форуме.

Edemuse
робот-вертер
Edemuse
2 месяцев 15 дней назад

Репликация базы данных master-slave, последняя версия php7 и db_indexes?)

XPEH
робот-вертер
XPEH
2 месяцев 14 дней назад

Наверняка за счет аякс-переключателя страниц

Автор камента сцыкло
робот-вертер
Автор камента сцыкло
2 месяцев 14 дней назад

Нагрузка на system была связана с отправкой почты?

Hanna
робот-вертер
Hanna
2 месяцев 13 дней назад

Вах! Неужто отбив ботов дал такой результат по system?

Питов
робот-вертер
Питов
2 месяцев 10 дней назад

нагрузка упала из-за отключения popup-сообщений, так-как система постоянно мониторит происходящее на форуме. Попал ?

wpDiscuz