| +66 голосов |
|
Сегодня (вернее – уже вчера), как и обещал в прошлых постах про Hyper-V Server, решил проэкспериментировать с виртуализацией серверов IIS7 под управлением Hyper-V Server 2008. Хотел, наивный, добиться озвученных ранее показателей, когда виртуализация позволяет “разогнать” вебсайты за счет “обхода” узких мест при диспечеризации процессоров и ввода/вывода веб сайтов. Щаз!!! Но давайте все по порядку….
Итак, сценарий задуманного тестирования был крайне прост (как АКМ), что позволяло надеяться на положительный результат.
Шаг 1. Берем сервер – все тот же, использовавшийся и ранее для экспериментов с Hyper-V Server Dual Xeon x5345, 4GB MEM, SAS RAID 0 10K rpm – и устанавливаем на него WS08 с IIS7. Для чистоты эксперимента отключаем в IIS7 кеширование контента, включаем ASP.NET и пишем какую-нить страничку aspx, которая при инициализации просто много считает, деля и перемножая раз так 10К случайные числа с плавающей точкой – чтобы было чем занять процессор.
Шаг 2. Берем еще 2 “сервера тестирования” и устанавливаем на них весьма оригинальную программу под названием Web Capacity Analysis Toll (WCat), которая генерирует необходимое число запросов с этих серверов на нужную страницу на сервере веб согласно простенького скрипта. По умолчанию оба WCat c серверов эмулировали по 1024 клиента, непрерывно “дергающих” заветную страницу – получалось – запрос каждые 0,014 сек
Шаг 3. Меряем все это дело 3 раза – вернее, сохраняем логфайлы показателей транзакций, а за одно посматриваем на загрузку процессоров вебсервера.
Результаты получились примерно следующими: Transactions/sec: 595; Requests/sec: 1187; Total Errors: 214; веб сервер CPU: 10%. Самое интересное, что дальнейшее увеличение числа эмулируемых клиентов в WCat к особому изменению показателей не приводило… А после 2500 клиентов – уже начали притормаживать сами генерирующие запросы сервера.
Теперь тоже самое, только на Шаге 1 на тестируемом сервере поднимается Hyper-V Server 2008, в нем 2 виртуальные машины Windows Server 2008 Web Edition с IIS7. Каждой выделяется по 4 виртуальных процессора и 1,7ГБ ОЗУ (чтобы 4-2*1,7=0,6 оставить самому серверу на виртуализацию, реально же счетчики показывали 3,84ГБ занятой памяти). Настройки IIS7 и страница – те же, что и в предыдущем примере.
Шаг 2. “Натравливаем” WCat с разных серверов на разные виртуальные IIS7 с параметрами эмулируемых клиентов, что и в предыдущем примере, увеличенными на 2.
Шаг 3. Меряем – и получаем: Transactions/sec: 315; Requests/sec: 628; Total Errors: 161; веб сервер CPU: 5%, родительский CPU 1-2%.
Выводы? В принципе 2*315=630>595; 2*628=1246>1187 – что должно говорить о повышении производительности, хотя 4% – это в пределах погрешности… Также пока непонятно с ошибками соединения – их тоже стало больше – 2*161=322>214 – причем, не на 4%, тут тоже стоит покапаться…
С другой стороны – такая же производительность 2х виртуальных машин, которые получили чуть меньшое железо и меньшие ресурсы – уже неплохо, можно считать тест удачным. :) Виртуализация, о которой все говорили, как о жрущей ресурсы работает, как видно из теста, абсолютно прозрачно, без накладных расходов…
Но больше всего смущает нагрузка – надо все же потестировать решение, когда оно будет нагружать вебсайт хотя бы на 60-70%, причем, неоднородной по типам нагрузкой – память, процессор, диск, сеть. Простой рост эмулируемых WCat клиентов не подходит, какое чувство, что даже такой “маленький” сервер выдержит с десяток тысяч одновременных обращений. Поэтому завтра поставим на IIS реальные продукты, например, “родной asp.net” Community Server и php WordPress. И вот их работа, надеюсь, уже даст искомые показатели и позволит реально оценить более эффективное распределение нагрузки физической машины между виртуальными машинами с IIS7. Так что ждите следующего раунда тестирования. После чего перейдем к тонкому тюнингу и замерам отдельных сценариев, как-то IIS web garden, NLB из виртуальных IIS и прочим полезностям :)
Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365
| +66 голосов |
|
