Как не попадать на 250 000 рублей в год, если не слушаться "специалистов" по настройке серверов

Как всегда начну издалека.

Откуда то у людей взялся миф, что если вот вдруг, вам настроят сервер у вас будет быстрый магазин, или вот возьмите арендуйте dedicated, и тоже будет быстрый магазин.

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

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

Второй миф. Когда на магазин приходит нагрузка от ботов, или парсинг, или школьный ддос, да просто предновогодний трафик в конце концов, часто густо сервера начинают падать, глючить, приходит какой-то мего спец с умным видом говорит - "у вас ДДОС", срочно срочно надо уходить под cloudflare, ddosguard или stormwall.

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

Вводные данные: 10к товаров, 3к трафика в день, выделенный сервер на бегет. не VPS а именно дедик за 10 000 рублей в месяц, а также платный пакет stormall за 15000. При этом занято на диске 400 из 500 гигабайт, и магазин работает несколько нестабильно. 

А теперь небольшая калькуляция (10000 + 15000)  * 12 = 300 000 рублей в год за инфраструктуру.

По итогу после приведения в порядок магазина, отказа от бесполезного stormwall (если надо будет - есть CloudFlare за $20 в месяц), переезда на нормальный VPS за 2000 рублей в месяц и аренды еще пары сервисов по мелочи, мы в 2022 году сэкономим порядка 250 000 рублей чистыми. 

Вы опять же спросите - как так? Почему мелкий VPS оказался производительнее чем выделенный сервер?

Да потому что за 10 000рэ на бегете был какой то xeon лохматого 15-го года выпуска, древний измученный ssd, и DDR3, а взамен мы арендовали 3 четырехгиговых ядра, nvme диск, и DDR4, что позволило почти на порядок увеличить моментальную скорость генерации страниц.
Также у вас может быть хоть  150 ядер и 100гб памяти, но если у вас в настройках базы данных к примеру стоит 100 max_connection, то все ваши ресурсы просто будут греть воздух, ну или как сервиз для красоты в серванте стоять. Ну кроме настроек базы - есть еще несколько затычек в дефолтных настройках стека LAMP, но если их все перечислять - это на пару десятков постов потянет. Так что просто поднастроили все как надо.

Вы спросите, а куда же ты Йода дел 400 гигабайт, ведь не может стоить 2000 рублей с таким количеством места VPS?

Конечно же дел, вынес бекапы на внешнее удаленное хранилище, почистил логи (200 гиг было), добавил архивацию свежих логов, удалил старые базы, хламушник от обмена с 1с, и 400 гб отлично превратились в 37гб.  

Также, напрашивается вопрос. А что же с трафиком, как может мелкий VPS в 3 ядра работать успешней чем многоядерный собственный процессор?

И здесь все тоже очень просто. Во первых магазин как и автомобиль, требует профилактики и тюнинга, очень часто бывает удается сделать из 2-3 секунд 200-300 мс. Но в целом даже пятикратный прирост скорости генерации страниц, который мы получили на этом проекте, за счет настройки магазина, более чем достаточен, чтобы мы вписывались в 30-40% от пиковой нагрузки сервера. Во вторых: боты боты боты боты! Смотрите в логи друзья, там часто ходит такой зоопарк, что вы даже себе представить не можете, мало того этот зоопарк может ходить туда куда ему не надо, равно как и гугл и яндекс боты. Если ограничить доступ к магазину для всяких MJ12, Petal ботов и т.д. И закрыть в роботс корректно ненужные страницы для легитимных ботов, то и еще нагрузку на систему можно снизить на 40-50-70%. Ну а 3-4 к трафика в день с глубиной 5-6 страниц человека, для нормального VPS - это детский лепет. Пошло как дети в школу.

И еще логичный вопрос от обывателей: а почему бы не поставить джет кеш или лайтнинг, ведь они ускоряют ?

Очень хочется увидеть как они ускоряют агрегатный запросы в админке при обработке 4-5 сотен заказов в день. Ну или как они ускоряют внутренний поиск на сайте.
В данном случае пришлось потратить пару дней для скурпулезной простановки составных индексов, под запросы моделей, которые в админке обрабатывают данные о продажах.
Так как в сложных JOINах с таблицами по 300-800к строк, просто так нельзя взять и взять проставить индексы на id, и думать что поможет!

Ну и поиск sphinx быстрее любых потенциальных аналогов.

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