Статья будет совсем короткая, ибо для большинства идеальное решение - простое решение (не путать с правильными и разными ибо правильных много). Статья о том, как это делал Я при отсутствии инструментария вообще. 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х с какого-то буржуйского сайта, тогда это было модно...