Где мои модели должны жить? Ярус веб-узлов или уровень Данных? (MVC + NHibernate)
Сколько памяти занимает VU, сильно зависит от того, что делает ваш скрипт и (как правило, более важно), сколько других файлов он импортирует / анализирует. Из-за того, что все VU имеют свою собственную JS VM, они являются отдельными копиями всех файлов JS, которые необходимо проанализировать. Таким образом, если у вас есть какая-то большая библиотека JS, она будет скопирована между VU и, вероятно, будет занимать большую часть вашего использования памяти. Если в вашем скрипте также есть несколько больших файлов с большим количеством тестовых данных - они также будут скопированы и так далее. По моему опыту, простые сценарии могут использовать всего 1-2 МБ или меньше, и я видел, как сценарий достигает 40 МБ в некоторых действительно плохих случаях, когда они импортируют довольно большие JS-библиотеки.
Очевидно, что ваш скрипт будет использовать больше памяти во время выполнения, но основным источником этой памяти будут тела ответа, поэтому мы настоятельно рекомендуем использовать discardResponseBodies (в самом низу страницы), чтобы уменьшить эту память использовать и только установить responseType где / если вам нужен ответ тела.
О линейности - вид, более или менее большая часть памяти в каждом профилированном мной скрипте идет в VU после того, как скрипты JS были проанализированы в начале, и все VU были инициализированы. И они используют примерно одинаковый объем памяти, но есть некоторая память, которая нужна k6 для других целей, в зависимости от того, что вы используете, это должно быть около 200-300 МБ.
В конечном итоге вам придется проверить свой сценарий и посмотреть. Если вы знаете, что собираетесь использовать некоторые библиотеки, импортируйте их, не используя их, чтобы их можно было проанализировать и получить быструю оценку. Вы можете запустить k6 с --paused --no-teardown --no-setup, чтобы только инициализировать VU без фактического выполнения какого-либо кода снова для более быстрой оценки. Я рекомендую указать, сколько VU нужно запустить / инициализировать с помощью -u для тестирования. И вам следует подождать, пока не появится paused перед индикатором выполнения, чтобы все было инициализировано. Имейте в виду, что k6 будет использовать некоторую память для анализа вашего JS и инициализации других вещей в начале, поэтому вам, вероятно, следует начать тестирование по крайней мере с 50 VU и подняться, чтобы увидеть, сколько памяти добавляется для дополнительных VU. Очевидно, что выполнение финального сценария будет использовать больше памяти, но это должно быть полезно для целей измерения.
5 ответов
Я сохраняю модели/классы Entity Framework в уровне данных и использую папку Models проекта MVC для моделей презентации и образцовых редакторов связей.
Я сохраняю все свои модели в уровне данных из-за NHibernate. Смотрите на Архитектуру S#arp для отличного способа содержания в чистоте Вашей презентации. Модели не должны быть физически расположены в Вашем веб-проекте для Ваших представлений, чтобы быть со строгим контролем типов.
Модель данных является своей собственной вещью. Модель в MVC - что-то другое. Это - модель того, что Вы собираетесь отобразить, который может или не может быть Вашей Моделью данных. Вы - Модель данных, может превысить слои, или нет.
Примите, например, форму регистрации стандарта. Модель данных может включать имя пользователя, пароль и массив классов истории входа в систему, флаг, указывающий, что это активно и много другого материала. Модель в MVC, может только действительно заботиться об имени пользователя и пароле, и что пользовательский тип пароль дважды. Для Вашей Модели данных действительно нужны два поля пароля? Нет. Однако модель в MVC делает. Следовательно, два различных существа.
Вы правы относительно принципа DRY здесь. Я сохраняю свои объекты LINQ-SQL разделенными от моих бизнес-объектов, и у меня есть некоторое дублирование, и оно не заставляет меня чувствовать себя хорошо, но кажется, что нет простого обходного решения этого..
Мне было нелегко принимать это решение, но я смотрел блог Rob Conery при создании Витрины MVC, и в конце я решил пойти этим путем (объекты ORM И бизнес-объекты)
С MVC у Вас есть свои модели, которые находятся в папке "Models". Кажется необходимым поместить мои модели здесь, чтобы создать Представления со строгим контролем типов и обычно оставаться с философией MVC.
Никакая модель может быть ничем, что Вы хотите. Я все еще использовал бы модель презентации, если бы это было необходимо, но у меня нет возражения на использование Ваших nhibernate объектов в Ваших представлениях.
С NHibernate Вам действительно не нужен Уровень Данных, так как сама Сессия является уровнем данных.
Сервисный уровень походит на допустимую идею, но только если Вы планируете на наличии нескольких клиент для этого слоя.
Иначе у меня только были бы 1 проект и пространства имен использования для разделения моих слоев. Это создает быстрее и легче развернуться.