Ставь то, что описал, но помноженное на 2. Тогда точно подойдет.

Сталкивался с требованиями к железу от IBM. Энтерпрайз такой энтерйпрайз, выдали то же самое - «вот на этом точно пойдёт».

а как проц помоножить? 8)

В требованиях раздели такие вещи как «томкат+субд+линупс», в случае возникновения вил можно сказать «эти 512 метров оперативы выжираю не я, а субд/линакс/кеды_в_vnc, поэтому все и свопится дико, и вообще, под субд надо отдельный сервер, а мое чудное приложение всего 400 метров занимает, ему бы хватило».

Ну и сервер, где менее 2 гигов оперативы - это смешно. Заранее запроси под кеширование запросов из базы, если валится начнет. Да и пометка «требования соответствуют текущему ТЗ и текущей нагрузке» тоже не помешает. А то вдруг ты пишешь «госуслуги2.ру», которое будут пиарить по тв и которое опять отвалится? А у тебя будет бумажка «рассчитано на 100 юзеров в год», после чего скажешь «а я предупреждал, что для 5000 юзеров надо кластер покупать»

проц умножай так: вывод /usr/bin/time помнож на количество запросов, помнож на 2 и еще на 2 - будет примерное cpu-time относительно твоей машинки. Далее переписываешь под новый конфиг.

Невыполнимые требования спасут.

Всё очень просто, не ври. Или другой вариант: «Будь реалистом, требуй невозможного.» В требованиях прямым текстом напиши, что под СУБД должна быть выделена отдельная машина, 512 Мб ОЗУ, процессор такой-то, сеть, НЖМД...А на словах объясни заказчику сколько твоей программы на самом деле надо. Пусть его админ ставит так, чтобы СУБД получила заведомо не меньше вычислительных ресурсов, чем на отдельной машине из ТЗ.

Все банально, бери то, на чем твоя БД+Tomcat+2-3 запроса будут работать на 1000%. Ессно:

1) Если малоресурсоемкость не имеет преимущества
2) Из современных платформ.

А так - конкретику можно сказать, только зная объем и структуру db и примеры запросов

ИМХО требования к железу ibm x3550 с таким-то числом памяти и процом и рейдами, можно ещё похожее от делл и хп. В идеале неплохо бы их иметь под рукой и убедиться в нормальной работоспособности. Потом всё, говоришь корзина технических средств для моей проги такая-то, на всём остальном стабильная работа хз.

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

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

Ну и вообще, я бы в такой ситуации исходил не из понятия минимальных требований (которые будут очень сильно отличаться под разной нагрузкой что естественно), а из описания возможностей программы на целевой конфигурации, которая будет конкретно прописана в документе. Например если целевая железка 3й пень + 512 мб оперативки, то прикинуть, сколько запросов выдержит система конкретно на этой железке (лучше бы конечно проверить, но сам процесс тестирования нагрузки может оказаться нетривиальным надо думать, если только под рукой нет хорошего ботнета) и написать это в документе. Плюс дополнительно пункт, по которому при желании смены конфигурации, расчеты должны быть проведены повторно (и включены в отдельный счет).

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

три звезды а такое спрашивает.
1. Надо определить требования: сколько пользоателей и т.д.
2. Надо провести нагрузочное тестирование.

Исходя из результатов этих операций можно говорить о железе.

>Желательно узреть примеры, да, если кто с таким сталкивался.

Коммерческое серверное ПО должно писаться и обкатываться на конкретной платформе, и местные админушки туда лезть должны не дальше чем есть в инструкции, или отказ от поддержки. А потом, если марка озу или тайминги изменились можно слать подальше.

Впервые слышу про такие требования как у Вас.

берём серверные требования оракла. говорим нужен сервер 1 штука с такой конфой под дб. берём серверные требования вебсферы и говорим что нужен второй сервер такой-то конфы. ынтерпрайс же.

>как бы очевидно что ему хватит третьего пня

а ты с эмулируй непрерывную нагрузку на сервер например 10 пользоватей на 3 пне и посмотри сколько из них пройдут за минуту. это пока у тебя один юзер всё хорошо. ваш К.О.

OpenVZ, провести нагрузочное тестирование, cat /proc/user_beancounters

напейсано же что приложения пока нет, так шо нехрени эмулировать.

По опыту знаю, что как правило все упирается в субд, ибо там очень ё***е запросы, кои могут выполнятся по минуте. А требования субд мне учитывать ненадо.

ну смотри сам. по опыту я могу сказать что средняя тормознутость юнтырпрайз приложения растёт экспоненциально нагрузке.

навреняка твой опыт стротся на разрабатываемых «быстро» приложениях? т.е. с ORM типа hibernate, и кучей бинов и т.п.

>навреняка твой опыт стротся на разрабатываемых «быстро» приложениях? т.е. с ORM типа hibernate, и кучей бинов и т.п.

ты прав.

о существовании load и performance тестирования белка не подозревает?

и да. писать технические требования к железу не имея конкретных цифр предполагаемой средней и максимальной нагрузки - это маразм.