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

Статистика: Символов — 3 707/3 114 без пробелов (3 707/3 114 без кода):, слов — 594
Разметка: Wiki
Статья будет совсем короткая, ибо для большинства идеальное решение - простое решение (не путать с правильными и разными ибо правильных много).
Статья о том, как это делал Я при отсутствии инструментария вообще.

  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 стр/сек пиковую нагрузку на наш веб-сервер.

Выводы:
  a) 1 php-процесс, согласно php.ini по дефолту жрёт 128 мег. 4 стр/сек * 128мб = 512 мег в секунду кушает php;
  b) предполагается, что вы уже настроили свою бд относительно потребления памяти и это число, например, равно 1гб памяти (у кого-то и 4гб, а у кого-то и 512мб)
  c) сама операционка, если это линукс/юникс, занимающийся только хостингом кушает в среднем 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х с какого-то буржуйского сайта, тогда это было модно...