Может войдёшь?
Черновики Написать статью Профиль

Вычисляемая на коленке нагрузка на сервер (ОЗУ), дабы выбрать хостинг

Статья будет совсем короткая, ибо для большинства идеальное решение — простое решение (не путать с правильными и разными ибо правильных много).
Статья о том, как это делал Я при отсутствии инструментария вообще.

  1. Первичный хостинг — девелоперская машина в офисе/дома на реальном IP, где и разворачиваем открытый бета-тест и запускаем людей.
  2. Выясняем время сессии РНР. Обычно это 15 минут.
  3. Делим сутки на 96 участков по 15 минут (24ч*60мин/ч=3600мин/15мин)
  4. Пишем скрипт-надстройку, которая в начале кода любого проекта/движка тупо регистрирует ip визитёра в свой участок 15-мин промежутка.
  5. Работаем так 2 недели...

Не раз повторю, что всё изложенное — вычисления на коленке.

На выхлопе:

  • Максимум уникалов/15-мин
  • Максимум хитов / 15 минут

Механика:
Допустим у нас в 15 минут 250 уникалов, которые смотрят каждый по (в среднем арифметическом, кто 9, а кто 2...) 6 страниц.
Это 250*6=1500 хитов / 15 минут.
15 минут = 15мин*60сек/мин = 900 сек.
В секунду просматривается 1.6(66) страниц ( ceil( 1500хитов / 900сек ) ) = 2 страницы в пике нагрузки за 1 секунду.
Если знаем пиковое значение времени генерации страницы (тут уж от проекта зависит), скажем от запроса до окончания отдачи — 2 секунды (без времени передачи файлов, но включающее работу с БД), то получаем 2 стр/сек * 2 сек = 4 стр/сек пиковую нагрузку на наш веб-сервер.

Выводы:

  1. 1 php-процесс, согласно php.ini по дефолту жрёт 128 мег. 4 стр/сек * 128мб = 512 мег в секунду кушает php;
  2. предполагается, что вы уже настроили свою бд относительно потребления памяти и это число, например, равно 1гб памяти (у кого-то и 4гб, а у кого-то и 512мб)
  3. сама операционка, если это линукс/юникс, занимающийся только хостингом кушает в среднем 512-1024мб, зависит от многих параметров и софта.

Итого нам требуется памяти от 2гб до 3гб. Точность вычисления — 85-90% , тоесть люфт 15%-10% и уже от вас и проекта зависит в какую сторону.

По нагрузке на процессор механика вычисления похожа, но за единицы измерения уже берётся время генерации страницы, как «информация», без оглядки на время запросов, — нам нужна конечная информация, а не составляющие её данные. Там вычисления либо по load average процессора либо по % нагрузки на процессор текущего процесса php.

PS:
Я прошу не привязываться к пунктам 2-3, это вычисления на коленке, но как ни странно показывающие приближённую реальность. Обычно (согласно личному опыту), это названные 85-90% и этого, поверьте — достаочно для старта продакшена.
Так же названные «96 участков времени» призваны установить видимые границы времени. Не более.
В итоге, нам надо выяснить пиковую нагрузку в количестве уникалов/хитов на объём 15-минутной рнр-сессии (это время процессора и мегабайты озу), за время которой и можно поймать этих уникалов.

PPS:
Вообще если кто-то заказывает проект, то он уже должен знать текущую аудиторию, её размер, предварительно проведя аналитику рынка. Соответственно от вас требуется только выяснить:

[время генерации страницы] * ( [Х-хитов] / [время сесии php в секундах] ) = [пиковая нагрузка на сервер за 1сек] * [объём потребления памяти процессом php] = [требования по памяти для php]

Соответственно мы видим необходимый объём памяти под php-проект. Останется плюсануть потребности БД и операционки.

PPPS:
Ну а если НЕ хотите делать вычисления на коленке, переложив всю работу на других — ставьте Яндекс.Метрику (не реклама), она покажет вам даже больше аналитики и точнее И debug-надстройку с возможностью сохранять потребления в бд, для последующих (через пару недель) выборок статистики. Однако там также всё не просто, как и с вышеизложенным. В любом случае придётся попотеть.

Прошу особо не пинать за настолько грубые вычисления и привязку к сомнительным «якорям», ибо этот метод, как я и говорил — вычисления на коленке при отсутствии какого-либо инструментария вообще. Точность проверена личным опытом в нескольких (5) проектах ещё 10 лет назад, и составила названные 85-90% с реальным люфтом в виде остатка 15-10% (2 проекта ушли в плюс, 3 в минус).
А методика, с некоторыми правками, сдёрнута ещё в начале 2000х с какого-то буржуйского сайта, тогда это было модно...

Как вы считаете, полезен ли этот материал? Да Нет

Комментарии (1)

Androbim

Принцип описан понятно. Спасибо!

Написать комментарий

Разметка: ? ?

Авторизуйся, чтобы прокомментировать.