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


Содержание

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.

Защитные функции вступают в компромисс с производительностью 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 показывает, что использование настроек по умолчанию и внесение выборочных изменений только в определенные параметры будет способствовать повышению производительности. Не изменяйте настройки по умолчанию для сетевого интерфейса системы до тех пор, пока не протестируете производительность системы и не сможете точно оценить, как отразится на ней каждое изменение.

HOWTO по оптимизации PHP

PHP очень быстрый язык программирования, но есть еще множество способов оптимизации, помимо оптимизации кода.

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

Достижение высокой производительности

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

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

Давайте возьмем более реалистичный пример для дальнейших рассуждений. Предположим, нам необходимо написать скрипт, который должен прочитать файл размером 250 кб и сгенерировать HTML, резюмирующий информацию из файла. Мы пишем два сценария, которые делают одно и тоже: hare.php, который читает файл в память целиком и обрабатывает его за один проход, и tortoise.php, который читает файл построчно не сохраняя в памяти информации, больше чем одна строка. Tortoise.php будет медленнее, потомучто использует многократное чтение, требует большего количества системных вызовов.

Hare.php требует 0.04 секунды центрального процессора, а также 10 мб памяти. Tortoise.php требует 0.06 секунд процессорного времени и 5 мб памяти. Сервер располагает 100 мб свободной памяти и процессор на 99% свободен. Предположим, что никакой фрагментации памяти не происходит (для упрощения).

При 10 одновременных запусках скрипта, hare.php исчерпает память (10 х от 10 до 100). В этой точке, tortoise.php все еще будет иметь в своем распоряжении 50 мб свободной памяти. 11 запуск hare.php приведет к уменьшению производительности, поскольку система начнет использовать виртуальную память. При этом, его первоначальная скорость может упасть более чем в половину. Каждый запуск hare.php на данный момент занимает 0.08 секунд процессорного времени. Тем временем tortoise.php все также будет занимать свое процессорное время 0.06 секунд.

В таблице ниже, самый быстрый сценарий выделен полужирным:

Соединения CPU секунды при запуске 1 скрипта CPU секунды при запуске 10 скриптов CPU секунды при запуске 11 скриптов
Hare.php 0.04 0.40 0.88 (свободная память закончилась)
Tortoise.php 0.06 0.60 0.66

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

Узкие места

Пример hare и tortoise (зайца и черепахи) показал нам причины узких мест. С бесконечной оперативной памятью hare будет быстрее всегда, чем tortoise. К сожалению, вышеупомянутая модель слишком упрощена, и есть еще много других узких мест, препятствующих работе, помимо оперативной памяти:

Ваша сеть, вероятно, самое узкое место. Например, вы говорите, что у вас 10 Мбит связь с интернетом, по которой вы можете скачать 1 мб данных в секунду. Если каждая страница у вас занимает 33 кб, то обычные 33 страницы в секунду будут занимать весь ваш канал.

Более тонкие узкие места в сети это скорость отклика, например, сервера имен (DNS), или адресация нужного количества памяти для программного обеспечения сети.

Центральный процессор

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

Shared Memory (общедоступная память)

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

Файловая система

Доступ к жесткому диску может быть в 50-100 раз медленнее, чем доступ к данным в оперативной памяти. Кэширование файлов с использованием оперативной памяти могут снизить данное ограничение. Однако, в условиях небольшого количества памяти для системного кэша, работа будет замедляться. Системные файлы так же могут быть сильно фрагментированными, замедляя дисковый доступ. Частое использование симлинков на UNIX системах также приводят к замедлению.

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

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

В некоторых операционных системах, например, в Windows, создание нового процесса это медленная операция. Это означает, что CGI процесс, вызываемый для каждой операции, будет работать значительно медленнее. Запуск PHP в multi-threaded (в виде модуля) режиме должно увеличить скорость ответа (примечание: старые версии PHP неустойчивы в данном режиме).

Избегайте переполнения вашего сервера множеством ненужных процессов. Например, если ваш сервер предназначен только для обслуживания сети, избегайте запуска (или даже вообще установки) X-Windows. На Windows-системах избегайте запуска Microsoft Find Fast (компонент офиса), а также всякого рода screensaver’ов. Потомучто все это заканчивается 100% использованием процессора.

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

  1. демоны, например, telnetd, inetd, atd, ftpd, lpd, sambad
  2. sendmail для поступающей почты
  3. portmap для NFS
  4. xfs, fvwm, xinit, X

Также вы можете отключить запуск некоторых программ при загрузке, изменяя файлы запуска, которые обычно хранятся в /etc/init* или /etc/rc*/init* директории.

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

Соединение с другими серверами

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

Когда начинать оптимизацию?

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

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

Также выберите хорошие испытательные данные. Если ваша база данных, как ожидается, будет хранить только 100 000 записей, избегайте тестирования ее только со 100 записями, вы будете потом об этом сожалеть. Это когда-то случилось с одним из программистов в моей компании: мы обнаружили медленный код значительно позже, потратив много времени впустую, поскольку пришлось переписать большую часть кода, который работал, но не масштабировался.

Настройка вашего сервера для PHP

Далее, мы рассмотрим с вами, как оптимизировать работу с PHP двух самых распространенных web-серверов, Apache 1.3 и IIS.

Разработчики PHP заявляют, что нет никакой разницы в скорости и преимуществах масштабирования при использовании Apache 2.0 над Apache 1.3, особенно, если PHP установлен в виде модуля.

Apache 1.3/2.0

Этот сервер доступен на Unix и Windows платформах, это самый популярный сервер в мире. Apache 1.3 использует pre-forking (предразветвления) модель для обслуживания сети. После старта, сервер создает дочерние процессы для обслуживания каждого HTTP запроса. Родительский процесс действует как ангел-хранитель, проверяя, что все дочерние процессы работают правильно и координирует их действия. Чем больше HTTP запросов, тем больше дочерних процессов будет порождено, чтобы их обработать. Поскольку HTTP запросы начнут замедляться, родительский процесс уничтожает неактивные дочерние процессы, освобождая ресурсы для новых процессов. Красота данного подхода в том, что это делает Apache чрезвычайно устойчивым. Даже если дочерний процесс рушится, родительский и другие дочерние процессы будут изолированы от сбойного дочернего процесса.

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

Apache 2.0 может работать в модульном режиме (multi-threaded). Мои эталонные тесты показали, что преимуществ этого режима не так уж много. Также будте готовы к тому, PHP расширения несовместимы, например GD и IMAP. Проверено на Apache 2.0.47 (23 октября 2003).

Apcahe сконфигурирован при помощи файла httpd.conf. Следующие параметры особенно важны при настройке дочерних процессов:

Максимальное число дочерних процессов, которые может создать сервер. Значение поумолчанию 256 означает, что одновременно может быть обработано 256 HTTP запросов. Любые дальнейшие запросы будут поставлены в очередь.

Количество дочерних процессов, которые будут созданы сразу после старта сервера.

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

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

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

Для больших сайтов наилучшими значениями будут близкие к этим:

  1. MinSpareServers 32
  2. MaxSpareServers 64

Apache под Windows ведет себя иначе. Вместо того, чтобы использовать дочерние процессы, Apache использует треды. Вышеупомянутые параметры не используются. Вместо этого мы имеем один параметр: ThreadsPerChild который имеет значение поумолчанию 50. эта переменная указывает число тредов, которые могут быть порождены Apache. Поскольку в Winodws есть только один дочерний процесс, то количество HTTP запросов, которые он может обработать, равняется 50. Для серверов сети, которые испытывают более серьезные нагрузки, увеличьте этот параметр от 256 до 1024.

Другие полезные параметры, которые вы можете изменить приведены ниже:

Параметр Поумолчанию Описание
MaxClients 256
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxRequestsPerChild

Определяет объем буфера вывода (в байтах), используемого в TCP/IP соединениях. Этот параметр прежде всего полезен для переполненных или медленных сетей, когда пакеты необходимо буферизировать. В этом случае, установите этот параметр близким к размеру самого большого пересылаемого файла. Один TCP/IP буфер будет создан при соединении.

В оригинале HTTP спецификации, каждый HTTP запрос должен создавать новое соединение с сервером. Keep-alive заголовок был создан, чтобы уменьшить нагрузку на сервер. Параметр keep-alive говорит серверу, чтобы он использовал тоже самое соединение через socket (сокет) для нескольких HTTP запросов.

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

Количество секунд для удержания сокет-соединения. Это время включает в себя генерацию контента и ответ клиента. Если клиент не реагирует в течение этого времени будет создано новое соединение.

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

Сокет-соединения будут закончены, как только их количество достигнет этой цифры. Установите большое значение, но меньше MaxClients или ThreadsPerChild.

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

Максимальный размер PUT или POST. нет лимита.

Если вы не требуете DNS поиска и не используете htaccess для настройки отдельных директорий в Apache, вы можете задать:


Если вас не волнует безопасность папок при вызове симлинков, включите FollowSymLinks и выключите SymLinksIfOwnerMatch, чтобы предотвратить дополнительный системный вызов lstat():

Настройка IIS

Параметр Поумолчанию Описание
SendBufferSize Определяется операционной системой.
KeepAlive [on|off] On
KeepAliveTimeout 15
MaxKeepAliveRequests 100
TimeOut 300
LimitRequestBody

Определяет, какое количество памяти отвести для IIS. (Performance Tab).

Управляет полосой пропускав секунду, разделенную по серверам. (Performance Tab).

Управляет процентом процессорного времени, доступного для процесса по серверам. (Performance Tab).

По умолчанию 900 секунд. Установите более низкое значение, если у вас локальная сеть. (Web Site Tab)

В IIS 5 вы можете сжимать динамические страницы, HTML и картинки. Вы можете настроить эти параметры. Значение по умолчанию выключено.

