Комментарии 12
Это не отзыв на панель, это отзыв на современных разработчиков.
500 юзеров держит шаред, чтобы от 500 юзеров упал ВДС за $50 — это надо постараться.
ВДС возьмите на nvme, базу вынесите отдельно, ДНС и почту также.
А панель — ничего особенного. Бесплатная CWP всё это умеет + varnish из-коробки: выдержит в несколько раз больше.
Да, cwp хороша, проста в установке, довольно гибкая в настройке. Но, недавно был у них очень неприятный случай, когда после очередного обновления на бесплатной версии отключился php-fpm. Типа было бета версия поддержки php-fpm, а потом сделали платной и отключили эту фичу с остановкой процессов php-fpm.
Что такое 1000 одновременных подключений? Параллельные запросы?
У вас же просто новостной сайт, там просто запрос-ответ. Время обработки такого подключения должно быть около 100 мс. Чтобы создать 1000 одновременных подключений в таких условиях нужно очень много пользователей. Очень.
Соответственно, у вас просто не вытягивает php-fpm. Возможно банально не хватает воркеров, но скорее всего проблема в самом коде.
Меня сейчас закидают помидорами, но зачем вам Laravel на новостном сайте? Еще «со времен» Symfony такие фреймворки были большие и неповоротливые, вряд ли сейчас что-то поменялось. А использовать вы будете на новостном сайте… да ничего по сути не будете использовать.
Какой-нибудь микро-фреймворк (по сути роутер + DI) покроет 90% задач, остальное можно допилить ручками. Работать это будет сильно шустрее просто за счет меньшей кодовой базы.
memcached в полтора гига? :) Что вы там такое кешируете? Это огромный объем для обычного сайта. Лучше память перекинуть в php-fpm или mysql.
Как сказали выше, это реально отзыв на современных разработчиков.
Просто интересно, какой размер БД и буфера InnoDB?
P.S. Перекиньте SSH на какой-нибудь нестандартный порт. Уйдут почти все боты.
У вас же просто новостной сайт, там просто запрос-ответ. Время обработки такого подключения должно быть около 100 мс. Чтобы создать 1000 одновременных подключений в таких условиях нужно очень много пользователей. Очень.
Соответственно, у вас просто не вытягивает php-fpm. Возможно банально не хватает воркеров, но скорее всего проблема в самом коде.
Меня сейчас закидают помидорами, но зачем вам Laravel на новостном сайте? Еще «со времен» Symfony такие фреймворки были большие и неповоротливые, вряд ли сейчас что-то поменялось. А использовать вы будете на новостном сайте… да ничего по сути не будете использовать.
Какой-нибудь микро-фреймворк (по сути роутер + DI) покроет 90% задач, остальное можно допилить ручками. Работать это будет сильно шустрее просто за счет меньшей кодовой базы.
memcached в полтора гига? :) Что вы там такое кешируете? Это огромный объем для обычного сайта. Лучше память перекинуть в php-fpm или mysql.
Как сказали выше, это реально отзыв на современных разработчиков.
Просто интересно, какой размер БД и буфера InnoDB?
P.S. Перекиньте SSH на какой-нибудь нестандартный порт. Уйдут почти все боты.
Трафик более 300000 посетителей в сутки. Время рендера от 200 до 500мс, при сильно большой загрузке понятно больше. Воркеров накрутили, в итоге LA на сервере было в районе 100 в пиковые моменты. Утыкались на самом деле больше в проц, чем в память.
Практика показала, что memcache отъедает не более 100, поэтому я его конечно урежу. Кто ж его знал сколько ему может понадобиться :)
К вопросу выбору фреймворка я непричастен, поэтому прокомментировать по существу не смогу. Сайт довольно динамичный, с голосовалками, комментами и сопутствующим контролем сессий. Вполне определенно можно сказать, что так оно и останется на ближайшее время, или пока трафик не вырастет до 1М в сутки.
Практика показала, что memcache отъедает не более 100, поэтому я его конечно урежу. Кто ж его знал сколько ему может понадобиться :)
К вопросу выбору фреймворка я непричастен, поэтому прокомментировать по существу не смогу. Сайт довольно динамичный, с голосовалками, комментами и сопутствующим контролем сессий. Вполне определенно можно сказать, что так оно и останется на ближайшее время, или пока трафик не вырастет до 1М в сутки.
В высокий LA можно уходить не только по процу. Например, если упретесь в диск, тоже LA поднимется, причем иногда это очень критично.
Сложно конечно вот так пальцем в небо, но учитывая число посетителей, вероятно, есть бюджет на сервер лучше чем за $50. В идеале конечно выделить отдельные машины под веб и бд, но скорее всего проще тупо закидать сайт мощностями: побольше ядер + под mysql выделить буфер полностью под всю базу, чтобы снизить нагрузку на диск.
Еще сильно помогает для php-скриптов /tmp выделить в tmpfs (в ram). Конечно, если там не нужно много места и память позволяет.
Про SSD/NVMe вроде выше сказали, но думаю у вас и так оно есть. VDS на HDD сегодня еще найти надо.
UPD: На всякий случай, memcached будет отъедать все что ей выделили, а по факту может использовать меньше. Нужно смотреть внутренние stats
Сложно конечно вот так пальцем в небо, но учитывая число посетителей, вероятно, есть бюджет на сервер лучше чем за $50. В идеале конечно выделить отдельные машины под веб и бд, но скорее всего проще тупо закидать сайт мощностями: побольше ядер + под mysql выделить буфер полностью под всю базу, чтобы снизить нагрузку на диск.
Еще сильно помогает для php-скриптов /tmp выделить в tmpfs (в ram). Конечно, если там не нужно много места и память позволяет.
Про SSD/NVMe вроде выше сказали, но думаю у вас и так оно есть. VDS на HDD сегодня еще найти надо.
UPD: На всякий случай, memcached будет отъедать все что ей выделили, а по факту может использовать меньше. Нужно смотреть внутренние stats
Да, следили и за диском и за сетевым адаптером. В ядерном пространстве почти не сидели, диск вообще не ждали.
Я принципиально согласен, что архитектура могла быть и посовершеннее, но такого роста трафика (тем более, относительно того что было на самом старте) не предвидел никто.
Много серверов с разделением ролей это может и правильно, но и хлопот пропорционально больше. А времени заниматься этим хозяйством не прибавится :) поэтому так. Если опять куда упремся, докинем либо ядер, либо рамы.
С другой стороны, разве не хорошо взять самую душу из доступной конфигурации?
Я принципиально согласен, что архитектура могла быть и посовершеннее, но такого роста трафика (тем более, относительно того что было на самом старте) не предвидел никто.
Много серверов с разделением ролей это может и правильно, но и хлопот пропорционально больше. А времени заниматься этим хозяйством не прибавится :) поэтому так. Если опять куда упремся, докинем либо ядер, либо рамы.
С другой стороны, разве не хорошо взять самую душу из доступной конфигурации?
Это все замечательно, но раньше плеск не умел в восстановление из бекапов на новом сервере. Ему нужны были какие-то мапы-шмапы, а главное — сайт мог не восстановиться или восстановиться не до конца.
Так что давно ушел на Весту, а для коммерческого — на DirectAdmin.
Так что давно ушел на Весту, а для коммерческого — на DirectAdmin.
Наверно сильно раньше. с 17.0 версии, с который мы начали, проблем нет. Одну вещь нужно сделать это поставить пароль для шифрования бэкапа, иначе с дефолтным ключом можно действительно наколоться. docs.plesk.com/en-US/obsidian/administrator-guide/backing-up-and-restoration/global-backup-settings.59265
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой опыт работы с Plesk