Iis расчет быстродействия для подключения


Содержание

Настройка IIS

Веб-сервер IIS, как среда выполнения веб-приложения, имеет некоторое влияние на общую производительность. Например, чем короче конвейер обработки запросов в IIS, тем меньше кода будет выполняться и тем выше будет скорость работы. В IIS имеются механизмы, которые можно использовать для увеличения производительности приложения за счет снижения задержек и увеличения пропускной способности, а также некоторые механизмы, которые при правильной настройке могут увеличить общую производительность приложения.

Кэширование вывода

Мы уже знаем, что ASP.NET поддерживает собственный механизм кеширования вывода, зачем же использовать еще один подобный механизм в IIS? Ответ на этот вопрос прост: помимо страниц ASP.NET существуют и другие виды содержимого, которое можно кешировать. Например, мы можем кешировать часто запрашиваемые статические файлы изображений или вывод собственных обработчиков HTTP-запросов. Для этой цели как раз и можно использовать механизм кеширования, поддерживаемый веб-сервером IIS.

В IIS имеется два механизма кеширования: кеш в пространстве пользователя и кеш в пространстве ядра.

Кеширование в пространстве пользователя

Так же как ASP.NET, веб-сервер IIS способен кешировать ответы в памяти, чтобы ответы на последующие запросы могли отправляться из кеша в памяти, без обращения к статическим файлам на диске и без вызова программного кода на стороне сервера.

Чтобы настроить кеширование, откройте приложение IIS Manager, выберите свое веб-приложение, откройте настройку Output Caching (Кеширование вывода), щелкните на ссылке Add (Добавить) в панели Actions (Действия), чтобы добавить новое правило кеширования, или выберите существующее правило для редактирования.

Чтобы создать новое правило кеширования в пространстве пользователя, добавьте новое правило, введите расширение имен файлов, которые требуется кешировать, и отметьте флажок User-mode caching (Кеширование в режиме пользователя) в диалоге Add Cache Rule (Добавить правило кеширования), как показано на рисунке ниже:

Отметив флажок, вы получите возможность выбирать, когда кешированный элемент будет удаляться из памяти, после обновления файла на диске или спустя некоторое время с момента кеширования. Для статических файлов больше подходит вариант удаления после обновления, тогда как определение интервала времени больше подходит для динамического содержимого. Щелкнув на кнопке Advanced (Дополнительно) можно получить доступ к настройкам, управляющим кешированием различных версий вывода (согласно параметрам в строке запроса или HTTP-заголовкам).

После добавления правила кеширования, настройки сохраняются в файле web.config приложения, в разделе system.webServer caching. Например, для правила кеширования страниц .aspx на срок до 30 минут, с учетом HTTP-заголовка Accept-Language, будет сгенерирован следующий код в конфигурационном файле:

Кеширование в пространстве ядра

В отличие от механизма кеширования в пространстве пользователя, сохраняющего информацию в памяти рабочего процесса IIS, механизм кеширования в пространстве ядра сохраняет информацию в памяти драйвера HTTP.sys. Кеширование в пространстве ядра обеспечивает более короткое время отклика, однако оно поддерживается не всегда. Например, кеширование в пространстве ядра нельзя использовать, когда запрос содержит строку с параметрами запроса или когда запрос не является анонимным запросом.

Настройка правил кеширования в пространстве ядра выполняется почти так же, как кеширование в пространстве пользователя. В диалоге настройки правила установите флажок Kernel-mode caching (Кеширование в режиме ядра) и выберите желаемый способ кеширования.

В одном правиле допускается использовать оба режима кеширования, в пространстве ядра и в пространстве пользователя. В этом случае IIS будет сначала пытаться применить кеширование в пространстве ядра. Если попытка не увенчается успехом, например, когда запрос содержит строку с параметрами, применяется кеширование в пространстве пользователя.

Если выбран вариант кеширования на определенный интервал времени в обоих режима, в пространстве ядра и в пространстве пользователя, оба интервала должны совпадать, в противном случае в обоих режимах будет использоваться интервал, установленный для кеширования в режиме ядра.

Настройка пула приложения

Параметры настройки пула приложения определяют, как IIS будет создавать и поддерживать рабочие процессы, в рамках которых будет выполняться наш код. В ходе установки IIS и ASP.NET создается несколько пулов приложений, в зависимости от установленной версии .NET, к которым вы можете добавлять новые пулы, по мере развертывания дополнительных веб-приложений. При создании пула приложения, он получает некоторые параметры настройки со значениями по умолчанию, управляющие его поведением. Например, каждый пул получает тайм-аут простоя, после которого этот пул приложения останавливается.

Понимание значения некоторых из этих настроек может помочь вам настроить работу пула и тем самым более полно удовлетворить потребности приложения.

Перезапуск

Изменяя параметр настройки перезапуска можно управлять моментом, когда пул приложения будет перезапускать рабочий процесс. Например, можно организовать перезапуск рабочего процесса через каждые несколько часов или когда будет превышен некоторый предел занимаемой памяти. Если с течением времени веб-приложение начинает потреблять большие объемы памяти (например, для хранения объектов), увеличение количества перезапусков может помочь удерживать его производительность на высоком уровне. С другой стороны, если веб-приложение не проявляет никаких проблем в процессе работы, уменьшение количества перезапусков предотвратит потерю информации о состоянии.

Для проверки количества и частоты перезапусков пула приложения можно использовать счетчик производительности ASP.NET\Worker Process Restarts. Если вы увидите слишком большое количество перезапусков без явной на то причины, попробуйте сопоставить полученные значения с потреблением памяти приложением и нагрузкой на процессор, потому что перезапуски могут быть обусловлены превышением других пределов, определяемых настройками пула приложения.

Тайм-аут простоя

По умолчанию пул приложения прекращает работу через 20 минут простоя. Если такие перерывы в работе ожидаемы, например, когда все пользователи уходят на обед, попробуйте увеличить тайм-аут или даже вообще отменить его.

Привязка процессов к ядрам процессора

По умолчанию пул приложения настроен так, что может использовать все доступные ядра процессора. Если у вас имеется какой-либо специализированный фоновый процесс, использующий все процессорное время, какое ему будет выделено, можете настроить привязку пула к определенным ядрам, освободив остальные для фонового процесса. Разумеется, при этом также потребуется настроить привязку фонового процесса к другим ядрам процессора, чтобы избежать конкуренции между ним и рабочим процессом за одни и те же ядра.

Веб-сад

По умолчанию пул приложения запускает один рабочий процесс, обслуживающий все запросы, поступающие приложению. Если рабочему процессу приходится одновременно обрабатывать несколько запросов, конкурирующих за обладание одним и тем же ресурсом, это может привести к задержкам при подготовке ответов.


Например, если приложение использует патентованный механизм кеширования с блокировками, препятствующими одновременному добавлению элементов в кеш, при обработке запросов потребуется синхронизировать операции с ними, что приведет к задержкам, которые непросто будет выявить и устранить. Иногда можно исправить код, чтобы уменьшить использование блокировок, но такая возможность существует не всегда. Другой способ устранения конкуренции за ресурсы — запустить несколько рабочих процессов, выполняющих одно и то же приложение, каждый из которых обрабатывает собственное подмножество запросов, устраняя тем самым ненужную конкуренцию.

Другим примером, когда может пригодиться наличие нескольких процессов, выполняющих одно и то же веб-приложение — использование 64-разрядного сервера IIS, выполняющего 32-разрядное веб-приложение. 64-разрядные серверы обычно имеют большой объем памяти, а 32-разрядное приложение может использовать не более 2 Гбайт, что часто приводит к увеличению частоты сборки мусора и, вероятно, к перезапускам пула приложения. Поддерживая два или три рабочих процесса для 32-разрядного веб-приложения, можно добиться более полного использования памяти сервера, уменьшить частоту сборки мусора и перезапусков пула приложения.

В настройках IIS пула приложения можно определить максимальное количество рабочих процессов, которое можно запустить для обслуживания запросов. Если установить этот параметр в значение больше 1 (значение по умолчанию), с ростом нагрузки на веб-приложение для него будут запускаться дополнительные рабочие процессы, вплоть до указанного максимума. Пул приложения, имеющий более одного процесса, называется «веб-садом» («Web Garden»). Каждый раз, когда устанавливается соединение с клиентом, оно связывается с рабочим процессом, который будет обслуживать запросы от этого клиента, при этом соблюдается равномерное распределение запросов от пользователей между процессами и уменьшаются накладные расходы на конкуренцию.

Имейте в виду, что использование веб-сада имеет и недостатки. Большее количество рабочих процессов занимает больший объем памяти, исключается возможность использовать механизм по умолчанию хранения информации о сеансе в памяти процесса, при выполнении нескольких рабочих на одном компьютере, между ними может возникать конкуренция за локальные ресурсы, например, за использование общего файла журнала.

Iis расчет быстродействия для подключения

Ключевое свойство Microsoft IIS 5.0 — высокая производительность. Для повышения уровня производительности IIS разработчики Microsoft усовершенствовали многие компоненты IIS, например Active Server Pages (ASP). Для максимально быстрого подключения IIS необходимо внести некоторые изменения в конфигурацию IIS и настройки системы Windows 2000.