HTTP сжатие нужно включать для всего сервера. Чтобы включить этот параметр нажмите правую кнопку мыши на консоли сервера (не на одном из подсайтов), выберите Свойства (Properties). Нажмите на Вкладке Service, затем выберите Compress application files для компрессии динамических данных, и Compress static files для компрессии статического контента.

Также вы можете изменить, настроенный поумолчанию, уровень изоляции web-сервера. Во вкладке Home Directory в Application Protection вы можете определить уровень изоляции. На высшем уровне изоляции ваш сайт будет работать медленнее, потомучто это будет отдельный процесс от IIS, вто время как запуск сайта в IIS процессе самая высока скорость, но сервер может лечь, если в вашем скрипте есть серьезные ошибки. На данный момент я рекомендую запускать PHP сайты как CGI или с использованием ISAPI совместно с Application Protection установленной в hight (высокая).

Вы также можете использовать regedit.exe для изменения параметров IIS 5, сохраненных в ветке HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesInetinfoParameters.

Настройка производительности исходя из обращений к серверу в день.
Управление полосой пропуска
Управление процессом
HTTP компрессия

Устанавливает количество памяти, которую IIS будет использовать для кэширования своих файлов. Поумолчанию, ISS может использовать 50% установленной в компьютере памяти. Вы можете увеличить этот параметр, если на машине работает только IIS. Значение задается в мегабайтах.

Определяет максимальный размер файла, который может быть кэширован. Размер указывается в байтах. Значение поумолчанию 262,144 (256 кб).

Устанавливает время (в миллисекундах), в течение которого кэшированный объект сохраняется в памяти. Значение поумолчанию 30,000 миллисекунд (30 секунд).

Устанавливает число нитей на процессор. Определяет, сколько CGI приложений может быть запущено одновременно. Значение поумолчанию 4. увеличьте это значение, если вы используете PHP как CGI.

Максимальное количество активных живых соединений (Keep alive), которые ISS поддерживает в очереди соединений. Значение поумолчанию 15, должно быть увеличено к числу одновременных соединений, поддерживаемых вашим сервером. Максимально 255.

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

Высока производительность в Windows: IIS и FastCGI

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

Поскольку установка FastCGI на IIS достаточно сложна, вы должны использовать EasyWindows PHP Installer (http://phplens.com/phpeverywhere/easywindows). Он установит PHP, FastCGI и Turck MMCache для достижения лучшей производительности. Этот инсталлер также может установить PHP для Apache 1.3/2.0.

PHP 4 и Zend Engine

Zend Engine это внутренний компилятор и движек, использованный для создания PHP 4. Созданный Zeev Suranski и Andi Gutmn, Zend Engine это сокращение от их имен. На начальном этапе PHP работал следующим образом:

PHP скрипт загружается в Zend Engine и компилируется в opcode. Opcode это набор низкоуровневых бинарных инструкций. После запуска opcode происходит генерация HTML и передача его клиенту. Opcode удаляется из памяти после выполнения.

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

PHP скрипт загружается в Zend Engine и компилируется в opcode. Opcode может быть оптимизирован с использованием необязательного оптимизатора, названного Zend Optimizer. В зависимости от скрипта, он может увеличить скорость выполнения PHP скрипта до 50%.

Раньше, после выполнения, opcode уничтожался. Теперь вы можете организовать его кэширование, используя несколько альтернативных вариантов: продукты с открытым кодом и Zend Accelerator (раньше известен как Zend Cache), который является закрытым коммерческим продуктом. Только кэшированный opcode совместим с Zend Optimizer и Zend Accelerator. Opcode кэш ускоряет выполнение, удаляя из цепочки загрузку исходного скрипта и его компиляцию. Время выполнения, с использованием кэширования, может улучшиться от 10 до 200%.

ДОПОЛНЕНИЕ:

Где искать инструменты для кэширования opcode?

Zend Accelerator. Это коммерческий продукт, развитый командой Zend Engine. Очень надежный. Искать здесь: http://zend.com.

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

Turck MMCache (http://turck-mmcache.sourceforge.net/) больше не поддерживается. Смотрите eAccelerator, который является развитием mmcache и активно развивается.

Один из секретов высокой производительности состоит не в том, чтобы написать быстрый PHP код, а в том, чтобы кэшировать результаты выполнения скрипта в файл или общую память. Скрипт запускается однажды, генерируемый HTML захватывается и все последующие обращения к скрипту приводят к показу уже готового HTML. Если требуется регулярное обновление данных, то необходимо указать срок жизни для кэшированных HTML. Кэширование HTML это не часть PHP языка или Zend Engine но осуществляется при помощи PHP кода. Существует много классов и библиотек для организации подобного. Одна из них PEAR Cache, о которой мы поговорим в следующей части. Другой распространенный способ библиотека Smarty.

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

Если ваш HTML очень сжимаем, то это может уменьшить размер на 50-80%, сокращая тем самым требования пропускного канала. Другая сторона это необходимость в более мощном процессоре, чтобы эффективно и быстро сжимать страницы.

HTML кэширование с использованием PEAR Cache

PEAR Cache это набор классов для кэширования разнообразных типов данных, включая HTML и картинки.

Самое распространенное использование PEAR Cache это кэширование HTML текста. Чтобы использовать кэширование задействуем Output buffering class, с кэшированием всего выдаваемого текста между функциями start() и end():

Примечание: С тех пор, как я написал эти строки, была создана более продвинутая система кэширования PEAR: Cache Lite (http://pear.php.net/package/Cache_Lite); чтобы узнать об этом подробнее, смотрите memcached (http://www.danga.com/memcached/).

Cache конструктор принимает первым параметром тип драйвера для сохранения кэша. Доступны следующие драйверы: файл, база данных, общая память (смотрите папку: pear/Cache/Container). Тесты Ulf Wendel показывают, что драйвер файл дает наилучшую производительность. Второй параметр это параметры для используемого драйвера. Варианты: cache_dir это папка для сохранения кэшированных данных, filename_prefix уникальная приставка к названию файлов для сохранения кэшированных данных. Что странно, время жизни кэша не является параметром для конструктора.

Для кэширования каких-то данных, вам необходимо сгенерировать уникальный ключ (id) для этих данных. В примере выше, мы использовали md5(«это уникальный ключ!»).

Функция start() использует ключ для поиска кэшированной копии данных. Если контент не был кэширован, функция вернет пустую строку. И все последующие echo и print будут буферизироваться в кэш, до тех пор, пока не встретится функция end().

Функция end() возвращает содержимое буфера и заканчивает буферизацию вывода. Функция end() принимает в качестве первого параметра время жизни кэша. Этим параметром могут быть секунды или Unix таймштамп, указывающий точное время окончания жизни кэша, или установит интервал по умолчанию 24 часа.

Другой способ использования PEAR Cache это сохранение значения переменных или других данных. Для реализации этого используйте основной Cache класс:

Для сохранения используемых данных применяйте функцию save(). Если выбранный вами уникальный ключ уже существует, вы можете использовать функцию generateID(). Объекты и массивы могут быть сохранены благодаря использованию функции serialize() внутри функции save(). Последний параметр это время жизни кэша. Этим параметром могут быть секунды или Unix таймштамп, указывающий точное время окончания жизни кэша, или установит интервал по умолчанию 24 часа. Для получения кэшированных данных используйте функцию get().

Использование тестов производительности

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

Если вы хотите получить наиболее реалистичные тесты производительности вебсервера, вам необходим инструмент, умеющий посылать разнообразные HTTP запросы. На Unix обычные инструментальные средства тестирования включают ab (сокращение от apachebench), который являются частью пакета Apache. И более нового flood (http://httpd.apache.org/test/flood). На Windows NT/2000 вы можете использовать Microsoft’s free Web Application Stress Tool (http://webtool.rte.microsoft.com).

Эти утилиты могут делать параллельные множественные HTTP запросы моделируя тем самым множество клиентов сети, и выдавать вам детальную статистику по завершению теста.

Вы можете контролировать, каким образом ведет себя ваш сервер, поскольку тесты проводятся на основе Unix с использованием «vmstat1«. Он печатает информацию о статусе вашего диска, виртуальной памяти, и загрузки процессора каждую секунду. Альтернативно вы можете использовать «top d 1» который дает вам полноэкранную индикацию всех процессов запущенных и сортированных по степени загрузки процессора каждую секунду.

На Windows 2000 вы можете использовать Performance Monitor или Task Manager для просмотра статистики своей системы.

Если вы хотите проверить специфический аспект вашего кода без необходимости использования HTTP запросов, вы можете написать тест с использованием функции microtime(), которая возвращает текущее время в микросекундах в виде строки. Следующая функции конвертирует это значение в число, подходящее для статистики:

Альтернативно, вы можете использовать специальные инструменты для профелирования: APD (http://www.linuxjournal.com/article.php?s >

Этапы тестирования производительности

Далее, я привожу детали реального теста производительности, созданного для одного из клиентов. В данном случае, клиент хотел гарантированное время отклика 5 секунд для любой PHP страницы, которая не делала сложных SQL запросов. Конфигурация сервера: Apache 1.3.20, PHP 4.0.6 на Red Hat 7.2 Linux. Аппаратное обеспечение: два Pentium III 933 Mhz, 1Gb RAM. HTTP запросы будут обращаться к скрипту testmysql.php. Этот скрипт читает и обрабатывает примерно 20 записей из MySql базы данных, расположенной на другом сервере. Для простоты мы предполагаем, что вся графика грузится с другого сервера.

Как инструмент для тестирования производительности мы использовали ab. Мы задали ab делать 1000 запросов (-n1000), используя 10 одновременных соединений (-c10). Вот результаты:

После запуска теста производительности, он начал контролировать на стороне сервера использование ресурсов с использованием команды «top d 1«. Параметр «d 1» указывает, что необходимо делать задержку в 1 секунду перед обновлением данных. Вывод показан ниже.

Посмотрите на шапку вывода. Результаты показывают, что Apache, на машине с двумя процессорами, отработал с 0% простоя. Это очень плохо. Средняя загрузка составила 9.07 за последнюю минуту (3.29 за последние 5 минут, 1.79 за последние 15 минут). Средняя загрузка это среднее число процессов, готовых быть запущенными. Для двухпроцессорного сервера любая загрузка больше 2, означает, что система будет перегружена процессами. Здесь вы можете видеть тесную связь между загруженностью 9.07 и количеством запущенных процессов (10), которые были определены в тесте ab.

К счастью, мы располагаем большим объемом свободной оперативной памяти, приблизительно 798 160 Мб, никакой виртуальной памяти не используется.

Далее, внизу, мы можем видет процессы, упорядоченные по количеству использования центрального процессора. Самые активные это процессы Apache (httpd). Первая задача httpd использует 7280 Кб памяти и отнимет в среднем 21.2% процессора, и 0.7% оперативной памяти. Колонка STAT показывает статус: R работает, S бездействует, W означает, что процесс выгружен из памяти.

Вышеприведенные цифры показывают нам типичную пиковую нагрузку, мы можем сделать некоторое планирование. Если среднее число загрузки для сервера с двумя процессорами 9.0, и задача отнимает для исполнения примерно одно и тоже время, то слегка загруженный сервер должен быть 9.0/2 процессора = в 4.5 раз более быстрым. Так что HTTP запрос, который обыкновенно занимал 1.283 секунды, при пиковой нагрузке займет примерно 1.283/4.5 = 0.285 секунд.

Для проверки этого, мы делаем тест производительности с 2 одновременными процессами (вместо 10 выше). Получаем 0.281 секунды, что очень близко к предсказанному значению 0.285!

Наоборот, удваивая количество подключений, мы можем предсказать, что среднее время выполнения должно удвоиться с 1.283 до 2.566 секунд. В тестах производительности мы, фактически, получили 2.570 секунд.

Перегрузка при 40 подключениях

После того, как мы запустили тест производительности с 40 запросами, сервер был перегружен с 35% неудачных запросов. При дальнейшем расследовании было обнаружено, что MySql сервер отказывал в запросах с ошибкой Слишком много подключений.

Тест производительности также указал на поведение дочерних процессов Apache. Каждый скрипт PHP использовал 2 постоянных соединения, так, на 40 запросах мы имели 80 постоянных подключений, что значительно ниже значения по умолчанию MySql (max_connections 100). Однако, дочерние процессы Apache, которым не переданы немедленно новые запросы, всеравно удерживают постоянное соединение. Эти неактивные дочерние процессы породили еще более 20 постоянных соединений, которые оказались соломкой, которая сломала спину верблюду.

Исправляем ситуацию

Переведя скрипты на непостоянные соединения, мы устранили эту проблему и получили результат 5.340 секунд. Альтернативное решение состояло в том, чтобы увеличить MySql max_connections выше, чем значение по умолчанию.

Заключение

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

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

Из вышеприведенных значений, мы можем вычислить какое количество соединений мы можем обработать не выходя за пределы желаемого времени ответа. Предполагая наличе двусторонней сети с временем доступа 0.5 секунд на Internet (0.25 секунд одна сторона), мы можем предсказать:

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

Для получения максимального количества страниц для просмотра в день, мы должны умножить пиковую способность в секунду на 50.000 (эта методика предложена веб-мастерами pair.com, большой хостинговой компанией), что даст нам 340 000 страниц в день.

Оптимизация кода

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

Большинство PHP сценариев просты. Они получают небольшое количество информации о сессии, загружают некоторое количество информации из системы управления контентом или базы данных, форматируют соответствующий HTML и отдают результат своей работы HTTP клиенту. Предположим, что типичный PHP сценарий исполняется 0.1 секунду, время ожидания Internet 0.2 секунды, только 33% времени из этих 0.3 секунд будут использоваться для генерации PHP сценарием ответа. Так, если вы улучшите скорость своего скрипта на 20%, клиент будет видеть, что время ответа сократилось до 0.28 секунд, что является незначительным усовершенствованием. Конечно сервер сможет обработать на 20% больше запросов к одной и той же странице, что увеличивает масштабируемость.

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

Высокие степени оптимизации

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

Пример 1

Вот вам один из простых примеров, печатающих массив:

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

Для начала необходимо понять, что выражение $j prop++) примерно в три раза медленнее чем локальная переменная.

  • Увеличение неопределенной локальной переменной примерно в 9-10 раз медленнее, чем предопределенной.
  • Только определение глобальной переменной без ее использования в функции также замедляет работу (примерно на тоже самое время, как и увеличение локальной переменной). PHP, вероятно, делает проверку на существование глобальной переменной.
  • Скорость обращения к методу не зависит от количества методов в классе, потому что я добавил еще более 10 методов в тестовый класс, что не привело к изменениям в скорости.
  • Методы в производных классах работаю быстрее, нежели определенные в базовом классе.
  • Функции с одним параметром вызова, а также с пустым телом занимают по времени столько же, сколько занимают 7-8 операций $localvar++. Вызов подобного метода занимает 15 $localvar++.
  • Дополнение от 11 июля 2004: эти испытания были проведены почти 3 года назад. Я проверил эти данные вновь на версии 4.3.3. Вызов функции теперь занимает 20 $localvar++, а вызов метода 30 $localvar++. Это может быть потому, что $localvar++ стало выполняться быстрее или вызов функция стал медленнее.

    Резюме

    1. Чем больше вы разбираетесь в программном обеспечении, которое вы используете (Apache, PHP, IIS, база данных), и чем глубже ваши знания операционной системы, организации сети, аппаратного обеспечения сервера, тем лучше вы сможете выполнить глобальную оптимизацию вашего кода и вашей системы.
    2. Для PHP скриптов самое узкое место обычно это центральный процессор. Два процессора, вероятно, будут лучше, чем два гигабайта оперативной памяти.
    3. Сборка PHP с параметром configure enable-inline-optimization позволяет сделать максимально быстрый исполняемый файл.
    4. Оптимизируйте вашу базу данных и индексы, которые чаще всего используются в параметре WHERE ваших SQL запросов. ADODB очень популярная библиотека абстрактного доступа позволяет работать в режими оптимизации SQL запросов, где вы можете всесторонне изучить ваши неудачные SQL запросы, а также определить, в каком скрипте они выполняются.
    5. Используйте кэширование HTML, если ваши данные редко меняются. Даже если ваши данные меняются каждую минуту кэширование может помочь, если данные синхронизировать с кэшем. В зависимости от сложности кода, кэширование позволяет улучшить скорость до 10 раз.
    6. Тестируйте производительность вашего сложного кода на ранних этапах (или по крайней мере его опытные образцы), таким образом вы получите чувство ожидаемых параметров работы, прежде чем будет слишком поздно. Попробуйте использовать реалистические количества испытательных данных, чтобы гарантировать должную масштабируемость.

    7. Рассмотрите возможности использования кэширования опкода. Это дает прирост производительности на 10-200% в зависимости от сложности вашего кода. Обязательно сделайте стресс тестирование вашего кода, прежде чем устанавливать оптимизаторы на реально работающий сервер, поскольку некоторые из них более надежны чем другие.
    8. Используйте ob_start() в начале вашего кода. Это даст вам повышение производительности на 5-15%. Вы также можете использовать gzip сжатие для организации быстрых загрузок (это требует дополнительных ресурсов центрального процессора).
    9. Рассмотрите возможность установки Zend Optimizer‘а. Это бесплатное программное обеспечение делает некоторую оптимизацию, но будте внимательны некоторые скрипты фактически замедляются, когда установлен Zend Optimizer. В основном, Zend Optimizer очень полезен, когда ваш код содержит множество циклов.
    10. Оптимизируйте код циклов. Переместите определения, по которым работает цикл перед циклом.
    11. Используйте массивы и строковые функции везде, где это возможно. Они работают значительно быстрее, чем написание аналогичного кода.
    12. Самый быстрый способ связать многократные небольшие строки в одну это использовать буфер вывода (ob_start()) и печатать echo в буфер. В конце получить данные функцией ob_get_contents. Это работает, потомучто для буферизации выделяется первоначальный буфер в 40 кб, который растет кусками по 10 кб.
    13. Работая с массивами и объектами используйте ссылки где это возможно. Если это короткий скрипт, и обслуживание кода это не проблема, вы можете использовать глобальные переменные для сохранения объектов и массивов.
    14. Если у вас много скриптов, использующих переменные сессии, рассмотрите возможность скомпилировать PHP для использования общедоступной памяти для сессий, или используйте RAM диск для их хранения. Включите эти возможности configure with-mm, затем перекомпилируйте PHP, а также установите session.save handler = mm в php.ini.
    15. Для поиска подстроки, используйте самую быструю команду strpos(), preg_match() и уж затем ereg(). Точно также str_replace() быстрее чем preg_replace(), которая, в свою очередь, быстрее, чем ereg_replace().
    16. Располагайте наиболее часто встречающиеся утверждения switch в самом верху. Если большинство случаев попадает под значение по умолчанию, определите его также в самом начале.
    17. Обработка XML данных регулярными выражениями работает значительно быстрее, чем использование SAX и DOM.
    18. Делайте unset() неиспользуемых более переменных, чтобы освободить память. Это главным образом полезно для ресурсов и больших массивов.
    19. Для классов с глубокой иерархией расширенные функции работают быстрее, чем определенные в основном классе (родительском). Рассмотрите возможность копирования часто используемых функций из основного класса в наследующий.
    20. Рассмотрите возможность написание вашего кода как расширение PHP или Java класс или COM объект, если вы нуждаетесь в сверхскорости. Будте осторожны при обмене данными между COM и Java.

    Бесполезная оптимизация

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

    Вот некоторые общие легенды:

    1. Echo быстрее чем print. Считается, что echo быстрее, так как не возвращает никакого значения, тогда как print возвращает. Из моих тестов производительности PHP 4.3 видно, что различие в них пренебрежительно малы. И в некоторых ситуациях print быстрее echo (когда ob_start включен).
    2. Удаление из кода комментариев ускоряет его выполнение. Если вы используете кэширование опкода, комментарии уже проигнорированы. Это миф, тянущийся со времен PHP 3, когда каждая строка скрипта интерпретировалась в момент ее выполнения.
    3. ‘var=’ . $var быстрее чем «var=$var». Это было справедливо для PHP 4.2 и более ранних версий. В PHP 4.3 это было устранено. Добавление от 22 июня 2004: очевидно, что в PHP 4.3 скорость была значительно увеличена, но различия устранены не полностью. Однако, я нахожу, что различия стали незначительными.

    Ускоряют ли ссылки ваш код?

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

    И тот же самый код без ссылок:

    PHP фактически не создает копии переменных, когда обрабатывает значение, но использует вместо этого очень быструю ссылку, рассчитывая все внутри себя. Так в TestRef(), $b и $c будут устанавливаться дольше, так как ссылки должны отслеживаться, в то время как TestNoRef() $b и $c только указывают на первоначальное значение $a и PHP всего лишь увеличивает число ссылок. Поэтому TestNoRef() будет выполнена быстрее, чем TestRef().

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

    быстрее, чем этот:

    Замечание: в PHP 5 все объекты передаются по ссылке автоматически, без требования явного указания &. Объектная модель PHP 5 должна быть значительно быстрее.

    Что вы можете сделать для ускорения работы веб-сайтов 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 7.0: краткая инструкция для системного администратора. Часть 1 – установка.

    Как я и обещал в посте несколько дней назад, начинаю писать серию постов типа инструкций шаг за шагом «как это установить и настроить» для тех админов, у которых действительно мало времени «на найти и разобраться», да еще если все это на английском языке. Кстати, кому таки не лениво – вот здесь очень хорошая подборка англоязычных документов под общим названием «Windows Server 2008 Step-by-Step Guides» — очень полезно в работе. Надеюсь, найдутся время и ресурсы, чтобы их тоже «отфильтровать» и сделать на их базе русские версии.

    Если вам не интересны мои мысли «почему я пишу про IIS 7.0», можете смело пропустить пару абзацев.

    В ближайший месяц я буду писать о веб-платформе от Microsoft, и в основном это будет касаться администрирования Internet Information Services 7.0 (IIS 7.0), входящего в состав Windows Server 2008. Это не значит, что я не буду писать ни о чем другом – конечно буду, у меня масса планов и тем с барселонского TechEd IT Forum 2008, в основном по направлению Windows Server 2008 R2, просто про администрирование IIS7 буду писать в этот месяц намного чаще и более последовательно, чем я это делал ранее. Поэтому даже те, для кого тема IIS7 не интересна, смогут как минимум раз в неделю находить у меня на блоге что-то интересное по другим тематикам.

    Почему именно IIS 7.0? Здесь несколько причин. Во-первых, в уже упомянутом сборнике документов «шаг за шагом» «Windows Server 2008 Step-by-Step Guides» по странному стечению обстоятельств документа по IIS 7.0 почему-то нет. Во-вторых, как показывает опыт семинаров TechNet в Украине – знания, и даже можно сказать – представления многих админов о технологиях Microsoft для веб базируются на «сказках-страшилках» конца прошлого века, и хотелось бы показать всем желающим простой путь попробовать все технологии самостоятельно, без каких-то предрассудков и прочих ОБС. В-третьих – мне самому, человеку, который достаточно долгий период своей жизни занимался вебом вообще и IIS в частности – а я помню и IIS 2.0, и 3.0, и 4.0 и, конечно же, 5.0 – эта тема близка и интересна, и могу сказать, что за 10 лет в этом направлении Microsoft сделал существенные, даже можно сказать – эпохальные шаги вперед. Потому хотелось бы поделиться и опытом, и знаниями в этой прогрессирующей области с коллегами. В-четвертых – небольшой сюрприз в рамках проводимой в Украине акции для тех, кто разворачивает и управляет веб-серверами под управлением продуктов Microsoft – украинский офис Microsoft проводит акцию, по которой вы можете получить лицензионный Windows Server 2008 Web Edition (коробочная версия) бесплатно для хостинга ваших проектов и сайтов в Интернете. Так что торопитесь получить такой легальный продукт – пишите через блог на почту. И, наконец, в-пятых – в Киеве проводится полигон по веб-технологиям Microsoft, в том числе и IIS 7.0, так что мои статьи послужат хорошим фоном для такого мероприятия.

    Ну, вроде это вcе наиболее веские причины писать в ближайший месяц о IIS 7.0. Кроме одной – зачем вообще админу знание IIS 7.0, который, в принципе, больше является платформой для разработчиков, на которой они делают свои веб-проекты? Проблема в том, что, как показывает опыт, разработчики не очень «напрягаются» созданием архитектуры и проработкой деталей веб-проекта, таких, как безопасность, администрирование, масштабирование и т.п. будущего работаеющего решения. И все это становится головной болью админа. Другая головная боль – это работодатели, которые часто под словом «компьютерщик» понимают, что человек может и спаять сгоревшую плату, и сетку настроить, и программку бухгалтерскую написать. И конечно же – веб сайт родной фирмы «Рога и Ко» сделать – как же без него. А то, что в ИТ отрасли есть глубокая специализация – никого не волнует. И вот потом и пишет мне в Live Messenger такой админ – «Игорь, а что делать?! За что хвататься?!», или если такого «Игоря», который бы подсказал, нет рядом – начинается такое.

    Вроде, мотивы мои всем понятны. получилось довольно длинно, обещаю, сами технические части будут куда короче. Итак.

    Часть 1. Установка IIS 7.0

    Первый вопрос, который мне задают – что такое веб сервер под Windows, что нужно установить? Ответ – вебсервер под Windows – это служба IIS 7.0. Следующий вопрос – где взять IIS 7.0, откуда скачать? Ответ очень простой – IIS 7.0 (как и предыдущие версии, начиная с IIS 5.0) интегрирован в саму серверную ОС Microsoft Windows Server 2008 (а предыдущие версии IIS – соответственно в Windows Server 2003 и Windows 2000) и устанавливается как роль Windows Server. Тогда более тривиальный вопрос – где взять «настоящий» Windows Server 2008? Пробную версию Windows Server 2008 для всех экспериментов и тестирования рекомендую брать только с сайта Microsoft http://www.microsoft.com/windowsserver2008 — проверенная и гарантированно правильная версия (только не забудьте установить все обновления). Серийный номер для Windows Server 2008 не требуется – вы просто при установке в мастере установки оставляете его пустым и на вопрос, хотите ли вы все же его заполнить – гордо отвечаете НЕТ. Фактически, если вы при установке или в ходе эксплуатации таки введете настоящий продуктовый номер – вы получите «настоящую» версию. Версия без введенного серийного номера работает 60 дней, после чего требует активации. Мало кто любит читать иструкции при загрузке файлов, особенно те, которые написаны мелким шрифтом – на самом деле, на странице загрузке есть ссылка на инструкцию, какой скрипт надо запустить, чтобы сбросить счетчик активации Windows снова на 60 дней. Такую операцию надо не забыть сделать до истечения 60дневного срока (например, на 59й день эксплуатации). Всего вы можете посторить операцию сброса счетчика 3 раза – т.е. пробную версию можно эксплуатировать 240 дней, что вполне достаточно с тем, чтобы распробовать плюсы и минусы системы. Ну а для желающих уже сейчас эксплуатировать лицензионный Windows Server 2008 для своих веб-проектов – напоминаю про акцию, пишите.

    Теперь о выборе редакции, которых доступно аж 4 – Datacenter, Enterprise, Standard, Web Edition. Пожалуйста, подходите более ответственно к их выбору. Зачем, ну зачем использовать Enterprise для запуска веб-сайтов – «шоб було?». Для таких задач есть оптимизированная редакция Web Edition. Сравнение возможностей разных редакций можно найти там же, на официальном сайте http://www.microsoft.com/windowsserver2008. Кроме того, некоторые соображения по использованию лицензионных соглашений и виртуализации в разных редакциях я написал на этом блоге ранее.

    После установки экземпляра Windows Server 2008 и его конфигурации (если это также вызывает затруднения – смотрим видео с семинара по Windows Server 2008) переходим непосредственно к установке IIS 7.0. Что нового в IIS 7.0, какие модули включены в него и т.д. – я рассматривать не буду, все теоретические выкладки можно найти в электронной версии журнала TechNet Magazine, которая выходит в том числе и на русском. IIS 7.0 были посвящены 2 статьи в мартовском и июльском номерах журнала. Рекомендую ознакомиться с ними перед практическим применение – знание теории, пусть даже в сжатой форме весьма полезно.

    Основным нововведением в направлении установки различных компонент и служб в Windows Server 2008 является понятие «роли». Роль представляет из себя набор всех необходимых компонент, настроек системы, безопасности и т.п., которые необходимы для выполнения определенной задачи. Кроме того, имеется также информация о взаимодействии ролей между собой – одна роль может работать как подмножество другой и, наоборот – роли могут конфликтовать между собой – об этом администратор будет уведомлен при установке такой роли поверх уже существующих. Установку и конфигурацию всего необходимого система выполняет автоматически при выборе конкретной роли. Такой подход гарантирует, что даже в случае ошибки администратора, связанной с установкой той или иной роли, не требуемой в текущий момент – система будет функционировать нормально и это не затронет работоспособность других ролей. Как впрочем, это также существенно упрощает и сам подход к управлению системой Windows Server 2008 в целом.

    Управление ролями осуществляется через стандартную оснастку управления Windows Server 2008 – Server Manager или в процессе начальной конфигурации сервера через Initial Configuration Tasks.

    IIS 7.0 устанавливается как роль Windows Server 2008. Для этого требуется:

    1. Запустить оснастку Server Manager из меню Start или из панели Quick Launch. Server Manager по умолчанию стартует автоматически при входе администратора в систему. Server Manager является основным инструментом управления сервером Windows Server 2008.

    2. В оснастке на стартовой странице убедиться, что сервер сконфигурирован правильно. Желательно проверить наличие статического IP адреса. Если он не установлен, его можно поменять тут же, из консоли Server Manager, открыв в правой панели по линку «View Network Connections» сетевые интерфейсы.

    3. Выбираем в левой панели Server Manager пункт Roles, в правой панели видим список текущих ролей. В зависимости от редакции ОС и установленных ролей список может варьироваться. В данном примере ни одна роль не установлена.

    4. Для установки новой роли используем в правой панели в разделе «Roles Summary» линк «Add Roles».

    5. Запускается мастер установки ролей «Add Roles Wizard», пропускаем первую страницу «Before You Begin» мастера, нажав кнопку «Next >»

    6. На странице «Select Server Roles» в списке ролей выбираем роль «Web Server (IIS)». Список ролей может отличаться в зависимости от редакции. Данный список соответствует редакции Windows Server 2008 Enterprise Edition x64.

    7. При выборе роли «Web Server (IIS)» мастер автоматически предлагает установить сервисы, которые требуются для функционирования веб сервера. Это службы активации процессов, фактически, они обеспечивают среду исполнения процессов, обслуживающих вебсайты. Соглашаемся с установкой данных служб путем нажатия кнопки «Add Required Features» и нажимаем кнопку «Next >» в мастере.

    8. На странице «Select Role Services» отображается список всех доступных модулей (сервисов), входящих в состав IIS 7.0, представляющих 3 большие группы – Web, Management и FTP – и внутри сгруппированых по назначению – общие модули для поддержки HTTP Common HTTP Features, модули для исполнения сценариев и приложений Application Development, модули управления журналированием и диагностикой Health and Diagnostics, модули обеспечения безопасности Security, производительности Performance, модули управления и совместимости с предыдущей версией IIS 6.0 Management Tools, и, наконец, модули FTP. По умолчанию роль веб сервера IIS 7.0 устанавливается и конфигурируется в минимальном наборе из 9 модулей:

    a. только для работы со статическим HTML контентом (модули из Common HTTP Features),

    b. только с подключением анонимных пользователей и с фильтрацией вредоносных запросов (Security),

    c. с базовыми модулями для журналирования запросов к вебсайтам на сервере и просмотра очереди запросов (Health and Diagnostics),

    d. с модулем сжатия статического контента при передаче страниц клиенту HTTP (Performance),

    e. и консоли администрирования в режиме локального подключения к веб серверу IIS Management Console.

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

    10. При отметке отдельного модуля для добавления, также, как и при выборе роли, мастер автоматически проводит проверку всех связей и зависимостей и предлагает установить дополнительные модули, без которых функционирование выбраного невозможно. В данном примере для установки выбран модуль ASP.NET и мастер автоматически запрашивает разрешение на установку других модулей и служб, необходимых для его работы. Соглашаемся с установкой данных служб и модулей путем нажатия кнопки «Add Required Role Services». По окончанию выбора всех модулей нажимаем кнопку «Next >» в мастере.

    11. На странице «Confirm Installation Selection» отображается для подтверждения информация о всех выбранных модулях, которые будут установлены. Также отображаются служебные и информационные сообщения рекомендательного характера. Например, рекомендация после установки роли IIS 7.0 выполнить обновления ОС или установить Windows System Resource Manager (WSRM), который позволяет обеспечить распределение ресурсов системы при выполнении веб-приложений. Нажатие кнопки «Next >» на этой странице устанавливает весь указанный перечень модулей.

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

    13. После закрытия окна мастера установки роли в левой панели консоли Server Manager в разделе «Roles» среди других ролей появляется подраздел «Web Server (IIS)». В правой панели отображается информация о состоянии всех установленных ролей.

    14. Выбираем подраздел «Web Server (IIS)» в левой панели Server Manager, в правой панели отображается информация о работе роли веб сервера. Здесь представлены:

    a. Events: агрегированный список записей из всех журналов событий ОС за последние 24 часа, имеющих отношение к работе веб служб,

    b. System Services: список всех системных сервисов, обеспечивающих функционирование данной роли и с возможностями по управлению ими и мониторингу их состояний,

    c. Role Services: в данном случае – список всех модулей IIS 7.0 с указанием установлен данный модуль или нет и с возможностями старта мастера установки/удаления модулей данной роли (о котором мы говорили выше),

    d. Resources and Support: наиболее интересный раздел информации о каждой роли, который содержит в себе базу знаний с рекомендациями по дополнительной более тонкой настройке той или иной роли для отдельных сценариев использования. Рекомендуется к широкому использованию.

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

    Выжать максимум: тонкая настройка производительности серверных версий Windows

    Содержание статьи

    Win2k3 и Win2k8 по умолчанию оптимизированы под стандартную сетевую среду. Но
    если серверную ОС надлежащим образом настроить (например, под требования
    компании), то это благоприятно отразится на каждом аспекте работы сети, начиная
    от самого оборудования и заканчивая пользователями, подключенными к серверу.

    Анализируем причину

    Любая внештатная ситуация, в том числе и снижение производительности сервера,
    требует тщательного анализа. Не собрав всей информации, можно нагородить дел.
    Возьмем такой случай. Контроллер домена (КД) уже не справляется со своими
    обязанностями — пользователи подолгу регистрируются в системе или не могут зайти
    в сетевую папку. В зависимости от топологии Сети, вариантов решения может быть
    несколько.

    Например, можно модернизировать железо, перераспределить нагрузку между
    серверами (в том случае, когда КД выполняет еще и другую задачу) или же снизить
    нагрузку на основной КД за счет установки еще одного КД в отдельном
    подразделении компании. При использовании Win2k8 в удаленном офисе есть вариант
    установить контроллер домена только для чтения (RODC). Тогда в случае
    компрометации сервера или банальной кражи оборудования можно не бояться за
    нарушение функционирования всего леса (подробности смотри в статье «В лабиринте
    AD»). Так мы разгрузим основной КД и снизим нагрузку на Сеть (в том числе и на
    внешний канал, если для соединения между офисами используется интернет).

    Узкие места могут возникать по нескольким причинам:

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

    Теперь разберем некоторые моменты подробнее.

    Ищем бутылочное горлышко

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

    В новой Win2k8 и Win2k3, которая еще долго будет верой и правдой служить на
    серверах, системы мониторинга несколько отличаются, но не настолько, чтобы не
    разобраться при смене системы. Диспетчер задач, вызываемый по (в
    Win2k8 нужно будет выбрать в меню еще и Start Task Manager) или ,
    позволяет во вкладке Performance увидеть состояние основных системных ресурсов (CPU,
    ОЗУ) и Сети (во вкладке Networking). В обеих системах можно оценить вклад
    отдельного процесса в общую потерю производительности. Если информации
    недостаточно, добавляем счетчики производительности. Для этого достаточно
    перейти во вкладку «Processes» и выбрать в меню View — Select Columns, после
    чего установить флажки напротив нужных пунктов. По умолчанию активировано всего
    два счетчика: CPU Usage (загрузка ЦП) и Memory — Private Working Set (Memory
    Usage в Win2k3, Использование памяти). Названия некоторых счетчиков в системах
    отличаются, но разобраться несложно.

    В Win2k3 для наблюдения за производительностью системы в штатную поставку
    входит «Монитор Производительности» (вызывается через Старт —
    Администрирование — Производительность, perfmon.msc), который выводит показания
    активных счетчиков в виде графиков, диаграмм или таблиц. Ведется история
    событий, помогающая отследить все изменения. При достижении порогового значения
    можно, например, отправить сообщение админу — в общем, выполнить действие.
    Подробности о «Мониторе Производительности» и основных счетчиках смотри в статье
    «Поставь сервер на
    счетчик», опубликованной в X_11_2007.

    На сайте Microsoft для Win2k3 доступно еще одно эффективное, хотя и
    малоизвестное средство анализа производительности — Server Performance Advisor
    V2.0 (SPA). С помощью этой утилиты можно собрать информацию о настройках, данные
    со счетчиков с одного или нескольких серверов, отслеживать события (Event
    Tracing). По результатам работы получим удобные для чтения и анализа отчеты о
    производительности, содержащие предупреждения и рекомендации по устранению
    неполадок. В SPA имеется более 90 предварительно настроенных групп коллекторов.
    Причем самые востребованные уже настроены! Например, коллектор System Overview
    содержит основные системные счетчики: CPU usage, Memory usage, занятые файлы и
    TCP-клиенты, top-потребители CPU, а также счетчики для основных серверов —
    контроллеров домена, файловых служб AD, IIS, DNS, Terminal Services, SQL и др.

    В Win2k8 контроль за основными параметрами системы возложен на Reliability
    and Performance Monitor (RPM), который вобрал в себя функции отдельных
    приложений, доступных в Win2k3. Запустить его можно несколькими способами: из
    меню Administrative Tools, нажатием клавиши Resource Monitor во вкладке
    Performance в Task Manager, выбрав пункт в меню Diagnostic в Server Manager или
    введя в консоли perfmon.exe. В главном окне RPM увидим четыре графика, выводящие
    информацию о загрузке CPU, Disk, Memory и Network в реальном времени. Чуть ниже
    расположены таблицы с подробной информацией, разбитой по этим же группам. В
    каждой показан процесс и связанные с ним данные (PID, объем ОЗУ, загрузка CPU,
    Response Time дисковых операций, количество переданных и принятых сетевых
    пакетов и прочее).

    Зачастую достаточно одного взгляда на графики и таблицу, чтобы оценить
    обстановку и принять решение. Но и это еще не все. «Монитор Производительности»
    находится в меню Performance Monitor. По умолчанию активирован только один
    счетчик Processor Time, но достаточно выбрать в контекстном меню Add
    Counter, как откроется одноименное окно, в котором можно выбрать нужный счетчик.
    Полный список охватывает все параметры системы и сервисов. Следующее меню, хотя
    и не связано с оценкой производительности, — тем не менее, очень полезно при
    поиске неисправностей. Речь идет о Reliability Monitor («Монитор Надежности»).
    Справа от графика выводится индекс ожидания появления проблемы System Stability
    Index («Системный Индекс Устойчивости»). График Stability Index помогает быстро
    найти дату, когда было замечено первое появление проблемы (уменьшился System
    Stability Index). В поле System Stability Report показаны детали возникшей
    проблемы.

    Два меню Data Collector Sets и Reports выступают в роли удобного аналога SPA.
    Так, в первом из них содержатся шаблоны коллекторов, которые могут быть
    использованы с любой программой, предназначенной для сбора данных. Выполнив,
    например, LAN Diagnostics или System Performance (то есть любой коллектор или
    группу), в соответствующем подменю в Reports получим полный отчет.

    Тюнинг системы

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

    Перед внесением изменений сформулируем для себя несколько правил:

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


    Среди советов встречаются такие, как отключение «лишних» сервисов и проверка
    запланированных заданий, но в Win2k8 изначально запущено только то, что
    действительно нужно. Поэтому эти советы больше актуальны для ранних версий
    Windows.

    Оптимизация сети

    Сетевая подсистема в Win2k3/Win2k8 (как, впрочем, и в любой другой ОС)
    является многоуровневой. Глубокий тюнинг следует производить на каждом уровне,
    начиная от драйвера и NDIS (спецификация интерфейса сетевых драйверов) и
    заканчивая уровнем приложений. Начнем «снизу».

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

    Локальные файлы HOSTS (для TCP/IP) и LMHOSTS (NetBEUI), хранящие адреса и
    имена систем, помогают уменьшить количество запросов на разрешение имен. Эти
    настройки можно произвести как вручную, так и зайдя в свойства TCP/IP в
    настройках сетевой карты, и затем выбрав Advanced. Распространять изменения в
    этих файлах можно в небольших сетях вручную, а в AD — при помощи политик.
    Присутствие DNS- и WINS-серверов также способно уменьшить количество лишних
    задержек.

    Кстати, новая концепция ролей в Win2k8 приносит свои плоды: в настройках Сети
    после установки системы ничего лишнего не включено, а новые алгоритмы настройки
    и оптимизации требуют меньше телодвижений со стороны администратора. Например,
    автоматическая настройка TCP Receive Window Auto-Tuning динамически изменяет
    размер принимающего буфера TCP, используемого для хранения входящих данных, тем
    самым повышая пропускную способность, скажем, при передаче больших файлов на
    высокоскоростных каналах (поэтому ключ реестра TcpWindowSize в Win2k8
    игнорируется). Средство Compound TCP (CTCP) увеличивает количество одновременно
    отправляемых данных — ну, и так далее. Впрочем, кое-что нам оставили и для
    ручной настройки.

    Нажав кнопку Configure в свойствах адаптера, получаем во вкладке Advanced
    доступ к ряду настроек (их количество зависит от конкретного адаптера).
    Например, для файлового и FTP сервера рекомендуется задействовать следующие
    опции: IPv4, TCP и UDP Checksum offload, Segmentation offload и TCP offload
    engine (TOE). Поддержка последнего включается следующим образом:

    > netsh int tcp set global chimney = enabled

    Для веб-сервера и сервера базы данных желательно активировать еще и
    Receive-side scaling (RSS). Но если сетевой адаптер не справляется с нагрузкой,
    — наоборот, пробуем по одному отключать все offload настройки. В Link Speed &
    Duplex указывается режим работы адаптера (по умолчанию он выбирается
    автоматически), а в Transmit/Receive Buffers — буфер приема и передачи. В целях
    экономии ресурсов размер буфера по дефолту установлен в минимальное или среднее
    значение. При больших нагрузках это чревато потерями пакетов. Если адаптер
    позволяет вручную изменить размер буфера, то увеличиваем, не задумываясь.

    Параметр Interrupt Moderation по умолчанию установлен в Adaptive.
    Проигравшись с настройками, можно попробовать выбрать приемлемый результат между
    производительностью Сети и нагрузкой на CPU. Если на сервере несколько CPU и
    сетевых карт, то возможна привязка CPU к сетевому адаптеру. Это положительно
    скажется на производительности Сети и системы за счет уменьшения количества
    «лишних» прерываний. Конечно, это не все, что может сделать админ для разгрузки
    Сети. Например, для настройки драйвера http.sys, который используется IIS, есть
    целая ветка реестра:

    Что-то можно сделать и на прикладном уровне. Например, в ISA Server
    реализована функция сжатия данных, передаваемых по протоколу HTTP. Правда, за
    меньший трафик придется платить большей нагрузкой на CPU. В медленных сетях
    пропускная способность повышается на 30%. Также уменьшается задержка при
    передаче информации, хотя нагрузка на процессор не увеличивается более чем на
    20%. Для разгрузки сервера терминалов в Computer Configuration — Administrative
    Templates — Windows Components — Terminal Services — Terminal Server можно
    уменьшить глубину цвета и размер рабочего стола, установить сжатие RDP,
    отключить обои и т.д.

    Дисковая подсистема

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

    Кое-что можно сделать и самому. По умолчанию файл подкачки равен 1.5 объема
    ОЗУ и расположен на системном диске. Последний обычно сильно загружен, к тому же
    подвержен фрагментации. Поэтому, если имеется несколько дисков, создаем файл
    подкачки на каждом. Для этого в Control Panel System выбираем Advanced System
    Setting и получаем знакомое окно System Properties («Свойства системы»).
    Нажимаем во вкладке Advanced в поле Performance кнопку Setting, снова щелкаем
    Advanced, а затем кнопку Change. В появившемся окне снимаем флажок «Automatically
    manage paging file for all driver» и указываем, на каких дисках и разделах
    следует создать файл подкачки. При этом следует помнить, что использование
    нескольких разделов одного диска для файла подкачки, мягко говоря,
    нецелесообразно. Своп лучше размещать на разделах с меньшей буквой, на которых,
    как правило, скорость повыше.

    По умолчанию Windows записывает данные блоками по 64 Кб, но жесткие диски и
    приложения могут использовать блоки других размеров. Данные в этом случае
    придется записывать на несколько секторов, что снижает производительность. В
    состав Win2k8 и Win2k3 SP1 входит программа Diskpart, предназначенная для
    создания разделов диска. С ее помощью можно задать другое смещение. Пользоваться
    программой просто. Для запуска в командной строке набираем diskpart.exe. Далее
    командой «List Disk» выводим список дисков, выбираем нужный диск — «Select Disk
    1», создаем раздел «Create Partition Primary Align=64» и присваиваем ему букву
    («Assign Letter=D»). Помни, что Diskpart уничтожает данные, поэтому
    предварительно создай резервную копию!

    Также стоит отключить индексацию файлов для (якобы) быстрого поиска и
    компрессию диска (если взведен флажок «Compress this drive to save disk space»).
    И, конечно же, не забываем о периодической дефрагментации (Свойства диска —
    Tools — Defragment Now). В подменю Shadow Copies находятся настройки теневых
    копий. Если резервирование производится другими средствами, то для повышения
    производительности их можно отключить или изменить алгоритм работы.

    Не помешает знать и о некоторых параметрах реестра (они подходят и для
    Win2k3). Так, параметр NumberOfRequests, зависимый от драйвера сетевой карты,
    позволяет задать количество запросов, ускоряя работу за счет распараллеливания.
    Драйвер сам устанавливает оптимальное значение, но рекомендуется установить его
    в диапазоне от 32 до 96.

    Установка в 0 ключа CountOperations позволит отключить некоторые счетчики,
    что также повлияет на производительность в лучшую сторону:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Session Manager\I/O System\CountOperations

    Установка в 1 (REG_DWORD) ключа DontVerifyRandomDrivers запрещает
    тестирование и проверку некорректно работающих драйверов:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Session Manager\Memory
    Management\DontVerifyRandomDrivers

    В Win2k8 используется сложный алгоритм, индивидуально управляющий приоритетом
    I/O. Если для экспериментов ты захочешь его отключить, установи в 0:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceClasses\ GUID>\DeviceParameters\Classpnp\IdlePrioritySupported\I/O Priorities

    Чтобы запретить обновление даты последнего обращения к файлу, устанавливаем в
    1 (REG_DWORD) ключ:

    Это только основные параметры. А подробную информацию по настройке дисковой
    подсистемы можно найти в документе «Disk Subsystem Performance Analysis for
    Windows» на сайте Microsoft.

    Точность хирурга

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

    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

    Есть ли способ повысить производительность вашего 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. До сих пор вы можете пойти с общим советом.

    Как оценить посещаемость (количество пользователей) на сайте IIS

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

    Проще всего определить количество активных сессией пользователей на веб сайте IIS при помощи счетчиков производительности в мониторе производительности Windows (Performance Monitor).

    Откройте консоль Performance Monitor, выполнив команду perfmon и перейдите в консоль монитора производительности (Monitoring Tools —> Performance Monitor).

    Далее нужно добавить в окно монитора необходимые нам счетчики (по умолчанию в окне отображается счетчик общей загрузки CPU — его можно удалить). Чтобы добавить новый счетчик, нажмите зеленую кнопку в панели инструментов (на скриншоте она выделена) или нажмите комбинацию клавиш Ctrl+N.

    В списке доступных категорий счетчиков найдем и развернем группу Web Service. В этой категории нас интересуют три счетчика:

    • CurrentAnonymousUsers – количество анонимных пользователей IIS;
    • CurrentNon-AnonymousUsers – количество авторизованных (неанонимных) пользователей IIS;
    • CurrentConnections – общее число активных подключений на сервере IIS.

    Выберем нужный счетчик и в поле экземпляров счетчика (Instances of selected objects) выберем один или несколько сайтов IIS, для которых нужно отобразить информацию о подключениях. Информация по пользователям всех сайтов на сервере содержится в экземпляре _Total. Осталось нажать кнопку Add >>, чтобы нужный счетчик переместился в список добавляемых счетчиков в правом окне.

    Точно так же добавим все необходимые счетчики и нажмем ОК.

    Теперь в консоли Performance Monitor в режиме реального времени будет отображаться информация о количестве активных подключений (сессий) пользователей на веб сервере/сайте IIS (по умолчанию значения счетчиков выводятся в виде линейных графиков). Выбрав в нижней панели любой из счетчиков можно посмотреть его текущее (last), среднее (average), минимальное (minimum) и максимальное (maximum) значение за данный период времени.

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

    Доступ к данным счетчиков производительности для сайтов IIS можно получить и из PowerShell. Для этого достаточно использовать командлет получения данных из счетчика производительности Get-Counter.

    Список всех доступных счетчиков производительности для службы Web Service можно вывести так:

    Чтобы получить информацию о текущем количестве активных подключений на сервере IIS (счетчик \Web Service(*)\Current Connections) воспользуйтесь такой командой:

    Get-Counter -Counter “\Web Service(*)\Current Connections”

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

    • Значения нескольких счетчиков можно вывести, указав их через запятую;
    • С ключем Continuous информация о значении счетчика будет выводится в консоль постоянно, пока не будет выполнено прерывание командой CTRL+C.

    Как мы уже говорили, можно получить количество активных сессии для конкретного сайта IIS. Например, чтобы получить текущее количество соединений на сайте с именем Site1, выполните команду (вы можете указать имя сервера, на котором проверяется значение счетчика, при проверке количества подключений на сайте локально, указывать localhost недопустимо):

    Get-Counter «web service(Site1)\current connections» -ComputerName web-app01

    Чтобы не указывать каждый раз имя сервера, можно использовать переменную окружения COMPUTERNAME

    Get-Counter «web service(Site1)\current connections» -ComputerName $env:COMPUTERNAME

    Для получения числового значения счетчика «current connections» всего веб-сервера IIS (суммарная нагрузка на IIS) можно использовать такой код:

    ((Get-Counter -Counter ‘web service(_total)\current connections’ -computer $env:COMPUTERNAME) | Select-Object -Expand countersamples).Cookedvalue

    Попробуем с помощью простого скрипта создать несколько дополнительных сессии с нашим сайтом и проверить значение счетчика. Можно накрутить количество обращений к IIS с помощью с помощью командлета Invoke-WebRequest, а можно просто открыть несколько окон в браузере:

    $counter = 20
    for($i=1;$i -le $counter;$i++)<
    $SiteAdress = «http://localhost:9666/»
    Start-Process $SiteAdress
    >

    После этого проверьте значение счетчика current connections и убедитесь, что он увеличиться.

    Если на сервере запушено несколько сайтов IIS, и нужно получить количество подключений к каждому из них в табличном виде, можно воспользоваться таким скриптом (для получения данных из IIS в PowerShell нужно загрузить модуль WebAdministration):

    import-module webadministration
    function get-CurrentConnection($Site) <
    Get-Counter «web service($Site)\current connections,web service($Site)\ Bytes Received/sec,web service($Site)\Bytes Sent/sec» -ComputerName $env:COMPUTERNAME
    >
    $IISsites = dir IIS:\Sites | Select Name
    $CurrentConnection = @()
    foreach ($site in $IISsites)
    <
    Write-Host $site
    $ConnCount = New-Object psobject | get-CurrentConnection -Site $site.name
    $CurrentConnection += $ConnCount
    >
    $CurrentConnection|out-gridview

    Также вы можете вывести числовые значения счетчиков подключений по всем сайтам так (первое значение – суммарное количество подключений к IIS):

    Get-wmiObject -class Win32_PerfRawData_W3SVC_WebService | select-object -expand currentconnections

    Также вы можете отобразить информацию о количество полученных/переданных данных для каждого сайта или всего веб сервера с помощь счетчиков web service(sitename)\ Bytes Received/sec и web service(sitename)\Bytes Sent/sec».

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

    Настройки производительности и оптимизации для веб-службы ASMX на IIS7

    Моя среда: Windows Server 2008, SQL Server 2008, IIS 7, .NET 4.0 и веб-служба .ASMX.

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

    Я нашел эту статью на MSDN, хотя. Просто не уверен, применимо ли это к IIS 7. Итак, что мне нужно сделать здесь в отношении настроек и конфигураций IIS 7?

    Две основные функции производительности IIS 7:

    «IIS 7 предоставляет мощное унифицированное средство для кэширования вывода, интегрируя возможности ASP.NET для динамического кэширования вывода с возможностями статического кэширования вывода, которые присутствовали в IIS 6.0. IIS также позволяет более эффективно и рационально использовать пропускную способность, используя общие механизмы сжатия, такие как Gzip и Deflate «

    IIS предоставляет следующие параметры сжатия: — только статические файлы — только динамические ответы приложений — как статические файлы, так и динамические ответы приложений

    В IIS 7 вы можете настроить кэширование вывода для повышения производительности вашего веб-сервера, сайта или приложения. Когда пользователь запрашивает веб-страницу, IIS обрабатывает запрос и возвращает страницу в браузер клиента. Если вы включите кэширование вывода, копия этой обработанной веб-страницы будет храниться в памяти на веб-сервере и возвращаться в браузеры клиентов при последующих запросах к тому же ресурсу. Это устраняет необходимость повторной обработки страницы каждый раз, когда она запрашивается. Это полезно, когда ваш контент зависит от внешней программы для обработки, например, с программой Common Gateway Interface (CGI), или содержит данные из внешнего источника, например из удаленного общего ресурса или базы данных.

    IIS 7.0: краткая инструкция для системного администратора. Часть 1 – установка.

    Как я и обещал в посте несколько дней назад, начинаю писать серию постов типа инструкций шаг за шагом «как это установить и настроить» для тех админов, у которых действительно мало времени «на найти и разобраться», да еще если все это на английском языке. Кстати, кому таки не лениво – вот здесь очень хорошая подборка англоязычных документов под общим названием «Windows Server 2008 Step-by-Step Guides» — очень полезно в работе. Надеюсь, найдутся время и ресурсы, чтобы их тоже «отфильтровать» и сделать на их базе русские версии.

    Если вам не интересны мои мысли «почему я пишу про IIS 7.0», можете смело пропустить пару абзацев.

    В ближайший месяц я буду писать о веб-платформе от Microsoft, и в основном это будет касаться администрирования Internet Information Services 7.0 (IIS 7.0), входящего в состав Windows Server 2008. Это не значит, что я не буду писать ни о чем другом – конечно буду, у меня масса планов и тем с барселонского TechEd IT Forum 2008, в основном по направлению Windows Server 2008 R2, просто про администрирование IIS7 буду писать в этот месяц намного чаще и более последовательно, чем я это делал ранее. Поэтому даже те, для кого тема IIS7 не интересна, смогут как минимум раз в неделю находить у меня на блоге что-то интересное по другим тематикам.

    Почему именно IIS 7.0? Здесь несколько причин. Во-первых, в уже упомянутом сборнике документов «шаг за шагом» «Windows Server 2008 Step-by-Step Guides» по странному стечению обстоятельств документа по IIS 7.0 почему-то нет. Во-вторых, как показывает опыт семинаров TechNet в Украине – знания, и даже можно сказать – представления многих админов о технологиях Microsoft для веб базируются на «сказках-страшилках» конца прошлого века, и хотелось бы показать всем желающим простой путь попробовать все технологии самостоятельно, без каких-то предрассудков и прочих ОБС. В-третьих – мне самому, человеку, который достаточно долгий период своей жизни занимался вебом вообще и IIS в частности – а я помню и IIS 2.0, и 3.0, и 4.0 и, конечно же, 5.0 – эта тема близка и интересна, и могу сказать, что за 10 лет в этом направлении Microsoft сделал существенные, даже можно сказать – эпохальные шаги вперед. Потому хотелось бы поделиться и опытом, и знаниями в этой прогрессирующей области с коллегами. В-четвертых – небольшой сюрприз в рамках проводимой в Украине акции для тех, кто разворачивает и управляет веб-серверами под управлением продуктов Microsoft – украинский офис Microsoft проводит акцию, по которой вы можете получить лицензионный Windows Server 2008 Web Edition (коробочная версия) бесплатно для хостинга ваших проектов и сайтов в Интернете. Так что торопитесь получить такой легальный продукт – пишите через блог на почту. И, наконец, в-пятых – в Киеве проводится полигон по веб-технологиям Microsoft, в том числе и IIS 7.0, так что мои статьи послужат хорошим фоном для такого мероприятия.

    Ну, вроде это вcе наиболее веские причины писать в ближайший месяц о IIS 7.0. Кроме одной – зачем вообще админу знание IIS 7.0, который, в принципе, больше является платформой для разработчиков, на которой они делают свои веб-проекты? Проблема в том, что, как показывает опыт, разработчики не очень «напрягаются» созданием архитектуры и проработкой деталей веб-проекта, таких, как безопасность, администрирование, масштабирование и т.п. будущего работаеющего решения. И все это становится головной болью админа. Другая головная боль – это работодатели, которые часто под словом «компьютерщик» понимают, что человек может и спаять сгоревшую плату, и сетку настроить, и программку бухгалтерскую написать. И конечно же – веб сайт родной фирмы «Рога и Ко» сделать – как же без него. А то, что в ИТ отрасли есть глубокая специализация – никого не волнует. И вот потом и пишет мне в Live Messenger такой админ – «Игорь, а что делать?! За что хвататься?!», или если такого «Игоря», который бы подсказал, нет рядом – начинается такое.

    Вроде, мотивы мои всем понятны. получилось довольно длинно, обещаю, сами технические части будут куда короче. Итак.

    Часть 1. Установка IIS 7.0

    Первый вопрос, который мне задают – что такое веб сервер под Windows, что нужно установить? Ответ – вебсервер под Windows – это служба IIS 7.0. Следующий вопрос – где взять IIS 7.0, откуда скачать? Ответ очень простой – IIS 7.0 (как и предыдущие версии, начиная с IIS 5.0) интегрирован в саму серверную ОС Microsoft Windows Server 2008 (а предыдущие версии IIS – соответственно в Windows Server 2003 и Windows 2000) и устанавливается как роль Windows Server. Тогда более тривиальный вопрос – где взять «настоящий» Windows Server 2008? Пробную версию Windows Server 2008 для всех экспериментов и тестирования рекомендую брать только с сайта Microsoft http://www.microsoft.com/windowsserver2008 — проверенная и гарантированно правильная версия (только не забудьте установить все обновления). Серийный номер для Windows Server 2008 не требуется – вы просто при установке в мастере установки оставляете его пустым и на вопрос, хотите ли вы все же его заполнить – гордо отвечаете НЕТ. Фактически, если вы при установке или в ходе эксплуатации таки введете настоящий продуктовый номер – вы получите «настоящую» версию. Версия без введенного серийного номера работает 60 дней, после чего требует активации. Мало кто любит читать иструкции при загрузке файлов, особенно те, которые написаны мелким шрифтом – на самом деле, на странице загрузке есть ссылка на инструкцию, какой скрипт надо запустить, чтобы сбросить счетчик активации Windows снова на 60 дней. Такую операцию надо не забыть сделать до истечения 60дневного срока (например, на 59й день эксплуатации). Всего вы можете посторить операцию сброса счетчика 3 раза – т.е. пробную версию можно эксплуатировать 240 дней, что вполне достаточно с тем, чтобы распробовать плюсы и минусы системы. Ну а для желающих уже сейчас эксплуатировать лицензионный Windows Server 2008 для своих веб-проектов – напоминаю про акцию, пишите.

    Теперь о выборе редакции, которых доступно аж 4 – Datacenter, Enterprise, Standard, Web Edition. Пожалуйста, подходите более ответственно к их выбору. Зачем, ну зачем использовать Enterprise для запуска веб-сайтов – «шоб було?». Для таких задач есть оптимизированная редакция Web Edition. Сравнение возможностей разных редакций можно найти там же, на официальном сайте http://www.microsoft.com/windowsserver2008. Кроме того, некоторые соображения по использованию лицензионных соглашений и виртуализации в разных редакциях я написал на этом блоге ранее.

    После установки экземпляра Windows Server 2008 и его конфигурации (если это также вызывает затруднения – смотрим видео с семинара по Windows Server 2008) переходим непосредственно к установке IIS 7.0. Что нового в IIS 7.0, какие модули включены в него и т.д. – я рассматривать не буду, все теоретические выкладки можно найти в электронной версии журнала TechNet Magazine, которая выходит в том числе и на русском. IIS 7.0 были посвящены 2 статьи в мартовском и июльском номерах журнала. Рекомендую ознакомиться с ними перед практическим применение – знание теории, пусть даже в сжатой форме весьма полезно.

    Основным нововведением в направлении установки различных компонент и служб в Windows Server 2008 является понятие «роли». Роль представляет из себя набор всех необходимых компонент, настроек системы, безопасности и т.п., которые необходимы для выполнения определенной задачи. Кроме того, имеется также информация о взаимодействии ролей между собой – одна роль может работать как подмножество другой и, наоборот – роли могут конфликтовать между собой – об этом администратор будет уведомлен при установке такой роли поверх уже существующих. Установку и конфигурацию всего необходимого система выполняет автоматически при выборе конкретной роли. Такой подход гарантирует, что даже в случае ошибки администратора, связанной с установкой той или иной роли, не требуемой в текущий момент – система будет функционировать нормально и это не затронет работоспособность других ролей. Как впрочем, это также существенно упрощает и сам подход к управлению системой Windows Server 2008 в целом.

    Управление ролями осуществляется через стандартную оснастку управления Windows Server 2008 – Server Manager или в процессе начальной конфигурации сервера через Initial Configuration Tasks.

    IIS 7.0 устанавливается как роль Windows Server 2008. Для этого требуется:

    1. Запустить оснастку Server Manager из меню Start или из панели Quick Launch. Server Manager по умолчанию стартует автоматически при входе администратора в систему. Server Manager является основным инструментом управления сервером Windows Server 2008.

    2. В оснастке на стартовой странице убедиться, что сервер сконфигурирован правильно. Желательно проверить наличие статического IP адреса. Если он не установлен, его можно поменять тут же, из консоли Server Manager, открыв в правой панели по линку «View Network Connections» сетевые интерфейсы.

    3. Выбираем в левой панели Server Manager пункт Roles, в правой панели видим список текущих ролей. В зависимости от редакции ОС и установленных ролей список может варьироваться. В данном примере ни одна роль не установлена.

    4. Для установки новой роли используем в правой панели в разделе «Roles Summary» линк «Add Roles».

    5. Запускается мастер установки ролей «Add Roles Wizard», пропускаем первую страницу «Before You Begin» мастера, нажав кнопку «Next >»

    6. На странице «Select Server Roles» в списке ролей выбираем роль «Web Server (IIS)». Список ролей может отличаться в зависимости от редакции. Данный список соответствует редакции Windows Server 2008 Enterprise Edition x64.

    7. При выборе роли «Web Server (IIS)» мастер автоматически предлагает установить сервисы, которые требуются для функционирования веб сервера. Это службы активации процессов, фактически, они обеспечивают среду исполнения процессов, обслуживающих вебсайты. Соглашаемся с установкой данных служб путем нажатия кнопки «Add Required Features» и нажимаем кнопку «Next >» в мастере.

    8. На странице «Select Role Services» отображается список всех доступных модулей (сервисов), входящих в состав IIS 7.0, представляющих 3 большие группы – Web, Management и FTP – и внутри сгруппированых по назначению – общие модули для поддержки HTTP Common HTTP Features, модули для исполнения сценариев и приложений Application Development, модули управления журналированием и диагностикой Health and Diagnostics, модули обеспечения безопасности Security, производительности Performance, модули управления и совместимости с предыдущей версией IIS 6.0 Management Tools, и, наконец, модули FTP. По умолчанию роль веб сервера IIS 7.0 устанавливается и конфигурируется в минимальном наборе из 9 модулей:

    a. только для работы со статическим HTML контентом (модули из Common HTTP Features),

    b. только с подключением анонимных пользователей и с фильтрацией вредоносных запросов (Security),

    c. с базовыми модулями для журналирования запросов к вебсайтам на сервере и просмотра очереди запросов (Health and Diagnostics),

    d. с модулем сжатия статического контента при передаче страниц клиенту HTTP (Performance),

    e. и консоли администрирования в режиме локального подключения к веб серверу IIS Management Console.

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

    10. При отметке отдельного модуля для добавления, также, как и при выборе роли, мастер автоматически проводит проверку всех связей и зависимостей и предлагает установить дополнительные модули, без которых функционирование выбраного невозможно. В данном примере для установки выбран модуль ASP.NET и мастер автоматически запрашивает разрешение на установку других модулей и служб, необходимых для его работы. Соглашаемся с установкой данных служб и модулей путем нажатия кнопки «Add Required Role Services». По окончанию выбора всех модулей нажимаем кнопку «Next >» в мастере.

    11. На странице «Confirm Installation Selection» отображается для подтверждения информация о всех выбранных модулях, которые будут установлены. Также отображаются служебные и информационные сообщения рекомендательного характера. Например, рекомендация после установки роли IIS 7.0 выполнить обновления ОС или установить Windows System Resource Manager (WSRM), который позволяет обеспечить распределение ресурсов системы при выполнении веб-приложений. Нажатие кнопки «Next >» на этой странице устанавливает весь указанный перечень модулей.

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

    13. После закрытия окна мастера установки роли в левой панели консоли Server Manager в разделе «Roles» среди других ролей появляется подраздел «Web Server (IIS)». В правой панели отображается информация о состоянии всех установленных ролей.

    14. Выбираем подраздел «Web Server (IIS)» в левой панели Server Manager, в правой панели отображается информация о работе роли веб сервера. Здесь представлены:

    a. Events: агрегированный список записей из всех журналов событий ОС за последние 24 часа, имеющих отношение к работе веб служб,

    b. System Services: список всех системных сервисов, обеспечивающих функционирование данной роли и с возможностями по управлению ими и мониторингу их состояний,

    c. Role Services: в данном случае – список всех модулей IIS 7.0 с указанием установлен данный модуль или нет и с возможностями старта мастера установки/удаления модулей данной роли (о котором мы говорили выше),

    d. Resources and Support: наиболее интересный раздел информации о каждой роли, который содержит в себе базу знаний с рекомендациями по дополнительной более тонкой настройке той или иной роли для отдельных сценариев использования. Рекомендуется к широкому использованию.

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

    Илон Маск рекомендует:  Что такое код swf_ortho
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL
    MemCacheSize
    MaxCachedFileSize
    ObjectCacheTTL
    MaxPoolThreads
    ListenBackLog