Я управляю крупномасштабная ERP-система на следующей конфигурации сервера. Приложение разработано с использованием AngularJS и ASP.NET 4.5
Dell PowerEdge R730 (четырехъядерный процессор 2,7 ГГц, 32 ГБ ОЗУ, 5 жестких дисков по 500 ГБ, настроен RAID5) Программное обеспечение: ОС хоста - VMWare ESXi 6.0 Две виртуальные машины работают на VMWare ESXi .. одна - Windows Server 2012 R2 с памятью 16 ГБ выделено ... это содержит сервер IIS 8 с моим кодом приложения Другой виртуальной машиной также является Windows Server 2012 R2 с SQL Server 2012 и 16 ГБ памяти. выделено .... это просто моя база данных приложений.
Видите ли, я разделил сервер приложений и сервер базы данных для балансировки нагрузки.
В моем приложении есть модуль регистрации, где ожидается очень высокая нагрузка (около 10 000 посетителей за 10 минут).
Чтобы поддерживать этот объем запросов, я сделал следующее на своем сервере IIS -> увеличил очередь запросов в длине пула приложений до 5000 -> включил кеширование вывода для файлов aspx -> включил статическое и динамическое сжатие на сервере IIS -> установил виртуальную память limit и ограничение частной памяти каждого пула приложений до 0 -> Увеличить максимальный рабочий процесс каждого пула приложений до 6
Затем я использовал Гатлинг для запуска нагрузочного тестирования моего приложения. Я ввел 500 пользователей одновременно в мой модуль регистрации.
Однако я вижу, что используется только 40% / 45% моей оперативной памяти. Каждый рабочий процесс использует не более 130 МБ или около того.
И gatling сообщает, что около 20% моих запросов получают ошибку 403, и более чем 60% всех HTTP-запросов имеют время ответа более 20 секунд..
Один пользователь выполняет 380 HTTP-запросов в течение примерно 3 минут. Общий объем передачи данных одного пользователя составляет 1,5 МБ. Я смоделировал 500 таких пользователей.
Что-то не хватает в настройке моего сервера? Я уже настроил код своего приложения, чтобы минимизировать утечки памяти, увеличить время ожидания и т. Д.
Разместите свой SQL Server на выделенном хосте. Перед тем, как вы получите доступ к физическому ресурсу, здесь работают два поколения гостевой операционной системы. У вас есть гипервизор в качестве базовой ОС, Child Guest - это хост Windows Server, Grandchild OS - это SQL Server, который захватывает блоки диска и RAM и управляет им с помощью своего собственного пространства имен. Вы можете смягчить некоторые из них, если у вас есть выделенные диски и выделенная сеть. Не позволяйте виртуальной машине перемещаться.
http://www.tpc.org/tpctc/tpctc2009/tpctc2009-13.pdf
У вас будет некоторый арбитраж по общим ресурсам, поскольку у вас есть 32 ГБ, распределенные между двумя вашими хостами, что оставляет ровно ноль для гипервизора, поэтому гипервизор начнет арбитраж доступа к общим сегментам, в то время как он оставит блок для себя. На самом деле у вас была бы гораздо лучшая производительность, если бы вы установили оба компонента в один и тот же экземпляр ОС и использовали локальный именованный канал для всей связи с SQL Server и обратно. В нынешнем виде вы создаете много накладных расходов из-за превышения лимита подписки на физический хост гипервизора, два экземпляра ОС и запущенную операционную систему внука.
«Один пользователь делает 380 HTTP-запросов ...»
Предположительно, это не все динамические элементы, и здесь есть много статического мусора в виде изображений, таблиц стилей, JavaScript, шрифтов и тому подобного. Установите CDN перед этими статическими элементами, чтобы нагрузка упала почти до NIL в источнике для статических компонентов. Вы хотите, чтобы ресурсы и нагрузка направлялись исключительно на одну динамическую часть - данные, представленные формой, а не на общую обработку файлов. Черт возьми, я бы пошел далеко, чтобы предположить, что вы хотите, чтобы возраст кеша на клиенте был как минимум равным продолжительности развертывания вашей сборки. Выполняйте развертывание в субботу и в полночь каждую неделю, затем установите срок действия кеша до полуночи субботы плюс одна неделя с каждой сборкой. Это обеспечит хорошее заполнение вашего CDN, и вы сможете избежать попаданий, нагрузки на сеть и нагрузки на сервер.