SRS для системы, в которой я сейчас работаю, включает в себя следующие нефункциональные требования: «SuD будет масштабироваться до 200 одновременных пользователей». Как я могу преобразовать это утверждение в более измеримый признак: «количество показов в секунду»?Как конвертировать одновременных пользователей в число попаданий в секунду?
Ну, это невозможно ответить, не зная ничего о вашем приложении или о том, что он делает. Вам нужно выяснить, сколько показов в секунду может появиться у пользователя при использовании приложения, и умножить на 200.
Не случайно, что хиты/секунда - это не единственный показатель, который вам нужно учитывать. С 200 одновременными пользователями, сколько издержек памяти будет? Сколько дисков или открытых файлов? Сколько db читает/пишет? Сколько полосы пропускания (приложение использует потоковые медиа)? Можно ли все это обрабатывать одной машиной? и т. д. и т. д.
Предполагая, что вы говорите о веб-приложении (исходя из вашего желания оценивать «хиты» в секунду), вам нужно работать над несколькими предположениями. - Как долго пользователь будет проводить между взаимодействиями? Для типичных страниц контента это может быть 10 секунд; для интерактивных веб-приложений, возможно, всего 5 секунд. - Разделите количество пользователей на «время мысли», чтобы получать попадания в секунду - 200 одновременных пользователей с временем ожидания 10 секунд дают вам в среднем 20 одновременно работающих пользователей. - Затем умножьте на «пиковый множитель» - большинство веб-сайтов относительно тихо в ночное время, но действительно заняты около 7 вечера. Поэтому ваше среднее число должно учитывать это - как правило, я рекомендую пик от 4 до 10 раз. Это дает вам максимальные запросы страниц в секунду - это, как правило, ограничивающий фактор для веб-приложений (хотя отнюдь не всегда - потоковое видео часто ограничено пропускной способностью, например). Если вы действительно хотите знать «хиты», вам необходимо работать через следующее: - Сколько ресурсов на вашей странице? Изображения, таблицы стилей, файлы javascript и т. Д. - «удар» обычно относится к любому типу запроса, а не только к HTML-странице (или ASPX или PHP или тому подобное). Большинство современных веб-приложений включают десятки активов. - Насколько кэшируемыми являются ваши страницы и/или активы? Большинство изображений, CSS, JS-файлов и т. Д. Должны быть настроены на кеширование браузером.
Умножьте запросы страниц на количество не кэшируемых активов. Добавьте к этому количество посетителей, умноженное на количество активов, если вы хотите быть точным.
Все это, как правило, означает, что вы должны делать много и много предположений - так что последнее число является индикатором в лучшем случае. Для измерений масштабируемости я обычно трачу больше времени на то, чтобы понять узкие места в системе и наблюдать за системой под нагрузкой.