Механизм ASP в IIS 5.0 работает значительно быстрее, чем в IIS 4.0. Тестирование в компании Microsoft показало — приложения, построенные с использованием только ASP, в IIS 5.0 выполнялись чуть ли не вдвое быстрее, чем они это могли в IIS 4.0. Такое повышение скорости системы способствует тому, что ASP- приложение, запущенное на IIS 5.0, может поддерживать в два раза больше пользователей и в тоже время иметь такую же производительность, как если бы оно запускалось на IIS 4.0. При работе с IIS 5.0 производительность системы будет изменяться в зависимости от ее конфигурации (количества процессоров, размера памяти, конфигурации сети).

Значительное повышение производительности IIS 5.0 обусловлено свойствами системы Windows 2000, использующей многопроцессорную конфигурацию. Приложения, работающие на многопроцессорных системах Windows 2000, функционируют намного быстрее, чем приложения, запущенные на многопроцессорных системах Windows NT. Эффективная работа нескольких процессоров повышает производительность ASP. Тестирование производительности приложений (с помощью таких программ, как Vertigo Software`s Fitch & Mather Stocks 2000 – FMStocks 2000) показывает, что по производительности система Windows 2000 превосходит Windows NT 4.0. Так как IIS 5.0 запускается поверх Windows 2000, повышение эффективности работы системы Windows 2000 как сервера приложений оказывает влияние на быстродействие IIS 5.0.

Дополнительные характеристики, такие как Application Protection в IIS 5.0, управление компонентами и работа с общими файлами в Windows 2000, также влияют на производительность IIS 5.0. Давайте рассмотрим эти возможности и некоторые специальные настройки IIS 5.0 с точки зрения предстоящего увеличения производительности.

Application Protection

Функция Application Protection в IIS 5.0 дает возможность запускать приложения в изолированных областях памяти. Это позволяет увеличить стабильность системы, при выполнении обработки приложений вне IIS.

Существует три режима защиты приложений Application Protection в IIS 5.0 — Low (IIS Process), Medium (Pooled) и High (Isolated). Можно изменить настройку Application Protection на закладке Home Directory страницы Properties для сайта, как показано на Рис.1, или на странице Virtual Directory Properties (чтобы добраться до обеих страниц Properties, откройте Internet Services Manager (ISM), нажмите правую кнопку мыши на Web-сайте или Virtual Directory, который хотите изменить, а затем выберите Properties). Приложение ASP в режме защиты Low (IIS Process) работает в том же пространстве процесса (т.е. inetinfo.exe), что и сам IIS. Если происходит отказ приложения и нарушение доступа к памяти у IIS или серьезный сбой другого важного серверного процесса, то IIS и все другие Web-приложения тоже могут завершиться аварийно.

Рис.1. Выбор Application Protection в IIS 5.0

При использовании режима Medium (Pooled) Application Protection приложение запускается со всеми другими связанными с ним приложениями в процессе dllhost.exe. Как и при режиме защиты Low (IIS Process), если одно из приложений, использующее способ защиты Medium (Pooled) выходит из строя, это может послужить причиной сбоя всех приложений, запущенных в той же рабочей области.

Настройка защиты High (Isolated) в IIS 5.0 подобна настройке Run in separate memory space в IIS 4.0. При использовании этой настройки для ASP-приложения в IIS 4.0 оно помещается в отдельный пакет Microsoft Transaction Server (MTS). Передача приложения к MTS увеличивает стабильность, отделяя работу приложения от IIS, но в то же время значительно снижая производительность приложения. Это связано с тем, что внепроцессное исполнение пакета MTS приводит к непроизводительным издержкам.

Настройка Application Protection в IIS 5.0 выполняется не так, как настройка защиты в IIS 4.0. При выборе ASP-приложения для работы в режиме High (Isolated) в IIS 5.0 ISM создает новое COM+ приложение и помещает в него ASP (в Component Services Explorer название нового приложения будет выглядеть как IIS–, заключительная часть имени – DNATestProject1KLS является именем приложения). Каждое высокозащищенное приложение запускается в отдельной копии dllhost.exe, и если происходит сбой приложения, это не станет причиной остановки для других приложений.

Приложения, запускаемые в Medium (Pooled) или High (Isolated) режимах защиты в IIS 5.0, показывают значительное повышение производительности по сравнению с идентичным приложением, выполняемым в IIS 4.0, согласно статье «Leveraging ASP in IIS 5.0» в Microsoft Developer Network (MSDN). Автор статьи обращает внимание на то, что использование установки защиты Medium (Pooled) в IIS 5.0 обычно дает более высокую производительность, чем внутрипроцессные приложения в IIS 4.0. Этот способ, связанный с установкой защиты Medium (Pooled) в IIS 5.0, перемещает приложение в более изолированную среду и, кроме того, увеличивает производительность. Даже при установке защиты High (Isolated) приложение будет выполняться быстрее, чем если бы оно было запущено в IIS 4.0.

Компоненты

Управление компонентами в IIS 5.0 также повышает производительность по сравнению с IIS 4.0. Всем разработчикам для IIS 5.0 при работе с компонентами необходимо помнить о предоставлении механизму ASP права отпускать объект в тот момент, когда приложение в нем больше не нуждается. Освобождение ненужных объектов освобождает ценные ресурсы.

IIS 4.0 не освобождает объекты до тех пор, пока страницу со ссылкой на объект не перестанут использовать. Для страниц, обрабатываемых длительное время, задержка освобождения объекта может добавить значительные непроизводительные издержки в работе приложения. Низкая производительность является результатом того, что выполнение страницы не завершается до тех пор, пока все объекты не обработаны, а код ASP не выполнен до конца.

Выигрыш в производительности обеспечивается за счет быстрого освобождения ненужных объектов, и это особенно заметно, когда многие пользователи обращаются к приложению одновременно. Когда это происходит в IIS 4.0, каждая страница привязывает объект и держит его в памяти до тех пор, пока страница заполняется, используя в это время дополнительные ресурсы и таким образом снижая производительность.

Для освобождения объекта можно использовать код VBScript. Например,

присвоит переменной oCust, которая содержит ссылку на объект, ключевое слово Nothing, удаляющее ссылку. Этот код заставляет механизм ASP немедленно освободить объект, на который указывает oCust.

Дополнительные настройки

Метабаза IIS 5.0 содержит параметр ASPProcessorThreadMax, который в IIS 4.0 назывался ProcessorThreadMax и находился в реестре. Разработчики Microsoft изменили значение по умолчанию для этого параметра с 10 в IIS 4.0 на 25 в IIS 5.0. Это изменение может повысить производительность, поскольку процесс ASP будет обрабатываться большим количеством потоков. Если система имеет достаточно процессоров и скорости их работы хватает для использования большего числа потоков, новая настройка позволит сделать процесс ASP более эффективным. При использовании IIS 5.0 эту настройку указывать не нужно, пока тестирование системы не покажет, что настройка по умолчанию является узким местом.

Если на сервере установлена служба Indexing Service, то можно повысить производительность, используя ISM для отключения параметра Index this resource . Если приложение создает HTML-файл из базы данных или другого источника, и не используются статические HTML-файлы, которые пользователям необходимо будет найти, то в этом случае параметр Index this resource можно отключить, так как службе Indexing Service индексирование таких файлов, скорее всего, не потребуется. Отключение этого параметра сокращает непроизводительные издержки сервера при выполнении ASP-приложения, что может несколько повысить производительность.

Можно использовать закладку Performance страницы Properties для настройки памяти, которая применяется в IIS 5.0 для обработки подключений и ресурсов Web-сайта. В документации по IIS говорится о необходимости установки ползунка Performance Tuning немного выше того количества ответов в день, которые ожидается получать на сайте. Можно изменить настройку «ответов в день», перемещая ползунок в соответствии с количеством ответов (т.е. менее чем 10 000, менее чем 100 000, более чем 100 000). При перемещении ползунка к большему числу задействуется больший объем доступной памяти для обработки ресурсов Web-сайта.

Параметр Enable process throttling – новый на закладке Performance в IIS 5.0, позволяет IIS ограничивать время процессора, которое механизм ASP расходует на выполнение приложений с установленным режимом защиты High (Isolated). Когда включается этот параметр, приложения с высоким уровнем защиты по умолчанию могут использовать не более 10 % времени работы процессора в течение 24 часов. Если приложение превышает этот предел, IIS записывает сообщение в журнал регистрации событий. Можно активизировать Enforce limits, чтобы заставить IIS выбрать более решительное действие, например, остановку всех внепроцессных приложений, если приложение превысит предел. Если планируется ускорить выполнение процесса, следует предварительно почитать документацию по IIS.

Илон Маск рекомендует:  Dos fn 62h дать адрес psp


Защитные функции вступают в компромисс с производительностью IIS 5.0. Активизация настроек защиты в IIS или Windows 2000 включает функции, которые, должны контролировать или выполнять какие-либо процессы. Защита добавляет уровень непроизводительных издержек в каждую задачу, оказывая на нее воздействие. Если другой защиты доступа, кроме анонимного, не нужно, то другие типы защиты (например, Secure Sockets Layer (SSL)) включать не требуется.

Защита существует во многих местах. Windows 2000, IIS, COM+ и SSL имеют настройки, которые могут воздействовать на систему, делая ее более или менее защищенной. Необходимо понять, насколько мощная защита требуется системе, и как уровень защиты будет влиять на ее производительность. Например, совместное тестирование в лаборатории, где я работал, показало, что отдельное приложение, использующее Visual Basic (VB) и ASP, могло обслуживать 250 страниц в секунду. Изменение только одной настройки защиты в COM+ увеличивало производительность на 950-1000 страниц в секунду.

Доступ к общим файлам

Можно использовать режим File Sharing системы Windows 2000 для повышения производительности IIS 5.0, изменяя настройку File Sharing для сетевого адаптера, который обрабатывает входящие HTTP-запросы. Для этого нужно нажать Start, Settings, Network и Dialup Connections и перейти к окну, которое показано на Рис.2. Затем нажмите правую кнопку мыши на том подключении, которое хотите изменить, и выберите Properties. На закладке Server Optimization следует выбрать Maximize data throughput for network applications и нажать OK. Эта настройка оптимизирует использование памяти системой Windows 2000 применительно к сетевым приложениям, которые выполняют кэширование, таким как Microsoft SQL Server и IIS. Эта настройка также предохраняет Windows 2000 от выгрузки рабочих данных IIS, перенося их из памяти на диск при снижении объема доступной памяти системы. Предотвращение такой выгрузки может резко поднять производительность. На сервере, который имеет несколько адаптеров (т.е. многодомном сервере), можно установить настройки File Sharing для каждого используемого подключения.

Рис.2. Окно диалога File Sharing

Аппаратный фактор

Аппаратное обеспечение сильно влияет на производительность IIS 5.0. Группа разработчиков лаборатории компании Microsoft тестировала различные аппаратные платформы для Web-серверов IIS. Разработчики сравнили производительность IIS на мощных серверах с оперативной памятью 512 Мбайт, быстродействующими дисками и несколькими процессорами с производительностью IIS на серверах с меньшим объемом оперативной памяти (128 Мбайт), стандартными IDE-дисками и несколькими процессорами. Лучшими Web-серверами были признаны те, которые имели несколько быстрых CPU. Ни размер памяти, ни тип интерфейса диска (например, SCSI, IDE), ни скорость процессора не оказывала значительного влияния на производительность IIS. Результаты тестирования показали, что можно добиться заметного роста производительности, увеличивая количество процессоров. Если использовать Network Load Balancing (NLB) или аппаратное решение (например, маршрутизатор, который обеспечивает циклическое переключение к DNS), можно повысить производительность, добавляя большее количество компьютеров.

Лабораторные тесты и практический опыт внедрения IIS 5.0 на системе Windows 2000 показывает, что использование настроек по умолчанию и внесение выборочных изменений только в определенные параметры будет способствовать повышению производительности. Не изменяйте настройки по умолчанию для сетевого интерфейса системы до тех пор, пока не протестируете производительность системы и не сможете точно оценить, как отразится на ней каждое изменение.

Десять лучших способов улучшения производительности IIS 7.0

Посетителей: 11846 | Просмотров: 14496 (сегодня 2) Шрифт:

Чтобы понять причину этого явления, необходимо сначала разобраться с сутью последнего выпуска IIS. Версия IIS 6.0 содержала существенные технологические изменения, направленные на достижение трех целей: повышение уровня безопасности, увеличение надежности и улучшение производительности. Выпуск версии IIS 7.0 преследовал совершенно иную цель: на основе высокопроизводительного кода базовых компонентов веб-сервера, написанного для версии 6.0, создать модульную и расширяемую платформу, которая поддерживала бы основные сценарии развертывания веб-приложений и управления ими.

Многие архитектурные изменения и новые функции этой версии могут отрицательно воздействовать на производительность веб-сервера. Например, одним из основных изменений стало разделение компактных и оптимизированных ветвей кода веб-сервера на изолированные модули, которые не подвергаются никакой специальной обработке со стороны веб-сервера. Однако в результате огромной работы по улучшению производительности, выполненной группой разработки IIS, его производительность осталась примерно такой же, как и у его предшественника, а в некоторых случаях даже повысилась. Как разработчик основных компонентов веб-сервера и интегрированного конвейера я могу сказать, что такой результат был достигнут в результате искусного проектирования и кропотливой работы над созданием продукта.

Тем не менее, у IIS 7.0 есть намного большие возможности по значительному приросту скорости работы и снижению затрат, связанных с производительностью фермы серверов, чем любая другая предыдущая версия IIS.

Скорее всего, просто переход на IIS 7.0 не выявит всех преимуществ нового веб-сервера, хотя в некоторых случаях и этого будет достаточно. Например, на узле Microsoft.com было отмечено 10-процентное улучшение эффективности использования ЦП (полный анализ доступен в блоге группы разработки Microsoft.com наgo.microsoft.com/fwlink/?Link >® (оба процесса теперь выполняются на уровне ядра), а также улучшение вертикальной масштабируемости на многопроцессорных и многоядерных машинах.

Однако основная мощность IIS 7.0 состоит не в пошаговом улучшении производительности существующих функций. Напротив, главные усовершенствования заключаются в новых возможностях, которые нужно активно использовать. Эти возможности основываются на гибкости и расширяемости новой платформы, а также на новых функциях повышения производительности. В этой статье я расскажу вам о 10 наиболее важных способах улучшения производительности, которые станут вам доступны после перехода на IIS 7.0.

Экономичные веб-серверы

Возможность развертывать экономичные серверы IIS 7.0 обеспечивается их модульной архитектурой. Практически все функции веб-сервера реализованы в виде модульных компонент, которые можно добавлять и удалять независимо друг от друга. Таким образом можно убрать все ненужные для приложения операции, что приведет к существенному уменьшению области, открытой для атак и ресурса, используемого операциями, а также к улучшению производительности.

Полный набор функций веб-сервера IIS 7.0 состоит из 44 модулей, включая собственные модули IIS и ASP.NET, предоставляющие службы для интегрированного конвейера. В модулях реализованы такие функции, как проверка подлинности (модули проверки подлинности Windows и дайджест-проверки подлинности), поддержка инфраструктуры приложения (модуль FastCGI), службы приложений (модуль состояния сеанса), обеспечение безопасности (модуль фильтрации запросов) и производительности (модуль кэширования выходных данных). Однако минимальному веб-серверу, обслуживающему статические страницы, для работы требуется всего 2 модуля!

Количество дополнительные данных от неиспользуемых модулей может быть довольно значительным — например, от модуля записи запросов в журнал или от модуля трассировки неудачно завершившихся запросов. Если удалить эти модули из окружения, где они не нужны, можно получить прирост общей пропускной способности и уменьшение времени реакции сервера, что в свою очередь улучшит такие характеристики нагрузки на сервер, как время до получения первого байта (TTFB) и время до получения последнего байта (TTLB).

На рис. 1 показаны результаты простых тестов пропускной способности для HTML-файла (статическая нагрузка) и страницы «Здравствуй, мир», написанной на ASP.NET (нагрузка ASP.NET). Использовались три конфигурации веб-сервера: с полным набором функций, с предлагаемым по умолчанию набором функций для каждого типа нагрузки и с минимальным набором необходимых для каждого типа нагрузки функций. Можно заметить, что, хотя большинство необязательных функций отключены даже в полной конфигурации сервера, пропускную способность можно существенно увеличить как в случае статической нагрузки, так и при работе ASP.NET, если полностью удалить ненужные функции.

Рис. 1. Пропускная способность сервера при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами

Кроме того, может снизиться объем занимаемой памяти и повыситься плотность веб-узлов, особенно в случае сред совместного размещения или при использования большого количества рабочих процессов. Это происходит за счет уменьшения количества библиотек DLL, загружаемых каждым процессом, а также количества запросов на выделение памяти, происходящих при инициализации модуля и обработке запроса. На рис. 2 изображено использование памяти (в байтах исключительного использования рабочими процессами IIS) в тестах пропускной способности, о которых говорилось выше. И, хотя приведенные в этом примере изменения не так заметны, они, тем не менее, соответствуют всем ожиданиям. Дело в том, что поддержка приложений ASP.NET требует больше служебных данных, чем можно высвободить удалением модулей.

Рис. 2 Использование памяти (в байтах исключительного использования рабочими процессами IIS) сервером при статической нагрузке и работе с ASP.NET в трех разных конфигурациях со 100 параллельно подключенными клиентами

При помощи наборов необходимых условий IIS 7.0 также предоставляет дополнительные возможности по управлению тем, какие модули будут включены на уровне приложения, а также по использованию модулей в зависимости от рабочей нагрузки на них. Хотя для этого и потребуется профессиональная настройка веб-сервера, многоузловые серверы или приложения с несколькими видами рабочей нагрузки могут получить значительные дополнительные преимущества.

В качестве предупреждения: определение требующегося набора функций — непростая задача. Необходимо принять во внимание не только минимальные возможности, требующиеся для работы приложений, но и любые дополнительные функции, которые могут неявно использоваться приложением. Например, приложение может зависеть от собственных методов проверки подлинности пользователя, а может полагаться на средства авторизации, предоставляемые различными возможностями IIS. В последнем случае удаление этих функций может снизить уровень безопасности приложения. Подобным образом приложение может опираться на некоторые технически необходимые или повышающие производительность функции. В этом случае удаление модуля с этими функциями может повлечь за собой неверную работу приложения или снижение его производительности.

Использование экономичной операционной системы

В Windows Server ® 2008 реализовано выделение компонентов на уровне операционной системы, посредством чего можно дополнительно сократить контактную зону веб-сервера. Минимальным режимом установки Windows Server 2008 является режим «Server Core», который содержит минимальный набор основных подсистем операционной системы. Для экономичных веб-серверов на базе IIS 7.0 лучшим вариантом установки является именно Server Core.


Однако, рассматривая возможности Server Core, необходимо учитывать, какие его ограничения могут отразиться на работе вашего приложения. В Server Core отсуствует поддержка платформы Microsoft ® .NET Framework, то есть нет ASP.NET, расширений.NET для IIS и диспетчера служб IIS. Кроме того, решение задач местного управления потребует использования средств командной строки, поскольку консоль управления (MMC) также отсутствует. Между приложениями, работающими под управлением Server Core и полной версией Windows Server, не будет особых отличий в объеме занимаемой памяти и пропускной способности приложений, если уже были использованы преимущества компонентной структуры IIS. Работа, выполняемая IIS и вашими приложениями, одинакова на обеих платформах. Однако есть характеристика, где разница будет заметна: место, занимаемое сервером, как на жестком диске, так и в оперативной памяти.

В качестве примера на рис. 3 показана разница в занимаемом объеме после одинаковой статической рабочей нагрузки на серверы, работающие под управлением Windows Server 2008 в полной конфигурации и Server Core. Хотя IIS занимает в обоих случаях почти одинаковое место, общий объем места, занимаемого операционной системой Server Core меньше, что позволяет поддерживать ту же рабочую нагрузку, используя существенно меньший объем памяти. Из-за меньшего размер установки может появиться возможность использовать менее мощное аппаратное обеспечение для работы приложения. При этом основная мощность процессора будет тратиться на обработку запросов приложения, а не операционной системы, что делает Server Core отличным вариантом для виртуализированных сред.

Рис. 3. Память, занимаемая Windows Server 2008 в полной конфигурации и Server Core после выполнения теста на статическую нагрузку

Применение топологий, адаптированных для нужд приложения

Оптимизируя нагрузку на приложение, в ней можно выделить отдельные части. Например, вместо 30 одинаковых веб-серверов можно обойтись 10 веб-серверами, 3 серверами приложений и 3 прокси-серверами, последние из которых будут выполняли бы кэширование и сжатие данных.

Такая специализация работает по нескольким причинам. Во-первых, производительность многих приложений сильно зависит от разных ресурсов, используемых совместно, таких как память. Части одного и того же приложения могут конкурировать за доступ к таким ресурсам. Такая конкуренция может приводить к образованию узких места и, а это, в свою очередь, будет мешать всем серверам воспользоваться ресурсом. Выделение разных частей приложения позволяет предоставить им доступ к ресурсам, за которые в другом была бы возможна конкуренция, таким образом повышая эффективность их использования.

Во-вторых, специализация может привести к тому, что приложение будет лучше размещено в кэше, что увеличит его производительность. Это относится к кэшам низкого уровня, таким как аппаратный буфер TLB виртуальной памяти, кэш файловой системы, а также другие средства кэширования, реализуемые как операционной системой, так и приложением. Другим источником хорошего местоположения является ЦП. Уменьшение числа одновременно выполняемых операций путем уделения основного внимания только определенной части приложения позволяет уменьшить количество переключений контекста максимально увеличить объем работы, выполняемой ЦП.

В-третьих, специализация обеспечивает возможность оптимизации рабочих нагрузок, повышая эффективность работы всех частей приложения. Множество из этих оптимизаций невозможны при поддержке всего приложения на одном сервере из-за противоречия потребностей различных частей приложения.

Это возможно только в конфигурации потоков IIS и ASP.NET, которая существенно влияет параллелизм и косвенно сказывается на использовании памяти, задержке и пропускной способности множества приложений. Рабочая нагрузка статического файла IIS крайне асинхронна и требует максимального уровня одновременных запросов, но использует очень небольшое количество доступных потоков. С другой стороны, многие функции ASP.NET синхронны, отличаются длительной блокировкой и требуют большого количества потоков, тогда как для других функций требуется более низкий предел параллелизма для снижения воздействия на память. Путем выделения статической нагрузки и поврежденных частей конвейера обработки процессов в отдельный процесс или сервер можно оптимизировать параллелизм каждой отдельной нагрузки.

Наконец, специализация может повысить уровень общей масштабируемости, позволяя приложению выполнять масштабирование отдельных нагрузок или частей приложения независимо друг от друга. Это позволяет топологии приложения увеличивать производительность и избыточность там, где это необходимо, вместо необходимости применения одного шаблона ко всему приложению. В этой модели специализированными ресурсами могут быть физические серверы, виртуальные серверы или даже пулы приложений на одном компьютере.

Оценку возможных преимуществ специализации в топологии приложения необходимо начать с поиска обработки или ограничений приложения, требующих существенных затрат ресурсов. Эти области должны быть первыми кандидатами на специализацию, поскольку при изоляции они могут обеспечить значительные возможности для оптимизации, а также потому, что для них потребуется наибольшее горизонтальное масштабирование. Затем необходимо оценить, позволит ли изоляция более эффективно использовать ресурсы остальным частям приложения. Наконец, потребуется оценить перегрузку механизма подключения, необходимую для объединения изолированных компонентов приложения.

Улучшенная поддержка приложения

Службы IIS 7.0 включают в себя расширенную поддержку платформ приложений с помощью FastCGI, открытого протокола, поддерживаемого множеством платформ приложений с открытым исходным кодом, которые в противном случае могут не поддерживать надежную и высокопроизводительную собственную интеграцию с IIS. В отличие от протокола CGI, который в течение длительного времени поддерживался IIS, FastCGI обеспечивает значительно улучшенную производительность на платформе Windows. В основном это обусловлено архитектурой многократно используемых процессов FastCGI, уменьшающей значительные затраты на создание процессов для отдельных запросов, что позволяет клиентам использовать преимущества постоянных открытых соединений.

При поддержке платформ приложений в IIS с помощью CGI или другого механизма можно улучшить производительность (а в некоторых случаях и стабильность) путем перехода на протокол FastCGI.

Первой платформой приложений, использующей преимущества этой поддержки, является PHP. Группа разработчиков IIS фактически напрямую работала с компанией Zend Technologies для обеспечения успешной работы реализации FastCGI IIS с PHP и улучшения производительности платформы PHP в Windows. (Более подробные сведения об этом проекте см. в моем блоге по адресу go.microsoft.com/fwlink/?Link >

Перенос PHP и других платформ приложений на IIS 7.0 и FastCGI позволит использовать преимущества различных функций IIS 7.0, в том числе интегрированный контейнер ASP.NET. Это предоставляет очень удобный способ улучшения платформ приложений при помощи служб ASP.NET без их преобразования в ASP.NET. Это также позволяет совместно работать приложениям, использующим различные платформы. Пример использования этого для улучшения существующих приложений при помощи функций и повышения производительности без изменения кода см. в моей статье «Улучшите приложения при помощи интегрированного конвейера ASP.NET» в журнале MSDN ® Magazine (доступна по адресу msdn.microsoft.com/magazine/cc135973.aspx).

Увеличенная плотность приложений

IIS 7.0 включает множество улучшений, предназначенных для увеличения плотности приложений, которые могут быть размещены на одном сервере. Эти улучшения являются некоторыми из множества функций IIS 7.0, направленных на улучшение качества совместного размещения, которые включают улучшенную подготовку узлов и лучшую изоляцию приложений.

С точки зрения производительности улучшения главным образом касаются двух аспектов увеличения плотности приложений — увеличение количества приложений, которые могут быть подготовлены на сервере IIS 7.0, и количества приложений, которые могут быть активны в любое заданное время.

Обратите внимание на то, что службы IIS 7.0 теперь позволяют подготавливать на каждом сервере больше приложений, чем раньше — в нескольких внутренних тестах достигалась цифра в 100 000 узлов на одном сервере. Это обеспечивает возможность создания и настройки большого числа узлов и приложений.

Илон Маск рекомендует:  Комплект GEO-скриптов + база данных

В качестве предупреждения: для достижения высокоскоростной подготовки необходимо перейти на новые API настройки, поскольку старые API настройки не позволяют этого. Кроме того, не все API настройки IIS предоставляют одинаковые характеристики производительности, поэтому для обеспечения максимальной производительности необходим тщательный выбор API. При возникновении сомнений используйте параметры конфигурации, которые напрямую используют новые объекты настройки IIS, включая пространство имен Microsoft.Web.Administration, служебную программу командной строки AppCmd.exe и объекты настройки IIS COM, которые можно вызвать из сценария, кода .NET или C++.

Разница между количеством узлов, которые могут быть подготовлены и которые могут быть активны – очень важное отличие архитектуры IIS, постоянно использующей приложения и рабочие процессы для выполнения обработки запроса. В этой модели активные приложения потребляют больше ресурсов на сервере, но обеспечивают постоянную лучшую производительность благодаря кэшированию и отсутствию затрат на инициализацию.

Поскольку для каждого активного приложения необходим определенный объем памяти и рабочий процесс (при использовании рекомендуемой модели изоляции приложений), количество активных приложений сильно зависит от объема памяти приложения. Поэтому хотя для рабочего процесса одного приложения, выполняющего только обслуживание статического содержимого, требуется всего 3 МБ (подобные приложения часто могут использовать рабочий процесс совместно с другими приложениями, работающими со статическим содержим), для некоторых динамических приложений может требоваться 100 МБ ОЗУ или больше даже при низкой загрузке. Это обуславливает незначительную загрузку памяти самим рабочим процессом IIS по сравнению с местом, которое занимает приложение, при определении максимальной возможной плотности.

В типичном сценарии совместного размещения часто можно увидеть так называемое распределение 80/20, когда 80 процентов запросов выполняются к 20 процентам узлов. Результат – небольшой процент активных узлов в любой определенный момент времени. Для обеспечения большего количества активных узлов службы IIS 7.0 предоставляют активное управление временем существования. Это помогает высвободить память неактивных приложений, чтобы можно было разместить большее количество активных приложений.

В IS 7.0 появился новый алгоритм под названием «динамический простой», заблаговременно регулирующий тайм-ауты простоя рабочих процессов на основе доступной на сервере памяти. При нехватке памяти простаивающие приложения удаляются более быстро, что обеспечивает размещение большего количества приложений. Однако при наличии доступной памяти тайм-ауты могут оставаться большими для обеспечения лучшей производительности и поддержания состояния приложения. Помимо большего количества приложений, которые могут быть активными, динамический простой позволяет избежать условий нехватки памяти, вызывающих существенное снижение производительности сервера из-за пробуксовки.

Для обеспечения возможности размещения множества активных приложений также следует использовать преимущества 64-разрядной операционной системы, заключающиеся в возможности использования более 4 ГБ ОЗУ. На основе этого можно настроить рабочие процессы IIS для работы в 32-разрядном режиме (SysWoW64), в котором они используют меньше памяти, одновременно позволяя операционной системе работать с большим объемом памяти, чем возможно в 32-разрядной среде.

Сокращение занимаемой полосы пропускания за счет сжатия данных

Неудивительно, что затраты на полосу пропускания – одни из самых больших затрат при работе центра обработки данных, имеющего выход в Интернет. Кроме того, полоса пропускания, необходимая для предоставления запрошенного содержимого, является ключевым фактором воспринимаемой скорости работы вашего приложения.


Одним из наиболее эффективных способов уменьшения полосы пропускания, необходимой для доставки ответов приложения, является использование сжатия HTTP. Оно позволяет значительно уменьшить размер ответа, часто даже в 10 раз, для просто сжимаемого содержимого, такого как HTML. Лучше всего то, что сжатие HTTP поддерживают практически все обозреватели для настольных систем, а затраты на распаковку на оборудовании настольных систем минимальны по сравнению с неявной экономией отправки меньшего количества данных. А поскольку сжатие основано на согласовании кодировки содержимого, определенном в протоколе HTTP 1.1, включение этой функции безопасно для клиентов, не поддерживающих сжатие — эти клиенты просто получают несжатую версию содержимого.

Службы IIS 7.0 предоставляет две функции сжатия, представленные в их предшественнике: статическое сжатие и динамическое сжатие. Статическое сжатие выполняет предварительное сжатие статического содержимого и сохраняет его на диск, таким образом, позволяя будущим запросам работать напрямую со сжатым содержимым без затрат на сжатие. Динамическое сжатие выполняет сжатие ответов в реальном времени, и позволяет сжимать созданные приложениями ответы. Все платформы приложений на IIS 7.0 могут использовать преимущества динамического сжатия, включая ASP, ASP.NET и PHP.

Несмотря на распространенный миф, обычно динамическое сжатие не вызывает чрезмерную загрузку ЦП. Фактически, часто динамическое сжатие использует меньше 5 процентов ресурсов ЦП загруженного сервера. Динамическое сжатие может использоваться довольно свободно, обеспечивая максимальную экономию полосы пропускания для выполняющихся приложений.

Можно дополнительно оптимизировать загрузку сжатия, настроив уровень сжатия для достижения необходимого соотношения сжатия и загрузки ЦП. Но на этом все не заканчивается — также можно настроить приложение для поддержки кэширования сжатого содержимого, что устраняет загрузку сжатия на попадания в кэше благодаря работе с уже сжатым содержимым. Имейте в виду, что в кэши вывода ASP.NET и IIS включена дополнительная возможность кэширования сжатого содержимого для поддерживающих это клиентов, а также обработка запросов клиентов, для которых необходимо несжатое содержимое.

Регулировка полосы пропускания для мультимедийных файлов

С увеличением числа узлов, предоставляющих медиа-содержимое, затраты на полосу пропускания для многих организаций значительно возросли. Что еще хуже, теряется большая часть полосы пропускания мультимедиа из-за того, что отправленное клиенту медиа-содержимое никогда в действительности не используется. Почему это происходит?

Вспомните, когда вы последний раз смотрели интерактивное видео или видели видеорекламу при просмотре веб-узлов. Вы досмотрели видео до конца? Чаще всего пользователи, посещающие узлы с видео, просматривают только часть видео до того, как перейти к следующему или уйти с веб-страницы. Однако веб-сервер, использующий прогрессивную загрузку для предоставления видео, обычно отправляет гораздо больше данных, чем необходимо для этих нескольких секунд воспроизведения. Большая часть данных никогда не используется.

Если среднее время просмотра ваших видео составляет всего 5 секунд, но за это время предоставляются (буферизируются) видеоданные длительностью 30 секунд, скорее всего, вы теряете более 80 процентов полосы пропускания!

Год назад для разрешения этой проблемы для клиента, переходящего на бета-выпуск IIS 7.0, я написал модуль регулировки полосы пропускания, автоматически определяющий скорость видео и обеспечивающий предоставление сервером видео клиенту приблизительно с этой же скоростью. Группа мультимедиа IIS использовала этот модуль, называющийся модулем регулировки скорости (см. рис. 4 ) и доступный в центре загрузок iis.net (iis.net/downloads/?tab >

Рис. 4. Регулировки скорости уменьшает использование полосы пропускания

Модуль регулировки скорости автоматически определяет скорость кодирования наиболее популярных типов видео. Можно контролировать объем данных, предварительно отправляемых клиенту, для устранения начальных задержек на буферизацию (быстрый запуск) и процент скорости кодирования для предоставления содержимого. Также можно настраивать множество других параметров, таких как максимальная полоса пропускания и одновременные подключения, и управлять модулем программно.

Кэширование выводимых данных

Вообще говоря, кэширование – это лучший способ увеличения производительности приложений, выполняющих повторяющиеся операции. В отличие от улучшений производительности отдельных приложений, для чего часто требуется множество усилий и работа с затратами на обработку приложения, кэширование устраняет загрузку повторяющихся запросов для одного содержимого.

До IIS 7.0, как IIS, так и ASP.NET предоставляли возможности кэширования в форме кэша ядра IIS и кэша вывода ASP.NET. Кэш ядра IIS обеспечивал максимальную производительность, но ограничивался преимущественно статическим содержимым. Кэш вывода ASP.NET был гораздо более полным решением для кэширования динамического содержимого, за исключением более низкой производительности и менее эффективного управления памятью. Новый кэш вывода в IIS 7.0 ликвидирует разрыв между кэшем ядра IIS и кэшем вывода ASP.NET.

Кэш вывода IIS 7.0 обеспечивает возможность кэширования динамического содержимого из любого приложения, включая ASP, ASP.NET, PHP и любых других платформ приложений, совместимых с IIS 7.0. Предоставляя базовую поддержку изменчивости и срока действия содержимого, эта новая функция позволяет реализовывать кэширование для содержимого, которое не может кэшироваться кэшем ядра IIS. Кэш ядра по-прежнему может использоваться для содержимого, не соответствующего ограничениям.

Кроме того, кэш ядра IIS 7.0 также предоставляет высокопроизводительную альтернативу кэшу вывода ASP.NET для содержимого ASP.NET, не требующего дополнительных функций кэширования (таких как зависимости кэша и недействительность данных в кэше), которые доступны только в кэше вывода ASP.NET.

Что касается кэширования выводимых данных, обычно проблемы связаны с определением верных политик срока действия содержимого, недействительности данных и изменчивости, обеспечивающих эффективное кэширование ответов и одновременное поддержание необходимой правильности и свежести кэша. В большинстве случаев это можно выполнить путем простой настройки верных правил кэширования, хотя иногда требуются более сложные политики, зависящие от информации времени выполнения. Для решения этой проблемы кэш вывода IIS 7.0 предоставляет программные API, которые могут использоваться для обеспечения необходимого поведения кэширования. Это разблокирует потенциал эффективности кэширования для содержимого, кэширование которого в противном случае было бы невыгодным. Кроме того, интегрированный конвейер ASP.NET позволяет использовать кэш вывода ASP.NET для содержимого, не относящегося к ASP.NET.

Развертывание кэширования вывода для динамического содержимого может быть сложным и может требовать многоуровневой стратегии для использования преимуществ эффективности и гибкости различных функций кэширования на платформе IIS 7.0. Развертывание часто включает описание множества параметров, влияющих на ответ, и определение стратегий срока действия и недействительности для поддержания свежести кэша, а также последующее определение кэша, поддерживающего необходимую семантику.

Но выполнение этой сложной работы почти всегда оправдано. Реализация кэша вывода IIS 7.0 позволяет в несколько раз улучшить общую пропускную способность приложения и соответственно уменьшить нагрузку на базу данных и компоненты уровня предприятия.

Преобразование кода ISAPI в модули IIS 7.0

В IIS 7.0 появился новый серверный интерфейс API, на котором основаны все модули IIS 7.0. Он заменяет устаревшие интерфейсы API ISAPI Filter и ISAPI Extension, использовавшиеся в предыдущих версиях IIS. Для новых модулей, которым не требуется поддержка предыдущих версий, новые API более просты в использовании, позволяют улучшить надежность серверного кода и гораздо более эффективны.

Однако IIS 7.0 предоставляет возможность поддержки существующих фильтров и расширений ISAPI путем использования слоя совместимости, реализуемого посредством дополнительных модулей IIS 7.0. Это позволяет существующим компонентам ISAPI работать в IIS 7.0 без необходимости переписывания.

Хотя использование существующих вложений в ISAPI снижает планку для перехода на IIS 7.0, следует серьезно рассмотреть перенос устаревшего кода ISAPI на новые API IIS 7.0. Это устраняет затраты на слой совместимости ISAPI и позволяет использовать преимущества производительности, недоступные для компонентов ISAPI. В зависимости от работы, выполняемой компонентом ISAPI, эти преимущества производительности могут быть довольно значительными. Например, API модуля IIS 7.0 предоставляет встроенную поддержку кэширования метаданных конфигурации и других произвольных данных, связанных с узлами, приложениями, URL-адресами, что можно значительно увеличить скорость выполнения внутренних операций компонента.

Помимо этого, API модуля IIS позволяет модулям асинхронно выполнять длительные операции, такие как получение данных объекта запроса и отправка ответа. Асинхронное выполнение этих задач позволяет серверу масштабироваться до большого количества одновременно клиентов (десятки тысяч) вместо прежнего максимального количества в несколько десятков или самое большое нескольких сотен одновременных клиентов из-за ограничений количества потоков запросов. Асинхронная обработка также может устранить эффект обработки на других запросах и действиях в приложении, снизить загрузку памяти и обеспечить гораздо лучшее использование ЦП.

Помимо определенных шаблонов, влияющих на производительность, собственный интерфейс API предоставляет разработчикам большую гибкость работы с задачами обработки запросов. Это позволит улучшить архитектуру серверного компонента и, в свою очередь, повысить эффективность. Например, определенные задачи фильтрации, для которых ранее требовались расширения ISAPI с подстановочными символами и выполнение дочернего запроса, теперь могут быть выполнены в модуле во время исходного запроса, а также могут разрешить кэширование ядра IIS для ответа.

Для этого могут быть необходимы определенные эксперименты и прототипы для определения оптимальной архитектуры, наилучшим образом использующую улучшения перехода. Из-за фундаментальных архитектурных различий ISAPI и API модуля IIS 7.0 прямой маршрут переноса не всегда является верным. Хорошая новость заключается в том, что API модуля IIS 7.0 также более прост в использовании, чем ISAPI, что упрощает переход.

Расширяемость сервера


IIS 7.0 предоставляет сквозную расширяемость. Для этого требуются значительные заблаговременные знания работы сервера, но это также позволяет добиться значительного повышения производительности отдельных приложений. Понимание архитектуры сервера и обработки запроса позволяет использовать преимущества этой расширяемости для создания специальных эффективных решений, отвечающих вашим требованиям к приложениям, рабочей нагрузке и оборудованию.

Это может быть выполнено путем замены каких-либо встроенных функций IIS 7.0 пользовательскими реализациями. Хотя IIS 7.0 претерпели значительную оптимизацию и тестирование производительности, они, конечно же, не оптимизированы для всех возможных применений. Поэтому можно повысить производительность определенных модулей путем создания оптимизаций для конкретной рабочей нагрузки. Например, можно решить повторно реализовать модуль вывода каталогов для кэширования списков содержимого каталогов в памяти вместо использования интерфейсов API операционной системы для перечисления файлов.

Также расширяемость может использоваться для создания новых функций повышения производительности. Встроенные примеры таких функций включают кэш вывода, модули сжатия и несколько других внутренних кэшей.

Для того, чтобы определить, что пользовательская функция повышения производительности действительно необходима, нужно понимать характеристики производительности приложения и его рабочей нагрузки, а также знать ограничение, которое требуется устранить. IIS 7.0 предоставляет достаточную диагностическую поддержку для выполнения анализа, который помогает сделать требования и возможную архитектуру необходимых функций более ясными.

Заключение

Хотя выпуск IIS 7.0 в основном является функциональным, он предлагает заслуживающие внимания улучшения производительности, обусловленные его модульной архитектурой, настраиваемостью и новыми функциями производительности. Эти улучшения могут помочь добиться значительных экономических выгод через консолидацию серверов и уменьшения используемой полосы пропускания, а также повысить удобство работы пользователей.

Perpetuum informatio

Решение проблем с производительностью IIS

Иногда бывает, что на сервере IIS начинают происходить странные дела. Так например у меня возникла ситуация, в которой один из процессов w3wp.exe время от времени начинал занимать под свои вычисления весь ресурс одного из ядер (был бы одноядерный процессор было бы использование процессора на 99% или 100%). Для тех, кто не знает процесс w3wp.exe кроме всего прочего отвечает за исполнение серверного кода ASP, ASP.NET скриптов. Ясно было что, какой-то скрипт производит излишнюю нагрузку. Такое поведение для меня было неприемлимым и я постарался решить эту задачу.

Первым делом я захотел выяснить какое из используемых нами приложений производит эту дополнительную нагрузку. Для этого я попробовал вынести все приложения в отдельные виртуальные каталоги, задав для каждого отдельный пул приложений, они же Application pool (для каждого пула приложений используется отдельный процесс w3wp.exe), попутно определяя какой из процессов к какому пулу относится. Сделать это можно довольно просто при помощи утилиты Sysinternals Process explorer. Для этого достаточно зайти в свойства процесса (при этом подсказкой может служить то, что приложения написанные при помощи ASP.NET будут подсвечены жёлтой строкой), и на вкладке Image посмотреть строку Command line, из которой видно, что название пула приложений передаётся процессу w3wp.exe через параметр «ap». Так например команда запуска для пула приложений с именем «dotnet4» будет выглядеть так:

c:\windows\system32\inetsrv\w3wp.exe -a \\.\pipe\iisipmceXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -t 20 -ap «dotnet4»

Впоследствие эти действия оказались по большему счёту бесполезными, но умение определять нужный процесс w3wp оказалось впоследствии полезным и мне и нашим разработчикам выполняющим удалённую отладку в Visual Studio.

Ограничиваем пропускную способность IIS на сервере SCCM с ролью SUP (WSUS).

В процессе централизованной раздачи клиентам System Center 2012 R2 Configuration Manager (SCCM) очередной порции обновлений с сервера с ролью Software Update Point (SUP)столкнулись с ситуацией пиковой загрузки на канале передачи данных — участка с низкой пропускной способностью на канале между структурными подразделениями и площадкой, на которой был расположен сервер SCCM. По графику отдачи трафика на сервере SCCM было хорошо видно, что исходящий трафик “упёрся” в границу того самого “узкого места на канале. Разумеется таких ситуаций чаще всего можно избежать заранее настраивая приоритизацию трафика на разных уровнях, начиная с сетевого оборудования. Но что делать, если по какой-то причине проблема возникла прямо здесь и прямо сейчас, а доступа к сетевому оборудованию нет. То есть фактически нужно как-то оперативно “задушить” трафик отдачи обновлений Windows Update на определённый момент времени средствами Windows. Простое и эффективное решение подсказал автор заметки Ограничиваем аппетиты WSUS-а .

В качестве решения предлагается ограничение общей пропускной способности (в байтах) веб-сервера IIS. За это отвечает параметр maxGlobalBandwidth в разделе конфигурации IIS — system.applicationHost/webLimits .

Чтобы запросить текущие значения параметров в указанном разделе конфигурации IIS с помощью утилиты командной строки appcmd.exe выполним:

В полученном ответе мы увидим, что значение по умолчанию для интересующего нас параметра параметра – 4294967295:

Предположим, нам нужно уменьшить полосу пропускания трафика IIS до 20 Mbit/s. Рассчитаем необходимое значение параметра в байтах: (20 * 1024 * 1024)/8 = 2 621 440 байт.

Выполним команду установки рассчитанного значения:

В ответ получим сообщение об успешном применении параметра конфигурации:

Туже самую настройку можно выполнить и через консоль IIS Manager, перейдя на уровне веб-сервера в раздел Management > Configuration Editor

В поле Section из выпадающего дерева элементов конфигурации выберем system.applicationHost/webLimits , зададим значение интересующего нас параметра maxGlobalBandwidth и нажмём в правом меню действий Apply, чтобы изменения вступили в силу.

Результат сможем наблюдать сразу же. В нашем случае с настройками IIS по умолчанию отдача трафика клиентам была на пределе возможностей “узкого места” в сети, что вызывало ряд вытекающих проблем для пользователей находящихся в “задушенном” сегменте сети.

Илон Маск рекомендует:  Захват видео с камеры с помощью JavaScript и HTML5

Сразу после применения рассчитанного нами параметра ситуация изменилась на глазах…

Таким образом критическая ситуация загрузки канала была ликвидирована.

У такого подхода к ограничению трафика в отличии от классического использования QoS есть преимущество в том, что в случае необходимости изменения пропускной способности по какому-то заданному расписанию, можно прибегнуть к помощи планировщика заданий Windows, запуская из него в нужное время вышеприведённую команду настройки IIS.

Оптимизация IIS для Файловых баз 1С

Дано:
4 Бухгалтера
1 сервер IIS 7, Windows 7 максимальная.
24Гб оперативы
i5 4660
Гигабитная сеть
Работают локально
Файловые базы, опубликованные на IIS: 4 БП 3.0, 2 ЗУП 3.1.
1С 8.3.11.2924 х86
Каждый бухгалтер одновременно открывает все 6 баз.


Проводил нагрузочное тестирование: IIS падает после того, как открыто одновременно 4 базы БП и одна База ЗУП. В этот момент процесс w3wp.exe(IISа) занимает 3.8Гб оперативной памяти, после чего аварийно завершает процесс и все вылетают.

Вопрос: подскажите, в чем может быть дело: нехватка адресной памяти на процесс, ограничения IIS или как это ещё можно объяснить. Может кто сталкивался? что можете посоветовать?
Я думаю установить 1С х64 и попробовать ещё раз, так как в х86 ограничение в 4гб на один процесс, а в х64 2ТБ или же придется выделять ещё одну машину под другой веб сервер.

Подскажите, чтобы вы сделали?

(1) а приложение 1С х86 дак не влияет, да?

Ставь 64-битную 1Ску

Нагрузочное тестирование на файловых ИБ под ИИС — это пять!

А почему тогда не апач? И почему не терминальный сервер — память позволяет

Настройка IIS на 500 пользователей

Сервер имеет следующую конфигурацию:

  • Процессор: 2 процессора Intel L5520, 2.27 GHz, Cores: 4, Threads: 8
  • RAM: 24 GB
  • OS: Windows 8.1 (к сожалению клиентская ОС)
  • IIS: 8.0

Приложение построено на ASP.NET MVC, создано 500 учетных записей.

День 1

В 8:00 всем 500 пользователям необходимо было авторизоваться и скачать файл

В этот момент сайт начал замедляться и в конце концов полностью «сел».

Предложений в сети было много и все они в основном касались оптимизации и настройки сервера IIS .

У меня нет опыта администрирование веб-серверов, всегда делал акцент на кодинг — думал настройка серверов, это вторичная обязанность программиста-разработчика. И поэтому попытался решить проблему использованием асинхронных контроллеров (хотя в приложении всего то 2 контроллера). И это результатов не дало.

Одно из первых настроек IIS , которых я сделал и что дало эффект было увеличение максимального количества одновременных запросов в приложении ( appConcurrentRequestLimit ):

appcmd.exe set config /section:system.webserver/serverRuntime/appConcurrentRequestLimit:20000

Сайт сразу вздохнул и вроде пользователи смогли скачать данный файл. Перестало все замедляться. И как мне показалось проблема была решена.

День 2

Сегодня снова в 8:00 все пользователи хлынули скачивать другой файл и та же самая ситуацию.

Я увеличил appConcurrentRequestLimit до 90000 — безрезультатно.

Сейчас, хоть и нет времени на это сижу и изучаю архитектуру IIS. Все так запутанно. Как мне лучше поступить? Пока мало, что понимаю из прочитанного.

1 ответ 1

Для начала, увеличивать appConcurrentRequestLimit бесполезно. Если у вас 500 пользователей — то достаточно значения в 500 чтобы они все могли одновременно скачивать файл. Ну, лучше 1000, чтобы было 2 запроса на пользователя. 90000 — это очень много для ваших задач.

В конфигурации по умолчанию, IIS должен быть способен справиться с такой, в общем-то, незначительной нагрузкой. Поэтому надо искать что с сервером не так.


Прежде всего, надо смотреть, конечно же, пропускную способность канала. Если у вас исходящий канал всего 5 мегабит — то при размере файла 500 килобайт он минут 8-10 будет забит полностью, пока все файлы не скачаются. Открыть главную страницу в это время может быть и правда затруднительно — ведь соединению придется конкурировать за ресурсы с 500 другими.

Для того, чтобы главная страница сайта продолжала открываться пока скачиваются файлы — надо как-то ограничить скорость скачивания, чтобы весь канал не забивался. Можно попробовать сделать контроллер для медленной отдачи файла.

Но у IIS есть встроенная функциональность. К сожалению, ее можно включить только для сайта целиком, поэтому вам надо будет перенести файлы на отдельный сайт. Дальше в настройках IIS включаете ограничение по пропускной способности в 4 мегабита — и 1 мегабит для вашего основного сайта остается свободным.

Но можно сделать еще проще. Просто выложите ваши файлы в любое файловое облако — яндекс.диск, гугл-диск, дропбокс и т.п. В них во всех можно настраивать доступ к файлам.

Если же вы сторонник нестандартных решений — можно воспользоваться торрентами. Создаете торрент, прописываете в качестве трекеров открытые трекеры, и выкладываете торрент на сайт. Также надо будет запустить на сервере торрент-клиент, чтобы раздавал файлы.

Iis расчет быстродействия для подключения

Планируется в версии 8.3.9.

В версии 8.3.9 мы выполнили значительное количество задач по оптимизации разных механизмов платформы. Здесь хочется рассказать об одной из них. Это повышение производительности веб-сервисов.

Переиспользование сеансов

Недостаточная производительность веб-сервисов объяснялась тем, что каждый вызов веб-сервиса имел значительные накладные расходы на создание и завершение сеанса. Причём при создании каждый раз выполнялся обработчик УстановкаПараметровСеанса(), который в типовой конфигурации может быть довольно «тяжёлым».

Кроме этого существовал и функциональный недостаток. Веб-сервисы не обладали состоянием. Это не позволяло реализовывать логику, использующую сохранение состояния между вызовами веб-сервиса.

В версии 8.3.9 мы доработали механизм веб-сервисов (SOAP-сервисы, HTTP-сервисы, сервисы OData). В результате их производительность увеличилась примерно в 10 раз.

Мы проводили тесты на типовой конфигурации Бухгалтерия предприятия. В неё мы добавили HTTP-сервисы, выполняющие выборку из справочника Контрагенты. Тест заключался в том, что клиент выполнял последовательно 100 обращений к сервису. В старом режиме работы для этого потребовалось 29,9 с. В новых режимах работы в среднем 3 с.

Этих результатов удалось достичь за счёт того, что мы реализовали две различные стратегии, обеспечивающие переиспользование сеансов:

  • Автоматическое переиспользование сеансов из пула;
  • Управление сеансами с помощью HTTP-заголовков.

При автоматическом переиспользовании сеансов клиент не имеет возможности влиять на количество сеансов и время их жизни. Ему просто автоматически выделяется сеанс из существующего пула сеансов. Такая стратегия подходит для высоконагруженных публичных сервисов, к которым обращаются клиенты, выполняющие шаблонные операции, и обладающие унифицированными привилегиями.

Например, это может быть автоматизация торговой деятельности удаленных торговых точек, предусматривающая периоды пиковой нагрузки на сервер. Для обработки будет выделено нужное количество сеансов. Они будут завершены по мере падения нагрузки.

Другой пример это получение/помещение файлов в конфигурации Документооборот посредством http-сервисов. Для таких операций можно использовать одного и того же специального пользователя.

Стратегия ручного управления сеансами подразумевает, что клиент самостоятельно управляет количеством сеансов и временем их жизни. Эта стратегия лучше подходит для высокоинтегрированных систем в рамках одной организации. Вы можете реализовать собственный алгоритм, который будет управлять временем жизни сеансов и их количеством.

Средства управления

Необходимость использования одной или другой стратегии вы можете определить в дереве объектов конфигурации, и, при необходимости, переопределить в файле публикации default.vrd. В дереве объектов конфигурации мы добавили два новых свойства объектам Web-сервис и HTTP-сервис:

  • ПовторноеИспользованиеСеансов может принимать значения ИспользоватьАвтоматически, Использовать, НеИспользовать. Значение ИспользоватьАвтоматически включает автоматическое переиспользование сеансов из пула, а значение Использовать включает управление сеансами с помощью HTTP-заголовков.
  • В свойстве ВремяЖизниСеанса вы можете указать, сколько секунд будет бездействовать сеанс до того, как платформа завершит его автоматически.

В файле default.vrd для элементов, описывающих SOAP-сервисы, HTTP-сервисы и сервисы OData, мы ввели несколько новых атрибутов:

  • reuseSessions – аналог свойства ПовторноеИспользованиеСеансов, может принимать значения autouse, use и dontuse;
  • sessionMaxAge — аналог свойства ВремяЖизниСеанса;
  • poolTimeout — используется при автоматическом управлении сеансами, содержит время ожидания доступности сеанса;
  • poolSize — используется при автоматическом управлении сеансами, содержит максимальное количество сеансов, которое может быть создано в пуле.

Например, файл default.vrd может выглядеть так:


Файл default.vrd имеет больший приоритет, чем конфигурация. При публикации конфигурации атрибуты reuseSessions и sessionMaxAge заполняются из соответствующих свойств объектов конфигурации Web-сервис и HTTP-сервис. Но при необходимости вы можете изменить эти значения прямо в файле, и тогда платформа будет использовать их, а не значения из конфигурации.

Автоматическое переиспользование сеансов

Сеансы в пуле хранятся в разрезе типа сервиса, наименования сервиса, пользователя/пароля, значений разделителей и безопасного режима. Причём в пуле может быть несколько сеансов с одинаковыми значениями перечисленных реквизитов.

При вызове платформа проверяет, есть ли простаивающий сеанс с подходящим сочетанием этих реквизитов. Если такой сеанс есть, то он выделяется для обработки вызова. Если такого сеанса нет, то создается новый сеанс и выделяется для обработки.

Сеанс автоматически завершается по истечении периода бездействия (ВремяЖизниСеанса).

Если достигнуто максимальное количество сеансов (poolSize), то вызов ждет указное время (poolTimeout). Если за это время подходящий сеанс не освободился, то возвращается ошибка со статусом 406 Not Acceptable.

Настройки автоматического пула сеансов действуют в рамках публикации. Это значит, что если у вас есть несколько публикаций для одной и той же информационной базы, то при вызове действуют те параметры, которые указаны в публикации, к которой обращается текущий вызов. Таким образом, если в одной публикации для сервиса указан лимит в 3 сеанса, а в другой публикации 5, то общее количество сеансов, которое может быть создано для вашей информационной базы равняется сумме этих значений 8.

При выборе размера пула следует учитывать все разрезы, в которых хранятся сеансы в пуле. Мы рекомендуем устанавливать размер пула немного больше, чем количество возможных вариантов. Это позволит вам избежать ситуации, когда пул заполнен сеансами, и вызов с новой комбинацией разделителей/пользователей обработан быть не может.

Эта стратегия не подходит для сценариев, в которых нужно использовать сохранённое состояние сеанса на сервере. Потому что нет никакой гарантии, что при следующем вызове клиент будет подключен к тому же самому сеансу. Как мы говорили в начале, в пуле может быть несколько сеансов с одинаковыми значениями ключевых реквизитов.

Управление сеансами

Инициатором создания и завершение сеанса является клиент сервиса. Чтобы создать постоянный сеанс клиент должен передать заголовок IBSession в http – запросе. Этот заголовок вы устанавливаете вручную. Значением этого заголовка должна быть директива start.

После получения такого заголовка на сервере стартует сеанс информационной базы, происходит аутентификация, установка разделителей и вызывается обработчик УстановкаПараметровСеанса().

Если клиент затребовал создание сеанса, а сервер не может это сделать, генерируется сообщение об ошибке 406 Not Acceptable.

Если всё хорошо и сеанс создан, платформа помещает в http-ответ директиву установки куки IBSession с идентификатором созданного сеанса.

Для подключения ранее созданного сеанса, вам необходимо указать куки IBSession с идентификатором сеанса.

Для завершения сеанса вам нужно использовать заголовок IBSession http-запроса. Его нужно установить в директиву finish.

Получив сообщение с таким заголовком, сервер отрабатывает вызов, и закрывает сеанс.

Эта стратегия позволяет вам реализовать сценарии, в которых используется состояние сеанса, сохранённое на сервере. Потому что вы имеете уникальный идентификатор сеанса. Единственное, о чём нужно помнить, что завершение сеанса может происходить не только по вашей «команде», но и автоматически. В том случае, когда превышен период бездействия сеанса (ВремяЖизниСеанса). Поэтому вы, как клиент сервиса, должны быть готовы к тому, что сеансовые данные могут быть сброшены, если сеанс завершен.

Веб-сервисы в расширениях

Если объекты конфигурации Web-сервис или HTTP-сервис располагается в расширении конфигурации, то возможность редактировать свойства ПовторноеИспользованиеСеансов и ВремяЖизниСеанса у вас отсутствует. Поэтому, если вы хотите включить автоматическое или ручное переиспользование сеансов, вам нужно использовать для этого файл default.vrd.

В дальнейшем мы будем рассматривать возможность поддержки этих свойств в расширениях.

Что вы можете сделать для ускорения работы веб-сайтов IIS 7?

Включите сжатие, и вы увидите немедленное улучшение производительности, аналогично, если вы включите кеширование для сложных веб-приложений.

Какие еще параметры конфигурации вы можете изменить для повышения производительности? есть ли у вас «контрольный список производительности» вещей, которые нужно установить, когда вы получаете новый сервер?

Я спрашиваю об IIS 7 или более поздней версии (потому что все мои текущие серверы IIS7)

4 ответа

IIS7 + на самом деле довольно чертовски быстро. Существует не так много возможностей для ускорения IIS; в целом вы оптимизируете HTML


Советы Jesper выше — отличные рекомендации для ускорения статических веб-страниц.

Если вы используете приложение ASP.NET, вы также можете сделать это, если на вашем веб-сайте возникают проблемы с производительностью из-за загрузки:

  • Следите за своим сервером. ASP.NET публикует множество счетчиков, которые можно отслеживать в PerfMon.exe. Счетчик очереди глобального запроса покажет вам, будут ли поставлены какие-либо запросы. Это число всегда должно быть 0.
  • Оптимизировать любые вызовы внешним ресурсам, таким как базы данных и файловые системы. Длительные запросы связывают потоки и предотвращают доставку входящих запросов.
  • Если вы давно используете вызовы внешних ресурсов, подумайте о том, чтобы сделать их асинхронными. Это передает запрос в отдельный пул потоков и возвращает исходный поток в пул для обслуживания новых запросов.
  • Увеличьте размер пула потоков для более старых версий .NET. Этот параметр можно найти в файле machine.config
  • Настройте параметр веб-сада в пуле приложений IIS для использования нескольких рабочих процессов (параметр «Максимальные рабочие процессы» в расширенных настройках IIS7). Играйте с различными настройками, чтобы увидеть, что лучше всего подходит для вашей среды. Многоядерные машины смогут обрабатывать несколько рабочих процессов лучше.
  • На виртуальной машине не назначайте слишком много ядер на сервер, так как это может вызвать проблемы с размещением на вашем хосте.
  • Если вы все это пробовали и по-прежнему видите проблемы из-за нагрузки, подумайте о кластеризации вашего сервера. В Windows Server встроена балансировка сетевой нагрузки, которая позволяет настраивать небольшую веб-ферму без необходимости использования дорогостоящего балансировщика нагрузки. IIS7 также включает в себя структуру веб-фермы, которая обеспечивает то же самое, используя маршрутизацию запросов приложений (ARR). Он также обрабатывает подготовку сервера.

Быстрый веб-поиск по любому из этих вопросов вернет много хорошей информации.

Магические настройки обычно зависят от сайта. Вам нужно будет следить за тем, что происходит, чтобы найти правильные вопросы о том, что нужно изменить в IIS7.

Какая часть цепочки производительности самая слабая?

Что вы можете сделать, чтобы получить гранулированную видимость доступным способом?

Джеспер Мортенсен абсолютно прав Две книги Стива являются превосходным чтением и учитывают недавнее ускорение скорости от 5,5 до 1,8 секунд ( webpagetest ) на сайте, который мы поддерживаем. Стабилизация всей системы, основанная на журналах, помогла нам обеспечить стабильную доставку по трассам и увеличить ее на пике (более 50% этого было на уровне ОС). Ничто из этого не могло быть сделано в течение 2-х дневных временных рамок без мониторинга на каждом уровне.

Часто не существует контрольного списка для каждого сайта за пределами работы Стива Саундера, вам нужно знать проблему, прежде чем искать решение.

Мы внедряем модуль ARR в IIS7, поэтому мы создаем webFarm, ARR может кэшировать ваш запрос на диске и увеличивать производительность для нас, что имеет большое значение.

На странице html вы также можете использовать несколько поддоменов для своего носителя, например:

js.yourdomain.com img.yourdomain.com css.yourdomain.com

и т. д. Browser le ie, и я думаю, что другие загружают синхронные 3 соединения поддоменом.

Ускорьте свой IIS

Есть ли способ повысить производительность вашего IIS, изменив некоторые параметры конфигурации?

Или у вас есть какие-либо советы в целом о том, как повысить производительность приложения ASP.NET?

  • Не забудьте отключить ‘debug’ в web.config
  • не использовать сопоставление файлов подстановок.
  • Используйте httpCompression для улучшения воспринимаемой производительности.
  • Полоса пропускания дроссельной заслонки для улучшения общей воспринимаемой производительности.
  • Попробуйте использовать IIS7 для приложений .net

Ваш первый порт вызова должен быть здесь: —

Вы заглянули в Кэширование? или микро-кэширование Посмотрите http://www.dnrtv.com/default.aspx?showNum=85.

С другой стороны, вы можете попробовать IIS Tuner инструмент с открытым исходным кодом для оптимизации

Если у вас есть доступ к серверу IIS, вы можете изменить его, включая:

Сжатие HTTP — отлично подходит для статического контента, такого как файлы JS и CSS.

Предварительная компиляция приложения ASP.NET делает его быстрее. Сборка релиза — плюс.

Короче говоря, есть много способов повысить производительность вашего приложения с помощью настроек iis. Однако ваше конкретное приложение нуждается в собственной настройке.

Общие подсказки находятся в других сообщениях. Однако также будут некоторые особенности вашего приложения, которые могут быть настроены. Например, если у вас есть один или два каталога, которые имеют большую активность по сравнению с остальной частью сайта, вы можете поместить их в отдельные пулы приложений.

Это довольно художественная форма, и если после того, как вы последовали общим советам здесь, у вас все еще есть проблемы с производительностью, я бы рекомендовал пригласить консультанта на неделю для настройки вещей для вас. Предпочтительно тот, который может смотреть на ваш ASP тоже.

Другая вещь, которую вы могли бы сделать, если у вас есть конкретные точки затвора, — это отправлять запросы на SO. До сих пор вы можете пойти с общим советом.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL