I'm sorry.Привет, Олешка!
Что-то давненько тебя не было.
:) работа, то-се, в общем, я очень рада вернуться, хоть и под другим логином. Не складывается у меня с ним что-то.Я поняла твою идею, просто я предлагаю все же как-то оговорить в статье то, что ты даешь свое определение. В идеальном варианте все же лучше дать ссылку на Менаске, ибо лучше него никто еще не описал всю теорию в одном флаконе, и у него, опять же, есть определение модели рабочей нагрузки, согласно которому нагрузка характеризуется измеряемыми параметрами, одним или несколько, по каждому компоненту системы, а модель рабочей нагрузки состоит из набора измеренных значений, при ограничении - одно значение на один базовый компонент. В контексте твоего примера компонентами будут регистрация, удаление спама, удаление сообщений, ввод сообщений, и по каждому из них можно задать измеряемые параметры - количество регистраций в единицу времени, количество транзакций удаления в единицу времени, количество записей, перенесенных в бекап, количество новых записей, и т.д. Вот эти параметры сформируют модель нагрузки.В первую очередь, я разделяю понятия "модель нагрузки" и критерии успешности тестирования. В первый термин я включаю именно модель того, в каких условиях система будет эксплуатироваться. В второй - пи каких условиях результаты испытаний следует считать успешными (либо не успешными).
...
Продолжая пример можно написать так, что при 100.000 одновременных пользователях скорость реакции системы не должна превышать 7 секунд. Но это не есть модель нагрузки (в моем представлении). Модель нагрузки - это то, что программируется (реализуется) в тестовых скриптах - действия пользователей и "вес" этих действий в общем объеме операций.
Тут буду спорить :) . То, что ты описываешь, это характеризация нагрузки при использовании системы, или набор вариантов использования, но не модель нагрузки. Они друг друга дополняют, но одна из них, а именно - модель нагрузки - должна содержать измеряемые характеристики, и должна быть связана с самой системой, с ее техническими возможностями по обслуживанию клиентов, а не только профилирована на логику работы системы и пользовательские предпочтения.Фактически критерии успешности могут меняться в зависимости от требований бизнеса (например, конкуренты сделали быстрее чем у нас и теперь мы должны обойти конкурентов), а модель нагрузки постоянна. Она обусловлена логикой работы системы и пользовательскими предпочтениями. Если у нас только 10% пользователей присваивают теги письмам для фильтрации по тегам, то и через полгода - год это примерное процентное соотношение сохранится, если данная функциональность не будет изменена на более удобную или не будут проведены дополнительные "продвигающие" мероприятия. Но без дополнительных воздействий на манеру работы пользователей модель нагрузки практически не меняется.
...
Другой пример модели нагрузки. В крупной компании (100.000 пользователей) все приходят на работу в 9 часов и запрашивают почту с сервера. С 9 до 9:30 приходится пик нагрузки на почтовый сервер. Так вот, модель нагрузки будет включать в себя операцию по коннекту почтового клиента к почтовому серверу, а критерий успешности - 100.000 одновременных пользователей, максимальное время отклика не более 10 секунд. Для другой компании количество пользователей и время отклика системы может иметь другие значения, но модель нагрузки не изменяется, если другая компания имеет такой же режим работы.
Для другой компании из твоего примера, которая будет работать с аналогичной системой, именно что будет другая модель нагрузки (в классическом определении, см. выше), если у них другое количество пользователей - время отклика в час пик поменяется, пропускная способность системы тоже, очереди могут собираться в других узких местах, хотя мы можем предположить, что характеризация нагрузки, набор вариантов использования останется тем же. Кстати, на работу в компанию могут просто прийти менее продвинутые пользователи, которые изменят как набор вариантов использования (будут, например, чаще обращаться к help файлам), так и модель нагрузки (будут сидеть и дольше думать, реже посылать запросы, появится свободный ресурс, который уйдет на обслуживание запросов от другой группы пользователей, например).
