Asp средства повышения быстродействия iis


Содержание

Увеличение быстродействия IIS

AvnAvn (17.04.2007) Где IIS создает временные файлы при открытии новых сессий ASP?

AvnAvn (17.04.2007) где располагаются сформированные html-коды в результате выполнения ASP — скрипта (желательно, чтобы они были в физической памяти)?

AvnAvn (17.04.2007) Возможно ли как-то оптимизировать работу IIS? . Можно ли как-то заставить ASP в IIS более активно использовать физическую память?

Трактат о производительности MS CRM. Книга III: настройка IIS

На примере IIS 7.x … ��

Обновление КЭШа

Опция Expire (Истечение) управляет кэшем для клиентов, обращающихся к CRM (и не только). По умолчанию, истечение устанвлено в три дня. Любая система (сайт) с довольно статичным информационным контентом или развернутая в глобальной сети с медленными подключениями, может извлечь выгоду из увеличения этого значения, например, до 15 дней.

В результате элементы Microsoft Dynamics CRM будут загружаться во временные файлы и втечении 15 дней не будет проверятся налитчие новых версий.
Откойте менеджер IIS – щелкните по сайту Microsoft Dynamics CRM – в представлении Features View откройте HTTP Response Headers – на панели Actions (прилеплена к правой стороне окна) щелкните по Set Common Headers – и задайте значение для Expire.

Примечание: изменения вступят в силу на клиентских компьютерах после истечения срока текущих настроек.

IIS7 Output Caching

Веб-содержимое может быть разделено на две категории: статическое информационное наполнение и динамическое информационное наполнение. Статическое информационное наполнение не изменяется от запроса к запросу. Примером статического информационного наполнения являются файлы HTML, JPG или GIF.
Динамическое же информационное наполнение изменяется с каждым запросом. Например, ASP.NET или PHP страницы.

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

Возможность IIS 7.0 Output Caching, как раз и предназначается для полудинамического контекта (но также может кэшировать и статический контент). Она позволяет Вам кэшировать отдельные (статические) копии ответов динамических запросов, основываясь на строке запроса.

Что для этого нужно…

  • Откройте IIS, выберите сайт Microsoft Dynamics CRM;
  • В представлении Feature View дважды щелкните по Output Caching;
  • На панели Action, нажмите Edit Feature settings, удостоверьтесь, что и кэш и кэш ядра включены и нажимите OK;Теперь нужно добавить правила кэширования для сайта, которые мы запустим на Корневом уровне.
  • Все еще в корне веб-сайта в разделе Output Caching, нажмите Add и задайте такие параметры:
    • File Name Extension: bmp
    • Поставьте галку: Kernel Mode Caching
    • File Cache Monitoring: Using file change notifications
    • Нажмите OK и добавьте такие же правила кэширования для расширений css, gif, htc, js и png файлов.

    Отключение логов IIS

    Ведение логов IIS занимает ресурсы процессора, дисков и памяти, что не очень позитивно сказвыается на производительности. Поэтому их включение целесообразно только для отладки приложений или устранения каких-либо проблем. Чтобы отключить ведение логов сделайте следующее:
    В IIS Manager выделите сайте CRM – в представлении Feature View дважды щелкните кнопкой по Logging – щелкните по Disable, чтобы отключить логи для сайта.

    HTTP Compression

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

    • Щедкните правой кнопкой мыши по руту в IIS Manager’е — Properties — вкладка Service – далее Вы можете выбрать две опции:
      • Compress application files – включает сжатие динамических страниц, в которые по умолчанию входят asp, dll, и exe.
      • Compress static files – включает сжатие htm, html, и txt файлов (по умолчанию);

    В IIS Manager выделите сайте CRM – в представлении Feature View дважды щелкните кнопкой по Compression – отметьте галками Enable dynamic content compression и/или Enable static content compression для включения динамического (по умолчанию входят файлы asp, dll и exe) и/или статического (по умолчанию входят файлы htm, html и txt) контента сайта.

    Вы можете изменить список типов файлов, включенных в сжатие, откройте на редактирование файл C:\Windows\System32\inetsrv\config\applicationHost.config. Найдите секцию httpCompression и добавьте/удалите типы файлов подлежащие сжатию.

    Напрмер, чтобы включить сжатие файлов Word и Excel, добавьте такие строки в раздел :

    Чтобы изменения вступили в силу, необходимо перезапустить IIS.

    Web gardens (Web-сады)

    В IIS 6.0 Был добавлен новый режим обработки запросов, называемый режимом изоляции рабочих процессов (англ. worker process isolation mode). В этом режиме все веб-приложения, обслуживаемые сервером, работают в разных процессах, что повышает стабильность и безопасность системы. Кроме того, для приёма запросов HTTP был создан новый драйвер http.sys, который работает в режиме ядра, что ускоряет обработку каждого запроса.

    По умолчанию каждому пулу приложений (для обработки запросов) соответствует один рабочий процесс w3wp. Но в IIS 6.0 также появилась такая фишка как Web gardens. Благодаря ей, пул можно настроить так, чтобы ему (для обработки обслуживания запросов) соответствовал набор из N эквивалентных рабочих процессов, разделяющих нагрузку.

    Преимущества Web-садов в том, что, если один рабочий процесс замедляется, например, в случае постоянных долгих операций или, когда подсистема выполнения сценариев перестает отвечать, прием и обработка запросов продолжается остальными рабочими процессами. Единственным недостатком является увеличение потребляемой IIS’ом памяти (пропорцианально количеству процессов).

    Чтобы задействовать Web garden для CRM: В IIS менеджере выделите узел Application Pools — выделите пул CRMAppPool — щелкните Advance Setting — установите в секции Process Model необходимое значение Maximum Worker Process.

    TTL кэша IIS

    IIS кэшируют любые запрошенные объекты. У каждого объекта в пределах кэша есть время «жизни» (TTL) – время, в течение которого объект должен находиться в кэше и из которого IIS его достанет и выдаст, в случаи запроса. Что в результате значительно ускоряет работу веб-сервера. По умолчанию, значение TTL установлено в 30 секунд. Т.е. если объект в кэше не использовался в течение прошлых 30 секунд, то он удаляется.

    И тут у нас опять палка о двух концах: 30 секунд это много или мало? Если все страницы на Вашем сайте являются динамичными, то IIS действительно не извлечет большую выгоду из кэширования. Соответсвенно уменшив этот параметр Вы могли бы освободить память под другие нужды. С другой стороны, если у Вашего сервера много свободной памяти, и куча статичных страниц, то Вы можете улучшить эффективность работы, увеличив TTL.

    Чтобы изменить этот параметр откройте реестр. Далее в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\InetInfo\Parameters добавьте новый DWORD-ключ с именем ObjectCacheTTL и значением от 0 до 4 294 967 295 (это в секундах, где 0 – полное отсутствие кэширования).

    Трассировка и дебаггинг

    Для повышения производительности также можно отключить трассировку и дебаггинг (если они у Вас включены), с помощью конфигурациооных файлов machine.config (расположен в папке .Net Framework’а под которым выполняется пул приложений, например: C:\Windows\Microsoft.NET\Framework\vXXXX\Config\machine.config) и/или Web.config (находится внутри папки сайта CRM):

    Другие параметры

    Документ Optimizing and Maintaining Microsoft Dynamics CRM 4.0 также рекомендует использовать такие параметры для наcтройки IIS:

    Параметр Значение
    maxWorkerThreads 100
    maxIoThreads 100
    maxconnection 12*n (где n это число процессоров)
    minFreeThreads 88*n
    minLocalRequestFreeThreads 76*n
    minWorkerThreads 50

    Настраиваются эти параметры в файле C:\WINDOWS\Microsoft.NET\Framework\vXXXX\CONFIG\machine.config

    Примечание: Еесли у Вас есть hyperthreading, Вы должны использовать число логических центральных процессоров вместо физических. Т.е., если у Вас сервер с четырьмя процессорами, то значение N в формулах будет 8 вместо 4.

    ИТ База знаний

    ShareIT — поделись знаниями!

    Полезно


    Узнать IP — адрес компьютера в интернете

    Онлайн генератор устойчивых паролей

    Онлайн калькулятор подсетей

    Калькулятор инсталляции IP — АТС Asterisk

    Руководство администратора FreePBX на русском языке

    Руководство администратора Cisco UCM/CME на русском языке

    Серверные решения

    Телефония

    FreePBX и Asterisk

    Настройка программных телефонов

    Корпоративные сети

    Похожие статьи

    10 полезных SFTP команд

    Установка MySQL Server на CentOS 7

    Роль Proxy серверов в ИБ

    Что такое API? Простая статья для вашей бабушки

    Apache или IIS – сравнение и преимущества

    Про веб — сервера

    Если вы, или ваша организация намереваетесь создать Web – сервис, будь то сайт или приложение, то так или иначе вы обратите внимание на наиболее популярные на рынке платформы для создания web – серверов – Apache или Internet Information Services (IIS), которые занимают около 70% от всей доли интернета.

    Многие сравнивают противостояние этих двух платформ как соперничество между Microsoft и Linux. В данной статье мы беспристрастно и объективно рассмотрим плюсы и минусы этих платформ.

    Apache

    Apache HTTP web – сервер – полное название платформы, распространяемой организацией Apache Software Foundation как открытое программное решение или проще говоря «open-source». Программное обеспечение сервера распространяется абсолютно бесплатно и его лицензия позволяет конечному пользователю редактировать исходный код, чтобы адаптировать Apache под свои нужды, а так же, внести вклад в будущее развитие серверной платформы.

    Веб – сервер Apache может работать на всех популярных операционных системах, но чаще всего он используется в рамках Linux. Именно в паре с СУБД MySQL и PHP – скриптами образуется известный комплекс программного обеспечения LAMP Web – сервер (Linux, Apache, MySQL, PHP), который повсеместно используется в сети интернет.

    В рамках исследования Netcraft, проводимого в феврале 2014 года, web – сервер Apache занимал 42% рынка. Однако стоит отметить, что в том же июне 2013 года этот показатель составлял 54% и 59% в 2010 году. Это связано с улучшением позиций основного конкурента IIS и ростом позиций Nginx.

    С точки зрения функционала, Apache имеет впечатляющие характеристики. Многие функции реализуются как совместимые модули, расширяющие базовый функционал, диапазон которых варьируется от поддержки языков программирования до обеспечения различных схем аутентификации. Например, это могут быть языки Perl или Python. Модули аутентификации включают в себя элементы управления доступом к различным директориям сервера, пароль, установление подлинности и так далее. Многие другие функции, такие как Secure Sockets Layer (SSL) или TLS (Transport Layer Security) так же обеспечивается модульной системой. Помимо этого, Apache поддерживает возможность развернуть несколько web – сайтов, или графических интерфейсов приложений. Веб – сервер сжимает страницы, чтобы уменьшить их размер, что обеспечивает высокую скорость их загрузки. Наряду с высоким показателем безопасности, это является конкурентной чертой Apache.

    Выделим два основных недостатка Apache HTTP web – сервера:

    • Перенасыщенность функционалом: Еще раз стоит подчеркнуть, что Apache действительно чрезвычайно богат на функции, возможности и инструментарий. Но, к сожалению, в рамках типовой инсталляции пользователь задействует только 10 % от этих функций.
    • С точки зрения архитектуры, Apache, работает по модели «процессов». Это означает, что для каждого соединения Apache выделяет отдельную «коннекцию», или другими словами поток данных, что вызывает значительную загрузку. Конкуренты, а именно асинхронные платформы и сервера работающие по модели «событий», имеют преимущество обработки нескольких процессов одновременно в рамках одной транзакции.

    Internet Information Services (IIS) это веб – сервер разработки компании Microsoft и занимает второе место на рынке вслед за Apache. Платформа IIS будет работать только с Windows и поставляется в комплекте с этой операционной системы. В отличие от Apache, где основную поддержку продукта предоставляет сообщество разработчиков, IIS официально поддерживается компанией Microsoft. Разработка этого продукта не так стремительна по сравнению с Apache, но как было сказано выше, одним из главных конкурентных преимуществ IIS является официальная поддержка компании Microsoft, что очень важно для крупного бизнеса. Многие специалисты в области ИТ признают IIS одним из немногих коммерческих продуктов, который по настоящему может быть конкурентом «open-source» решению.

    Постоянная доработка безопасности, производительности и удобства администрирования позволили увеличить долю присутствия на рынке IIS с 21% в 2010 году до 32% в феврале 2014 (ранее указанное исследование компании Netcraft). Самые большие продвижения были сделаны с точки зрения безопасности. Версия IIS 6.0 была уязвима к атакам: известный вирус Code Red, который заменял содержимое web – сайта на баннер об авторах вируса. Важно отметить, что многие уязвимости проявляются на уровне операционной системы.

    Как и Apache, IIS использует различные расширения для внедрения дополнительного функционала. Например, работа с файлами по FTP, маршрутизация с помощью Application Request Routing (ARR), который позволяет вести балансировку нагрузки и повышать отказоустойчивость, различные медиа – компоненты, аудио, видео, динамическое изменение URL и прочие. Веб – сервер IIS предлагает более высокую совместимость с программной платформой .NET Framework и ASPX (Active Server Pages) чем Apache. Важно, что в IIS поддерживаются такие функции как мониторинг, отслеживание запросов в режиме реального времени. Конечно, IIS можно назвать «условно» бесплатным, так как распространяется он в комплекте с Microsoft Windows Server.

    С точки зрения производительности, IIS уступает Apache, в виду архитектурной особенности и строгой работы на Windows.

    Подведем итог

    И IIS и Apache имеют свои плюсы и минусы. Определиться с web – сервером поможет учет следующих факторов: Сервер IIS должен быть приобретен в комплекте с Windows, Apache не имеет официальной технической поддержки, но имеет высокие показатели безопасности, IIS отлично совместим с .NET и так далее. В таблице ниже приведены некоторые сравнительные характеристики:

    Опция Apache IIS
    Поддерживаемая ОС Windows, Linux, Unix, Mac OS Windows
    Техническая поддержка Сообщество Корпоративная
    Стоимость Полностью бесплатно Покупается в комплекте с Windows
    Разработка «open-source» Проприетарное решение
    Безопасность Хорошо Отлично
    Производительность Хорошо Хорошо
    Рынок 42% 32%
    • WEB сервер Apache
    • IIS
    • 5895
    • 83

    Полезна ли Вам эта статья?

    Пожалуйста, расскажите почему?

    Нам жаль, что статья не была полезна для вас :( Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

    Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации :) Просто оставьте свои данные в форме ниже.

    Asp средства повышения быстродействия iis

    Данные советы вводят в проблему повышения производительности работы приложений, использующих технологии Microsoft Active Server Pages (ASP) и Visual Basic Scripting Edition (VBScript). Большинство из них были многократно обсуждены и c успехом проверены на практике и будут интересны как новичкам в программировании ASP и VBScript, так и тем, кто уже имеет опыт работы с этими технологиями. При подготовке советов был использованы материалы c веб-сайта корпорации Microsoft Corp. (http://www.microsoft.com) и материалы конференций Relib.com (http://www.relib.com)

    Совет 1: Кэшируйте часто используемые данные на сервере

    Типичная ASP-страница получает данные из базы данных и затем выводит их в формате HTML. Независимо от скорости работы вашей базы данных, получение данных из памяти сервера будет намного быстрее, чем обработка sql-запроса к конечной базе данных. Получение данных, сохраненных на локальном жестком диске сервера, также обычно быстрее, чем получение информации из БД. Поэтому одним из основных путей увеличения скорости работы вашей ASP-страницы является кэширование часто используемой информации в памяти или на жестком диске.

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

    Данные, которые изменяются не часто, будут хорошим кандидатом для кэширования, потому что вам не надо будет волноваться относительно их синхронизации через какое-то время с конечной базой данных. Выпадающие списки (сombo-box), таблицы ссылок, пункты меню, и переменные конфигурации сайта (включая имена DSN, адреса IP и URL) — первые кандидаты для хранения в кэше. Заметьте, что вы можете кэшировать представление данных много быстрее, нежели данные сами себя. Если ASP-страница изменяется не так часто и ее временный кэш будет весьма внушительным (например, полный каталог изделий фирмы), попробуйте использовать сгенерированные HTML-страницы, чем каждый раз загружать сервер генерацией ASP-страниц.


    Совет 2: Кэшируйте часто используемые данные в объектах Application или Session

    Объекты Application и Session служат для хранения данных в памяти, значения которых могут быть доступны между несколькими HTTP-запросами (в отличие от обычных переменных, чьи значения доступны только в теле одной ASP-страницы). Данные объекта Session доступны только одному пользователю (в течении его сессии), в то время как данные Application доступны всем пользователям веб-сайта. Поэтому часто перед разработчиком возникает вопрос: в каком из объектов сохранять часто используемые данные. Обычно, для инициализации переменных этих объектов используются процедуры файла Global.asa — Application_OnStart() или Session_OnStart() соответственно. Если в вашем Global.asa еще нет этих процедур, то вы можете добавить их сами или инициализировать переменные, когда это будет необходимо. Примером может быть следующая процедура, использующая Application для хранения значений многократно использующейся переменной EmploymentStatusList. Процедура проверяет существование данных в EmploymentStatusList и при необходимости расчитывает их заново:

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

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

    Совет 3: Кэшируйте данные на диске веб-сервера

    Иногда в памяти вашего веб-сервера может быть слишком большое количество данных. «Слишком много», конечно, является спорным вопросом — это зависит от того, сколько памяти вы хотите использовать, а также число элементов для кэширования и частота, с которой эти элементы будут запрашиваться. В любом случае, если вы имеете слишком большое количество данных для кэширования в памяти, подумайте о переносе кэша в текстовый или XML-файл на жесткий диск веб-сервера. Вы можете одновременно комбинировать кэширование на диске и в памяти, чтобы сформировать оптимальную стратегию для вашего сайта.

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

    ASP и COM обеспечивают несколько инструментальных средств для создания схем кэширования на диске. Функции набора записей ADO Save() и Open() сохраняют и загружают recordset c диска. Используя эти методы вы можете переписать код из прошлого совета, заменяя запись в объект Application на метод Save() для записи в файл.

    Есть несколько других компонентов, которые работают с файлами:

    • Scripting.FileSystemObject позволяет создавать, читать и записывать файл.
    • MSXML, MicrosoftR XML parser поддерживает сохранение и загрузку XML-документов.
    • Объект LookupTable (например, используемый на MSN.com) — лучший выбор для загрузки простых списков с диска.

    Наконец, рассмотрите вопрос принудительного кэширования информации на диске. Сгенерированный HTML-код может быть сохранен на диске как .htm или .asp файл; гиперссылки могут указывать прямо на этот файл. Вы можете автоматизировать процесс генерации HTML, используя коммерческие инструментальные средства типа XBuilder или средства публикации в Интернет, входящие в MicrosoftR SQL ServerT. Кроме того, при помощи директивы #include можно включать отдельные HTML-части в файл ASP или читать HTML-файл с диска используя FileSystemObject. Например, на начальной странице веб-сайта Relib.com (http://www.relib.com/index.asp) приводятся 2 списка последних тем обсуждения двух дискуссионных форумов этого сайта. Отобразить эти списки можно при помощи создания двух наборов записей ADO при каждом обращении к данной странице или, следуя данному совету, сохранить их однажды в виде HTML-файла list.inc, а затем включать в index.asp:

    Второй путь работает значительно быстрее.

    Совет 4: Избегайте кэшировать медленные компоненты в объектах Application или Session

    Несмотря на то, что кэшированиe данных в объектах Application или Session может быть хорошей идеей, кэширование COM-объектов может иметь серьезные ловушки. Занесение наиболее используемых COM-объектов в объекты Application или Session часто соблазняет, но, к сожалению, много COM-объектов, включая все, написанные в Visual Basic 6.0 или ранее, могут вызывать серьезные критические проблемы после сохранения в объектах Application или Session.

    В частности, любой компонент, который выполняется медленно, вызовет критические проблемы когда кэшируется в объектах Session или Application. Быстрый (проворный non-agile) компонент — компонент, помеченный ThreadingModel=Both, который объединен Free-threaded marshaler (FTM), или — компонент, помеченный ThreadingModel=Neutral. (Neutral — новая модель в WindowsR 2000 and COM+). Следующие компоненты не проворны:

    • Free-threaded components.
    • Apartment-threaded components.
    • Single-threaded component.
    • Configured components (библиотека Microsoft Transaction Server (MTS)/COM+ и серверные приложения) не проворны пока они Neutral-threaded. Apartment-threaded components и другие не проворные компоненты хорошо работают в пределах страницы (т.е. создаются и разрушаются в пределах одной ASP-страницы).

    В IIS 4.0 компонент, отмеченный ThreadingModel=Both выполняется быстро. В IIS 5.0 уже не так достаточно. Компонент не должен только быть отмечен как Both, он должен также объединен FTM.

    IIS выполняет проверку компонентов, но если вы хотите ее отменить (т.е. хотите позволить непроворным компонентам быть сохраненными в объектах Application или Session), вы можете установить AspTrackThreadingModel в metabase в значение True. Но это (изменение AspTrackThreadingModel) не рекомендуется.

    IIS 5.0 выдаст сообщение об ошибке, если Вы пытаетесь сохранить непроворный компонент, созданный с использованием Server.CreateObject, в объекте Application. Вы можете обойти это, используя в Global.asa, но это также не рекомендуется, поскольку это ведет к проблемам (очереди и сериализация), объясняемым ниже.

    Что же все-таки неправильно если вы кэшируете непроворные компоненты? Непроворный компонент, кэшируемый в объекте Session блокирует Session от других рабочих потоков (thread) ASP. ASP обслуживает пул (контейнер) рабочих потоков, запрашиваемых другими сервисами. Обычно, новый запрос обрабатывается первым доступным потоком. Если Session блокирована, то запрос должен ждать поток, когда он станет доступным. Проведем аналогию, которая поможет понять эту ситуацию: вы идете в магазин, выбираете несколько булок, и платите за них в кассе #3. Всякий раз, после того как вы выбрали булки в том магазине, вы всегда оплачиваете их в кассе #3, даже в том случае, когда в других кассах короче очередь или даже вообще нет покупателей.

    Сохранение непроворных компонентов в объект Application накладывает столь же негативный эффект на производительность. ASP создает специальный поток для выполнения меделенных компонентов в пределах Application. Это имеет два последствия: все запросы выстраиваются в очередь к этому потоку и все запросы сериализуются. Выстраивание в очередь означает, что параметры были сохранены в общедоступной области памяти; запросы переключаются к специальному потоку; метод компонента выполнен; результаты выстраиваются в общедоступную область. Сериализация (преобразование в последовательную форму) означает, что все методы выполняются в одно время. Для двух различных потоков ASP не возможно одновременное выполнение методов общедоступного компонента. Это уничтожает многопотоковость (параллелизм), особенно на мультипроцессорных системах. Хуже всего то, что все непроворные компоненты в пределах Application совместно используют один поток («Host STA»), так что негативные результаты сериализации налицо.

    Смущены? Есть некоторые общие правила. Если Вы пишете объекты в Visual Basic (6.0 или ранее), не храните их в объектах Application или Session. Если вы не знаете потоковую модель объекта, не храните его в кэше. Вместо кэширования где-либо непроворных объектов, вы должны создать и удалить их на каждой странице. Объекты выполнятся непосредственно в рабочем потоке ASP и не будет никакой очереди или сериализации. Производимость будет адекватна, если COM-объекты запущены под IIS и если они не используют много времени, чтобы инициализироваться и уничтожаться. Заметьте, что однопотоковые (single-threaded) объекты не должны использоваться этот путь. Будьте внимательным — VB может создавать однопотоковые объекты! Если вы используете однопотоковые объекты, этот путь (типа таблицы Microsoft Excel) не рассчитывает на высокую производительность.

    Наборы записей (recordset) ADO могут безопасно кэшироваться когда ADO отмечен как Free-threaded. Чтобы сделать ADO как Free-threaded используйте файл Makfre15.bat, который обычно зафиксирован в каталоге \\Program Files\Common Files\System\ADO.

    Предупреждение: ADO не должен быть Free-threaded, если вы используете Microsoft Access в качестве БД. Набор записей ADO должен быть также вообще отсоединен, если вы не можете управлять конфигурацией ADO на вашем веб-сайте.

    Совет 5: Не кэшируйте соединение БД в объектах Application или Session

    Кэширование соединений ADO — обычно является плохой стратегией при разработке ASP-сайта. Если один объект Connection сохранен в объекте Application и используется на всех страницах, то все страницы будут бороться за использование этого соединения. Если объект Connection сохранен в ASP-объекте Session, то соединение БД будет создано для каждого пользователя. Это создает излишнюю загрузку веб-сервера и БД.

    Вместо кэширования соединений БД, создавайте и уничтожайте объекты ADO на каждой ASP странице, которая использует ADO. Это эффективно, потому что IIS имеет встроенное подключение БД. Более точно, IIS автоматически допускает объединение подключений OLEDB и ODBC. Это гарантирует, что создание и уничтожение связей на каждой странице будут эффективны.

    Так как соединенные наборы хранят ссылки на подключение БД, это следует, что вы должны не кэшировать соединенные наборы в объектах Application или Session. Однако, вы можете безопасно кэшировать отсоединенные наборы, которые не держат ссылку на подключение. Чтобы отсоединить набор записей, сделайте следующие два шага:

    Совет 6: Разумное использование объекта Session

    Теперь, когда в предыдущих советах были раскрыты достоинства кэширования данных в объектах Applications и Sessions, вам предлагается пытаться избегать использования объекта Session. Сессии имеют несколько ловушек когда используются на загруженных сайтах. Под «загруженными» имеются ввиду сайты с сотнями запрашиваемых страниц в секунду или тысячами пользователей одновременно. Этот совет также важен для сайтов, которые должны масштабироваться горизонтально — т.е. те сайты, которые используют несколько серверов для распределения нагрузки и обеспечения отказоустойчивости при сбоях. Для меньших сайтов, типа intranet-сайтов, преимущества применения Sessions все же перевешивают.

    Обобщая, ASP автоматически создает Session для каждого пользователя, который обращается к веб-серверу. Каждая сессия занимает приблизительно 10 Кб памяти (сверх любых данных, сохраненных в Session) и немного замедляет выполнение всех запросов. Сессия остается действующей до окончания таймаута (timeout), обычно 20 мин.

    Но самая большая проблема при использовании сессий — это не производительность, а расширяемость. Сессии не охватывают все задействованные веб-сервера; как только Session была создана на одном сервере ее данные остаются там. Это означает, что если вы используете сессии на мультисерверном веб-сайте, вы должны придумать стратегию для обработки запросов каждого пользователя, которые должны быть всегда направлены на сервер, на котором существует сессия этого пользователя. Это называется «застреванием» пользователя на сервере (или «липкой сессией»).

    Объект Application также не охватывает все сервера: если вам нужно совместно использовать и обновлять данные Application через веб-сервера, вам нужно использовать конечную базу данных. Однако неизменяемые (read-only) данные Application все же полезны на мультисерверных сайтах.

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

    Если же вы не используете Session, то убедитесь, что отключили их. Это можно сделать посредством Internet Services Manager (см. документацию по ISM). Но если вам все-таки необходимо использовать сессии, то есть несколько путей уменьшить их удары про производительности.

    Вы можете переместить содержимое, которое не требует сессий (например, страницы help и т.д.) в отдельное ASP-приложение, у которого сессии выключены. Кроме того, на страницах, где объект Session не используется, применяйте следующую директиву, помещещаемую вверху страницы:

    Одна из основных причин ее применения — то, что Session создает интересную проблему в случае использования фрэймов (frameset). ASP гарантирует, что в любое время будет выполняться только один запрос от Session. Это делается для того, чтобы при одновременном запросе одним пользователем нескольких страниц, только один ASP-запрос был обработан сессией, что помогает избежать проблем многопоточного доступа к объекту Session. К сожалению, в результате этого все страницы в frameset будут загружаться последовательно, а не одновременно, и пользователю придется продолжительное время ждать полной загрузки. Мораль этой истории: если вы не уверены, что с использованием фрэймов и Session ваше приложение правильно работает, то используйте:

    Альтернативой использованию объекта Session являются многочисленные параметры управления Session. При передаче малых объемов данных (менее 4 Кб) обычно рекомендуется использовать Cookies, переменные QueryString и скрытые (h >Если в вашем приложении используется много функций VBScript или JScript, то зачастую производительность можно улучшить поместив этот код в откомпилированный COM-объект. Обычно откомпилированная программа выполняется значительно быстрее, чем интерпретируемый код, поэтому откомпилированные COM-объекты будут работать более эффективно, чем вызываемые методы скрипта.

    Выделение (инкапсуляция) кода в COM-объект имеет следующие преимущества (не считая производительности):

    • COM-объекты хороши для логического представления структуры приложения.
    • COM-объекты позволяют многократное использование одного кода.
    • Много разработчиков находят код, написанный в VB, C++ или Visual J++ проще в отладке, чем ASP.

    Но наряду с, казалось бы, неоспоримыми достоинствами COM-объекты имеют и недостатки, среди которых — время разработки и потребность в различных навыках программирования. Будьте уверены, что инкапсуляция в малых ASP-приложениях может вызвать скорее убытки, чем прибыль. Обычно это случается, когда маленькое количество ASP-кода переносится в объект COM. В этом случае накладные расходы от создания и вызова этого объекта перевешивают выгоду от использования интерпретируемой программы. Определить наиболее выигрышную комбинацию для производительности — использование сценариев ASP или COM-объектов — можно только методом проб и ошибок. Заметим, что Microsoft значительно улучшила ASP-сценарии и производительность ADO в Windows 2000/IIS 5.0 по сравнению с Windows NT 4.0/IIS 4.0. Таким образом, преимущество откомпилированного кода над кодом ASP уменьшилось с введением IIS 5.0 и ваше приложение должно работать быстрее, по сравнению с четвертой версией IIS.

    Совет 8: Объявляйте переменные поздно, а удаляйте рано

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

    Соединения (Connection) ADO и рекордсеты — первостепенные кандидаты для этой оптимизации. Использовав recordset или сonnection для отображения данных сразу же удаляйте эти переменные из памяти, не дожидаясь конца страницы. Не позволяйте рекордсету или соединению остаться незакрытыми.

    Например, если вы создаете соединение и открываете набор записей следующим образом:

    то закройте их вот так:

    Любые другие переменные Microsoft VBScript также лучше устанавливать в Nothing.


    Совет 9: Out-of-process как компромисс между производительностью и надежностью

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

    Работа ASP-приложений может быть сконфигурирована одним из трех путей. В IIS 5.0 введен термин «уровень изоляции» (isolation level), описывающий эти пути, и который делится на три уровня — Low (низкий), Medium (средний), и High (высокий):

    Low Isolation. Поддерживается во всех версиях IIS и самый быстрый. Он выполняет ASP в Inetinfo.exe, который является первичным процессом IIS. Если ASP-приложение дает сбой, то нагрузка ложится на IIS. (Чтобы перезапутить IIS под IIS 4.0 вебмастер должен был вести мониторинг сайта, используя инструменты типа InetMon, и рестартовать его командным файлом, если на сервере произошел сбой. В IIS 5.0 введена более надежная функция рестарта, которая автоматически перезапускает сервер в случае сбоя.)

    Medium Isolation. Этот новый уровень, впервые введенный в IIS 5.0, называют out-of-process, т.к. ASP выполняется вне процесса IIS. В Medium Isolation все приложения ASP сконфигурированы для выполнения как среднеразделенный процесс. Это уменьшает число процессов, требуемых для загрузки нескольких ASP-приложений out-of-process. В IIS 5.0 уровень Medium Isolation установлен по-умолчанию.

    High Isolation. Поддерживающийся в IIS 4.0 и IIS 5.0 уровень High Isolation также выполняется out-of-process. Если в ASP произошел сбой, то с веб-сервером ничего не случится — ASP-приложение автоматически перезапускается со следующим запросом ASP. В High Isolation, каждое ASP-приложение сконфигурировано для выполнения в собственном участке памяти, что защищает приложения ASP от друг друга (отсюда и название — «высокая изоляция»). Недостаток этого — требование раздельных процессов для каждого ASP-приложения.

    Вы спросите, который уровнь лучше? В IIS 4.0 выполнение out-of-process сказывалось довольно негативно на производительности. В IIS 5.0 было проделано много работы для уменьшения последствий от запущенных out-of-process ASP-приложений. Фактически в большинстве испытаний ASP-приложения, запущенные out-of-process под IIS 5.0, выполняются быстрее, чем под IIS 4.0. Независимо от этого, Low Isolation все еще предоставляет лучшую производительность на обеих платформах. Однако, вы не увидите большой выгоды от Low Isolation, если ваш веб-сервер имеет низкую нагрузку. Поэтому, вам не стоит устанавливать этот уровень, до тех пор, пока ваш сервер не будет выполнять запросы в сотни или даже тысячи страниц в секунду. Как всегда, испытание с различными конфигурациями и определяет наиболее лучший выбор.

    Заметим, что когда вы выполняете ASP-приложения out-of-process (уровни Medium или High), они выполняются в MTS под NT4 и COM+ под Windows 2000. Т.е. под NT4 они выполняются в Mtx.exe, а под Windows 2000 они выполняются в DllHost.exe. Вы можете увидеть эти процессы запустив Администратор Задач (Task Manager). Вы можете также увидеть как IIS компонует пакеты MTS или приложения COM+ для out-of-process приложений ASP.

    Компоненты COM также имеют три параметра конфигурации, хотя они и не полностью аналогичны параметрам настройки ASP. Компоненты COM могут быть: «неконфигурированными» (unconfigured), настроенными как библиотечные или серверные приложения. «Неконфигурированные» — т.е. компонент не зарегистрирован с COM+. Такой компонент будет выполниться в памяти вызывающего процесса, т.е. «in-process» («в процессе»). Библиотечные приложения (Library Applications) также выполняются in-process, но имеют выгоду от сервисов COM+, включая защиту, транзакции и контекстную поддержку. Серверные приложения выполняются в собственной памяти процесса.

    Вы сможете увидеть весьма небольшую выгоду неконфигурированных компонентов над библиотечными приложениями. И, вероятно, большую производительность библиотечных приложений над серверными. Это все потому, что библиотечные приложения выполняются в том же самом процессе, что и ASP, в то время как серверные приложения выполняются в их собственном процессе — межпроцессорные запросы более трудоемки, чем работа в in-process (например, при обмене данными recordset между процессами, все данные должны быть скопированы из одного процесса в другой).

    Так что же все-таки использовать?

    Если вам требуются конфигурации с разумными долями реализации производительности и надежности, то советуем вам следующее: под IIS 4.0 используйте Low Isolation level и MTS Server Packages, под IIS 5.0 используйте Medium Isolation level и COM+ Library Applications. Но учтите, что данный совет — очень общая рекомендация. Например, хостинговые компании обычно устанавливают Medium или High Isolation level, тогда как множество веб-серверов могут работать в Low Isolation. Так что, лучше всего попробовать самому и решить, которая конфигурация непосредственно для вас наилучшим образом выполняет ваши потребности.

    Совет 10: Используйте директиву Option Explicit

    Используйте директиву Option Explicit в ваших .asp файлах. Расположенная в самом верху .asp файла, она заставляет разработчика объявлять все переменные, которые он использует. Многие программисты считают, что это позволяет быстрее отлаживать приложения, исключая, таким образом, ошибки в написании имен переменных и невнимательное создание новых переменных (например, MyXLMString=. вместо MyXMLString=).

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

    Таким образом, использование директивы Option Explicit гарантирует, что все используемые переменные объявлены и доступ к ним будет максимально быстрым.

    Совет 11: Используйте локальные переменные в подпрограммах и функциях

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

    Совет 12: Копируйте частоиспользуемые данные в переменные

    При вызове COM в ASP, вы должны копировать частоиспользуемые данные объекта в переменные ASP-скрипта. Это сократит количество запросов методов COM, которые являются относительно трудоемкими по сравнению с обращением к переменным самого скрипта. При вызове объектов Collection и Dictionary этот совет также сокращает время запросов.

    Вообще, если вы пользуетесь объектом данных больше, чем однажды, поместите данные в переменную ASP-скрипта. Главной целью этой оптимизации являются переменные объекта Request (Form и QueryString). Например, на вашем веб-сайте через QueryString передается переменная UserID. Предположите, что этот UserID упомянут дюжину раз на каждой странице. Вместо вызова Request(«UserID») 12 раз, поместите этот UserID в какую-либо переменную наверху ASP страницы и затем используйте эту переменную (а не Request) внутри страницы. Это упразднит 11 COM-запросов!

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

    Когда этот код выполняется, происходит следущее:

    1. Переменная Foo получена как глобальный объект.
    2. Переменная bar получена как член Foo. Это оказывается запросом COM-метода.
    3. Переменная blah получена как член Foo.bar. Это также оказывается запросом COM-метода.
    4. Переменная qaz получена как член foo.bar.blah. Да, это также оказывается запросом COM-метода.
    5. Вызовите Foo.bar.blah.quaz(1). Еще один запрос COM-метода. Представляете?
    6. Сделайте шаги от 1 до 3 снова, чтобы получить baz. Система не знает, изменил запрос к qaz модель объекта, так что шаги 1 до 3 должны быть выполнены снова, чтобы получить baz.
    7. Получите baz как член Foo.bar.blah.
    8. Сделайте шаги от 1 до 3 снова и получите zaq.
    9. Сделайте шаги от 1 до 3 уже в другой раз и получите abc.

    Как видите это ужасно неэффективно (и медленно). Быстрый способ — написать этот код в VBScript: ,pre> Set myobj = Foo.bar.blah ‘Объявляем blah однажды! Myobj.baz = myobj.qaz(1) If Myobj.zaq = Myobj.abc Then ‘.

    Если вы используете VBScript 5.0, то можете использовать выражение With:

    Совет 13: Избегайте использования переопределяемых массивов

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

    Пример ниже показывает использование беспричинного использования Dim и Redim.

    Есть ли в этом смысл? Гораздо было бы лучше использовать для инициализации массива изначально известный размер (в этом случае 5), чем каждый раз переопределять его. Определяя массив сразу вы будете тратить впустую небольшое количество памяти (если не все элементы массива используются), но выгодой будет скорость работы вашего скрипта.

    Совет 14: Используйте буферизацию Response

    Вы можете буферизировать целую страницу, включив «response buffering». Это минимизирует количество записей в браузер и, таким образом, улучшит производительность. Каждая запись имеет много непроизводительных издержек (и в самом IIS и в том количестве данных, посланных по проводам), так что меньшее количество записей будет лучше. TCP/IP работает намного более эффективно когда возможно посылать несколько больших блоков данных, чем при пересылке многочисленных маленьких блоков (из-за медленного начала процесса пересылки и сложных алгоритмов проверки).

    Есть два пути использования «response buffering». Первый путь — вы можете включить response buffering для приложения, взятого в целом, используя Internet Services Manager. Это рекомендуемый подход, поэтому response buffering включен по-умолчанию для новых ASP-приложений в IIS 4.0 и IIS 5.0. Второй путь — вы можете активировать буферизацию, поместив следующую линию кода вверху ASP-страницы:

    Эта линия кода должна быть выполнена прежде, чем любые данные response был записаны в браузер (т.е. прежде, чем появится любой код HTML в ASP-скрипте и прежде, чем были установлены любые Cookies, используя Response.Cookies). Вообще, лучше включить response buffering, как указано в первом случае. Это позволит вам избежать применения вышеупомянутой линии кода в каждой странице.

    Есть только одна общая проблема относительно буферизации Response — то, что пользователи чувствуют ASP-страницы менее «отзывчивыми» (даже при том, что время полного получения готовой страницы получается меньше) потому что они должны ждать полную страницу, которая будет произведена прежде, чем, они начинают видеть что-нибудь. Для длинных страниц, вы можете выключить буферизацию, установив Response.Buffer = False. Однако, лучшей стратегией будет использование метода Response.Flush. Этот метод показывает весь HTML, который был записан ASP в браузер. Например, после записи 100 строк из таблицы с 1000-ю записей, ASP может вызывать Response.Flush, чтобы вынудить показать браузер уже готовые 100 строк; это позволяет пользователю увидеть первые 100 строк таблицы прежде, чем остальные строки будут будут получены.

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

    . Так что проверьте ваш браузер на этот счет. Чтобы обойти эту проблему, попробуйте разделить таблицу на несколько более меньших таблиц (с меньшим количеством строк) и вызывать Response.Flush после каждой из них. Новые версии Internet Explorer отображают таблицы прежде, чем они полностью закончены и будут показывать их еще быстрее, если вы определите ширину столбцов таблицы — это поможет избежать расчетов, которые требуются браузеру для самостоятельного вычисления ширины столбцов путем измерения длины строк данных в каждой ячейке таблицы.

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

    Совет 15: Группируйте однолинейный код и выражения Response.Write

    Однолинейная конструкция VBScript записывает значение «выражения» в исходящий ASP-поток. Если буферизация response не включена (см. Совет 14), то при частом использовании таких выражений, каждое из них приведет к записи данных в браузер путем передачи по сети множества маленьких пакетов, что выполняется медленно. Точно также производительность приложения снижается при частом чередовании маленьких кусочков ASP-кода и HTML. Поэтому данный совет состоит в следующем: замените рядом стоящие однолинейные конструкции одним вызовом Response.Write. Например, в следующем примере отображения таблицы БД показано необоснованно частое переключение в каждой строке между однолинейным кодом VBScript и тэгами HTML:

    Ниже приводится более эффективный код, содержащийся в едином блоке VBScript и призванный ускорить отображение данных:

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

    Совет 16: Используйте Response.IsClientConnected перед получением больших объемов данных

    Если пользователь нетерпелив и торопится, он может отказаться от вашей просмотра ASP-страницы прежде, чем вы начнете выполнять его запрос. Если он нажал в браузере Refresh или ушел на другую страницу вашего сервера, вы получите новый запрос, стоящий в конце очереди ASP-запросов и «отсоединенный» запрос, стоящий в середине очереди. Часто это случается когда ваш сервер сильно загружен (имеет длинную очередь запросов с, соответственно, большим временем ответа) и этот новый запрос делает ситуацию еще хуже. Нет никакого смысла выполнять ASP-скрипт (особенно медленный и тяжеловесный), если пользователь больше не соединен со своим запросом. Вы можете проверить это состояние, используя свойство Response.IsClientConnected. Если оно возвращает False вы должны вызвать Response.End и отказаться от получения остальной части страницы. Фактически, IIS 5.0 использует эту практику — всякий раз, когда ASP собирается выполнять новый запрос, он проверяет, чтобы увидеть как долго запрос был в очереди. Если он был там более, чем 3 секунд, ASP проверит, соединен ли все еще клиент и немедленно закончит запрос, если нет. Вы можете использовать AspQueueConnectionTestTime, чтобы установить этот таймаут в 3 секунды.

    Если вы имеете страницу, которая требует очень много времени для выполнения, вы можете проверять Response.IsClientConnected на разных стадиях выполнения. Когда буферизация активирована — хорошая идея также вызывать Response.Flush, чтобы дать понять пользователю, что что-что работает.

    Обратите внимание, что в IIS 4.0 Response.IsClientConnected не будет правильно работать, если вы сначала не делаете Response.Write. Если буферизация активирована вы будете также должны делать Response.Flush. На IIS 5.0 нет никакой потребности в этом — Response.IsClientConnected работает прекрасно. В любом случае Response.IsClientConnected требует некоторых затрат времени, поэтому используйте ее только перед действием, которое требует, скажем, по крайней мере, не менее 500 миллисекунд (это большой промежуток времени, если у вас большая нагрузка на сервер). Т.е. вы должны отдавать себе отчет в действиях и не вызывать Response.IsClientConnected перед выводом каждой строки таблицы БД, гораздо лучше будет, если такая проверка будет реже, возможно, перед выводом новых 20-ти или 50-ти строк.

    Совет 17: Объявляйте объекты используя тег

    Если вам нужно обращаться к объектам, которые затем могут быть не использованы в коде (особенно объекты, содержащиеся в объектах Server или Application), попробуйте объявлять их в global.asa используя следующий синтакс:


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

    Совет 18: Используйте объявления TypeLib для ADO и других компонентов

    При использовании ADO разработчики часто включают adovbs.txt чтобы получить доступ к различным константам ADO. Этот файл должен быть включен в каждую страницу, в которой нужно использовать эти константы. Но этот файл констант достаточно большой и увеличивает время трансляции каждой ASP-страницы и размер скрипта.

    В IIS 5.0 введена способность связать с библиотекой типов компонента, которая позволяет вам один раз сослаться на библиотеку типов и использовать ее на каждой ASP-странице. Причем в каждой странице не надо будет компилировать файл констант и разработчикам компонентов не надо формировать файлы VBScript #include для использования в ASP.

    Чтобы обращаться к ADO TypeLib разместите одно из следующих выражений в Global.asa:

    Совет 19: Пользуйтесь преимуществами клиентской проверки правильности данных

    Современные браузеры имеют широко развитую поддержку XML, DHTML, java-апплетов и Remote Data Service. Пользуйтесь преимуществами этих возможностей всякий раз, когда можете. Все эти технологии помогают сократить на запросах к серверу и обратно, выполняя клиентскую проверку правильности ввода данных (например, проверку, имеет ли кредитная карта правильную контрольную сумму и т.п.). Сократив на обращениях клиент-сервер, вы снимите дополнительную нагрузку с сервера, тем самым — сократите сетевой траффик (хотя начальная страница, посланная браузеру, скорее всего будет большей), а также снизите нагрузку с любых других конечных ресурсов, к которым обращается ваш север (базы данных и пр.). Кроме того, пользователю не надо будет ждать новую страницу с сообщением об ошибке и предложением вернуться назад. Однако все это не означает, что вам надо просто перенести всю вашу проверку с сервера на клиента, нет. Вы должны всегда делать проверку вводимых данных на сервере, потому что она поможет защитить против хакеров или браузеров, которые не поддерживают ваши клиентские процедуры проверки.

    Много было сделано для создания HTML, «независимого от браузера». Это часто препятствует разработчику при извлечении выгоды от популярных особенностей браузеров, которые могли бы приносить пользу. Для высокопроизводительных веб-сайтов, которые беспокоятся о «досягаемости» для браузеров, хорошей стратегией будет оптимизация страниц под наиболее популярные программы просмотра. Особенности браузера могут быть легко обнаружены в ASP используя Browser Capabilities Component («компонент возможностей браузера»). Инструментальные средства типа Microsoft FrontPage могут помочь вам при проектировании кода, который будет работать с теми браузерами и версиями HTML, которые вы хотите.

    Совет 20: Избегайте конкатенации строк в циклах

    Множество программистов делают образование строк в циклах следующим образом:

    В таком подходе есть несколько проблем. Во-первых, неоднократная конкатенация (соединение) строк берет квадратичное время или если сказать менее формально, то — время, которое потребуется на выполнение цикла, пропорционально квадрату количества записей к числу полей. Более простой пример сделает это более понятным.

    На первом шаге цикла вы получаете одиносимвольную строку «A». Во второй раз VBScript должен перераспределить строку и скопировать два символа («AB») в s. На третьем шаге нужно перераспределить s снова и скопировать три символа в s. На шаге N (26), нужно перераспределить и скопировать N символов в s. Итого — общее количество 1+2+3+. +N, т.е. N*(N+1)/2 копирований.

    Если предположить, что в первом примере было 100 записей и 5 полей, то внутренний цикл будут выполнен 100*5 = 500 раз и время, которое потребуется для копирования и перераспределения строк будет пропорционально 500*500 = 250000, что будет довольно много для копирования набора записей скромных размеров.

    В этом примере код мог бы быть улучшен заменой конкатенации строк с Response.Write() или однолинейным скриптом ( ). Если буферизация response включена (как это должно быть), это будет быстро, как Response.Write только добавляет данные к концу буфера response. Никакое перераспределение не выполняется и это очень эффективно.

    В отдельных случаях преобразования ADO-рекордсета в HTML-таблицу можно попробовать использование GetRows или GetString.

    Если вы соединяете строки в JScript, то там строго рекомендуется использование оператора «+=»; т.е. используйте s += «строка», а не s = s + «строка».

    Совет 21: Используйте кэширование страниц в браузере и proxy-сервере

    По умолчанию в ASP отключено кэширование в веб-браузере и proxy. Смысл этого заключается в том, что ASP-страница — по своей природе динамическая и обычно содержит информацию, которая изменяется со временем. Если ваша страница содержит постоянные данные и не требует регенерации при каждом запросе, то вы должны включить кэширование для браузера и прокси. Это позволит браузерам использовать «кэшируемую» копию страницы в течение некоторого отрезка времени, которым вы можете управлять. Кэширование может значительно снизить нагрузку на вашем сервере.

    Какие из динамических страниц могут быть кандидатами на кэширование? Вот некоторые примеры:

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

    Заметьте, что с кэшированием в браузере или кэшированием proxy, вы получите меньшее количество хитов, зарегистрированных на вашем сервере. Поэтому, если вы хотите точно измерять количество просмотров страниц или количество показов баннеров, то скорее, всего вы не захотите воспользоваться кэшированием.

    Кэширование в браузере управляется свойством «Expires» HTTP-запроса, который посылает веб-сервер браузеру. ASP обеспечивает два простых механизма, чтобы установить это свойство. Чтобы заставить страницу «устареть» через несколько минут — установите свойство Response.Expires. Следующий пример сообщает браузеру, что содержание данной страницы истекает через 10 минут:

    Установка Response.Expires в отрицательное значение или 0 отключает кэширование. Использование большого отрицательного числа, например -1000 (немного больше, чем 1 день) будет лучше, в силу несоответствий между временем на сервере и в браузере. Второе свойство Response.ExpiresAbsolute позволяет вам устанавливать точное время, в течении которого содержание «устареет»:

    Вместо использования объекта Response для того, чтобы установить истечение срока действия страницы, вы можете использовать HTML-тэг . Большинство браузеров «понимают» эту директиву, хотя proxy ее не используют.

    Наконец, вы можете указывать является ли содержание допустимым для кэширования HTTP-proxy используя свойство Response.CacheControl. Установив это свойство в значение «Public» вы разрешите proxy кэшировать содержание страницы.

    По умолчанию это свойство всегда установлено в «Private». Обратите внимание, что вы не должны разрешать кэширование для proxy страниц, которые показывают данные, специфичные для каждого пользователя, поскольку в этом случае proxy может показывать страницы пользователям с информацией других.

    Совет 22: Используйте Server.Transfer вместо Response.Redirect

    Метод Response.Redirect сообщает браузеру запросить другую страницу. Этот метод часто используется, чтобы переназначить запрос пользователя, например, к странице идентификации (login) или странице с сообщением об ошибке. Redirect вынуждает сделать новый запрос страницы, результат этого — то, что браузер должен сделать два запроса к веб-серверу и веб-сервер должен обработать дополнительный запрос. В новой версии IIS 5.0 введена новая функция Server.Transfer, которая передает выполнение другой ASP-странице на том же самом сервере. Это помогает избежать дополнительного запроса «браузер-сервер» и в общем и целом приводит к улучшению производительности системы, а также к более короткому времени редиректа и отображения страницы в браузере пользователя.

    Следующий скрипт демонстрирует использование Server.Transfer для переназначения запроса в зависимости от значения переменной:

    Server.Transfer посылает запрос из одного выполняемого ASP-файла к другому файлу. В течении редиректа выполнение первоначально запрошенного ASP-файла немедленно прекращается без очистки буфера вывода.

    Совет 23: Используйте замыкающий слэш в URL каталогов

    Этот совет относится не только к ASP-программистам, но и ко всем веб-разработчикам, кто в своей работе создает html-страницы.

    Проверьте, всегда ли вы используете замыкающий слэш (trailing slash) — наклонную черту вправо (/) в URL каталогов веб-сайта. Если опустить этот слэш браузер будет делать запрос к серверу, только для того, чтобы сообщить, что он спрашивает о каталоге. Затем браузер будет делать второй запрос, но уже со слэшем на конце URL, и только тогда веб-сервер будет возвращать «главный» (default) документ этого каталога или выдавать список файлов каталога, если в нем нет главного документа и разрешен просмотр каталога. Добавление к URL замыкающего слэша позволяет избежать первого бесполезного запроса к веб-серверу, что, естественно, экономит время, которое требуется для перехода по ссылке. Чтобы подобная ссылка выглядела более приятнее вы можете опустить слэш в названии URL.

    Этот совет также относится и к записи ссылок на главную страницу веб-сайта. Используйте

    Совет 24: Избегайте использования серверных переменных

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

    Также пытайтесь избегать неопределенных вызовов объекта Request (например, Request(«Данные»)). Для элементов, находящихся не в Request.Cookies, Request.Form, Request.QueryString или Request.ClientCertificate, имеется неявный запрос к Request.ServerVariables. Запрос к коллекции Request.ServerVariablesе выполняется намного медленнее, чем доступ к другим коллекциям.

    Совет 25: Сделайте upgrade системного программного обеспечения

    Системные компоненты постоянно обновляются, поэтому рекомендуется, чтобы вы модернизировали (сделали upgrade) к самой последней версии. Лучше всего установить Windows 2000 (и следовательно, IIS 5.0, ADO 2.5, MSXML 2.5, Internet Explorer 5.0, VBScript 5.1 и JScript 5.1). IIS 5.0 и ADO 2.5 позволяют достичь значительного повышения производительности ваших приложений на мультипроцессорных системах. На серверах под управлением ОС Windows 2000 ASP может респределять нагрузку одновременно на четыре процессора и больше, принимая во внимание, что в предыдущей версии — под IIS 4.0, ASP не делал такого распределения и на два процессора. Насколько много вы используете скриптового кода и ADO в ASP-страницах вашего сайта, настолько больше повышения производительности вы должны увидеть после модернизации к Windows 2000.

    Если вы не можете установить Windows 2000 сейчас, вы можете модернизировать ваше системное программное обеспечение к самым последним версиям SQL Server, ADO, VBScript и JScript, MSXML, Internet Explorer и пакета обновления NT 4 (Service Pack). Каждое из перечисленного позволяет улучшить выполнение работы и увеличить надежность.

    Как повысить производительность запуска в IIS / ASP.Net

    Я использую особенно медленный виртуальный веб-хост (имя удерживается!), где производительность диска может быть очень плохо. Таким образом, первый удар по моему ASP.Net загрузка веб-сайтов может занять 1 + минут. (После начальной загрузки все в ОЗУ и в порядке.)

    Мне интересно, знает ли кто-нибудь способ поручить IIS предварительно загрузить сайт? Является ли essence подражать первому удару?

    Я играл со всем барахлом предварительной компиляции, это помогает, Но это не является заменой для выше.

    5 ответов

    требуется ли утилизация вашего приложения? Все параметры рециркуляции находятся в конфигурации IIS и могут быть скорректированы в соответствии с приложением.

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


    Если требуется ежедневная переработка, согласно предыдущему ответу, a пакетный файл может использоваться для перезапуска приложения, а также может вызывать iexplore.exe с URL-адресом приложения для «предварительной загрузки».

    Почему у вас не может быть пакетного файла с сбросом iis и расписанием его выполнения каждый день в определенное время (когда у вас нет пользователей в вашей системе)?

    Если ваш провайдер может иметь способ для вас, чтобы подключиться, когда они перезагружают веб-сервер, вы можете иметь пакетный файл / файл сценария удара ваш сайт после перезагрузки веб-сервера. Вам нужно только ударить unique ASP.NET файлы сборки, чтобы получить эту конкретную сборку в память. Поэтому, если у вас есть 1 Сборка, содержащая 10 страниц, просто нажмите одну из страниц. Этого должно быть достаточно. Если у вас более 1 сборки, нажмите 1 страницу в каждой сборке, чтобы загрузить эти сборки в память.

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

    какую часть сайта вы хотите предварительно загрузить? Сколько страниц?

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

    при первом запросе страницы из скомпилированного ASP.NET приложение после того, как его сборки были изменены, обработка занимает намного больше времени, чем обычный запрос страницы.

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

    Asp средства повышения быстродействия iis

    Опубликовано: Февраль 2012 г.

    Обновлено: Февраль 2012 г.

    Назначение: Windows Server 2012, Windows Server 2012 R2

    В этом документе описан процесс установки веб-сервера IIS и его настройки для обслуживания статического содержимого. Статическим содержимым является веб-страница (HTML), которая доставляется пользователю в том виде, в котором она хранится. И наоборот, динамическое содержимое формируется веб-приложением, таким как ASP.NET, классическим приложением ASP или приложением PHP. Статическое содержимое отображает одинаковые сведения для всех пользователей; динамическое содержимое может отображать сведения о конкретном пользователе, например имя пользователя.

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

    Содержание документа

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

      Windows Server® 2012

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

    Эту процедуру можно также выполнить с помощью пользовательского интерфейса Windows или командной строки.

    На начальной странице щелкните плитку Диспетчер сервера, а затем нажмите кнопку ОК.

    В диспетчере сервера выберите Панель мониторинга и щелкните Добавить роли и компоненты.

    В мастере добавления ролей и компонентов на странице Перед началом нажмите кнопку Далее.

    На странице Выбор типа установки выберите Установка ролей или компонентов и нажмите кнопку Далее.

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

    На странице Выбор ролей сервера укажите Веб-сервер (IIS) и нажмите кнопку Далее.

    На странице Выбор компонентов просмотрите выбранные по умолчанию компоненты, а затем нажмите кнопку Далее.

    На странице Роль веб-сервера (IIS) нажмите кнопку Далее.

    На странице Выбор служб ролей просмотрите выбранные службы и нажмите кнопку Далее.

    Примечание
    Установите службы ролей IIS 8 по умолчанию для веб-сервера статического содержимого.

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

    На странице Ход выполнения установки убедитесь, что установка роли веб-сервера (IIS) и требуемых служб ролей успешно завершена, а затем нажмите кнопку Закрыть.

    Чтобы убедиться, что службы IIS успешно установлены, введите в веб-браузере следующее:

    http://localhost

    Должна отобразиться страница приветствия служб IIS по умолчанию.

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

    В панели управления выберите Программы, а затем Включение и отключение компонентов Windows.

    В диалоговом окне Компоненты Windows щелкните Службы IIS, а затем нажмите кнопку ОК.

    Будет установлен набор компонентов IIS 8 по умолчанию. Установите только компоненты по умолчанию для веб-сервера статического содержимого.

    Чтобы убедиться, что службы IIS успешно установлены, введите в веб-браузер следующее:

    http://localhost

    Должна отобразиться страница приветствия служб IIS по умолчанию.

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

    Start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-Security;IIS-RequestFiltering;IIS-HttpCompressionStatic;IIS-WebServerManagementTools;IIS-ManagementConsole;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

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

    Откройте диспетчер служб IIS.

      При работе в Windows Server 2012 на начальной странице щелкните Диспетчер сервера, а затем нажмите кнопку ОК. В диспетчере сервера выберите меню Сервис, а затем выберите Диспетчер служб IIS.


    При работе в Windows 8 на начальной странице введите Панель управления, а затем в результатах поиска щелкните значок Панель управления. На экране Панель управления выберите Системы и безопасность, затем Администрирование, после чего выберите Диспетчер служб IIS.

    На панели Соединения правой кнопкой мыши щелкните узел Сайты, а затем выберите Добавить веб-сайт.

    В диалоговом окне Добавление веб-сайта в поле Имя сайта введите понятное имя веб-сайта.

    Щелкните Выбрать, если нужно выбрать пул приложений, отличный от пула, указанного в поле Пул приложений. В диалоговом окне Выбор пула приложений в списке Пул приложений выберите пул приложений, а затем нажмите кнопку ОК.

    В поле Физический путь введите физический путь к папке веб-сайта или нажмите кнопку обзора (. ), чтобы перейти к файловой системе для поиска папки.

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

    В списке Тип выберите протокол для веб-сайта.

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

    В поле Порт введите номер порта.

    Дополнительно введите имя заголовка узла для веб-сайта в поле Заголовок узла.

    Если не следует вносить изменения в параметры веб-сайта и следует сделать его незамедлительно доступным, установите флажок Запустить веб-сайт немедленно.

    Нажмите кнопку ОК.

    В командной строке с повышенными привилегиями или в скрипте используйте следующий синтаксис:

    Примечание
    Чтобы этот синтаксис работал, необходимо либо находиться в следующем каталоге, либо иметь каталог в пути: %windir%\system32\inetsrv

    appcmd add site /name:string /id:цел_чис_без_зн /physicalPath:строка /bindings:строка

    Переменная name является именем, а переменная id — положительным целым числом, которое следует назначить сайту. Переменные name и id являются единственными переменными, которые требуются для добавления сайта с помощью команды appcmd. Но при добавлении сайта без задания значений атрибутов bindings и physicalPath сайт будет невозможно запустить.

    Переменная physicalPath является абсолютным путем к содержимому сайта в файловой системе.

    Переменная bindings содержит сведения, используемые для доступа к сайту. Она должна иметь вид протокол/IP_адрес:порт:заголовок_узла. Например, если указать для веб-сайта привязку http/*:85: , то это будет означать, что он прослушивает HTTP-запросы на порту 85 для всех IP-адресов и доменных имен (также известных как заголовки узлов или имена узлов). С другой стороны, привязка http/*:85: marketing.contoso.com настраивает сайт для прослушивания HTTP-запросов на порту 85 для всех IP-адресов и доменного имени marketing.contoso.com.

    Чтобы добавить веб-сайт contoso с идентификатором 2 и содержимым в папке c:\contoso, который прослушивает HTTP-запросы на порту 85 для всех IP-адресов и доменного имени marketing.contoso.com, введите в командную строку следующее:

    appcmd add site /name:contoso /id:2 /physicalPath:c:\contoso /bindings:http/*:85:marketing.contoso.com

    Анонимный доступ предоставляет пользователям доступ к общедоступным зонам веб-сайта без запроса имени пользователя и пароля. Анонимную проверку подлинности можно настроить с использованием учетной записи анонимного пользователя по умолчанию (IUSR) или можно настроить учетную запись локального пользователя для анонимных пользователей.

    В представлении Просмотр возможностей диспетчера служб IIS дважды щелкните пункт Проверка подлинности.

    На странице Проверка подлинности выберите Анонимная проверка подлинности.

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

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

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

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

    Важно
    При использовании учетной записи IUSR анонимным пользователям предоставляется возможность с помощью этой учетной записи осуществлять доступ ко всей внутренней сети.

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

    Используйте следующий синтаксис, чтобы изменить учетную запись по умолчанию для анонимного доступа:

    appcmd set config /section:anonymousAuthentication /userName:строка /password:строка

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

    appcmd set config /section:anonymousAuthentication /userName:Moe /password:pssword1

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

    В представлении Просмотр возможностей диспетчера служб IIS дважды щелкните пункт Документ по умолчанию.

    На панели Действия нажмите кнопку Добавить.

    В поле Имя введите имя файла, которое необходимо добавить в список документов по умолчанию, затем нажмите кнопку ОК. Это имя файла будет добавлено в верхнюю часть списка документов по умолчанию.

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

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

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

    appcmd set config /section:defaultDocument /+files.[value=’строка‘]

    Переменная string является добавляемым в список именем файла. Например, чтобы добавить файл home.html в список документов по умолчанию, в командной строке введите следующее:

    appcmd set config /section:defaultDocument /+files.[value=’home.html’]

    Чтобы удалить файл home.html из списка документов по умолчанию, в командной строке введите следующую команду и нажмите клавишу ВВОД:

    appcmd set config /section:defaultDocument /-files.[value=’home.html’]

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


    В представлении Просмотр возможностей диспетчера служб IIS дважды щелкните пункт Сжатие.

    Выберите Включить сжатие статического содержимого для сжатия службами IIS статического содержимого.

    В поле Статическое содержимое настройте следующие параметры:

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

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

    Кроме того, можно установить флажок Лимит места на диске на пул приложений (в МБ) и ввести максимальный размер дискового пространства (в мегабайтах), отводимого для каждого пула приложений, которое будет использоваться службами IIS при сжатии статического содержимого. Например, если существует 20 пулов приложений на сервере и параметр Лимит места на диске равен 100, максимальный объем дискового пространства будет равен 2 ГБ. Если выбрать параметр Лимит места на диске на пул приложений (в МБ) и ввести в текстовом поле определенное значение, то при достижении порогового значения службы IIS автоматически очистят временную папку в соответствии с правилом удаления наиболее давно использовавшихся файлов. Значение по умолчанию — 100 МБ для каждого пула приложений.

    Нажмите кнопку Применить на панели Действия.

    Чтобы включить сжатие HTTP статического содержимого, в командной строке введите следующую команду и нажмите клавишу ВВОД:

    appcmd set config /section:urlCompression /doStaticCompression:True

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

    appcmd set config /section:urlCompression /minFileSizeforComp:цел_чис /directory:строка /maxDiskSpace:цел_чис

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

    %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files

    Переменная maxDiskSpace служит для определения максимального количества места на диске (в мегабайтах) для каждого пула приложений, которое будет использоваться службами IIS при сжатии статического содержимого. Значение по умолчанию — 100 МБ для каждого пула приложений.

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

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

    Для повышения защищенности веб-сервера настройте фильтрацию запросов. Инструкции см. в статье Настройка фильтрации запросов в IIS.

    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

    В настоящее время:

    У меня есть проект ASP NET, который использует несколько ASHX. он работает едва приемлемо с ежедневными 50000 вызовами API входа в систему (и каждый вход в систему приходит разным количеством других вызовов API)

    но теперь это занимает> 1 минуты с ежедневными 150 000 вызовов API входа в систему.

    Чтобы разобраться с этой проблемой, я сделал это на одном из API с помощью вызова sproc, который только извлекает данные:

    1) Я запускаю его в другом новом экземпляре, на локальной машине, он работает менее 100 миллисекунд; текущий веб-экземпляр работает> 1 мин.

    2) я запускаю sproc самостоятельно в SSMS, это занимает 1 мин.

    3) Я сделал локальное назначение параметров для этого конкретного sproc, чтобы предотвратить перехват параметров и перестроение и повторный запуск, тот же результат.

    4) часть сериализации Json (newtonsoft) использует статическую, также очень быструю, менее 1 секунды.

    Я запустил » http://tools.pingdom.com/fpt/ » и действительно очень медленно; но я не уверен, почему это медленно.

    Я пытался использовать «DebugView» (« https://technet.microsoft.com/en-us/library/bb896647.aspx »), так как он может писать много журналов без блокировки файлов, но не уверен, как его поставить работает для веб-приложения.

    В любом случае / инструмент для захвата независимого времени begin_request & end_request внешне и точно? (Я пытался указать промежуток времени в Global.asax, но иногда получал некоторые нулевые параметры) Лучше всего, если у кого-то есть идея точно определить часть, которая его вызвала.

    образец временного теста:

    большая часть результата:

    2015-03-04 18: 45: 29,263 [163] Ведение журнала отладкиПомощь single_detail getPracticeQualificationTimeLeft длительность (мс): 5,8594

    2015-03-04 18: 45: 29,264 [163] DEBUG LoggingHelper single_detail generate ПродолжительностьJsonFromObj (мс): 0

    эти вещи я заметил.

    1) использование процессора компьютера и использование памяти: память на 70%, что, я думаю, все еще не пик

    2) проверьте, включено ли сжатие Gzip: мой json работает на мобильных устройствах (iOS / Android / WM); некоторые изменения кода необходимы, и не проверены, чтобы предотвратить любую проблему сжатия-распаковки; поскольку сжатие также увеличивает использование процессора в то же время

    Способы увеличения производительности

    Общие вопросы производительности веб-приложений


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

    При работе веб-приложения существенное влияние на производительность оказывают две составляющие:

    • программный код самого веб-сервера;
    • программный код прикладного приложения.

    Приложения ASP . NET работают в рамках веб-сервера Internet Information Services, который поставляется в составе семейства операционных систем Windows Server ( IIS ). Актуальная версия этого веб-сервера – IIS7 – содержит ряд механизмов по увеличению производительности приложений.

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

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

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

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

    Наиболее частые проблемы веб-приложений, которые снижают производительность приложения:

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

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

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

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

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

    Краткие итоги

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

    Как повысить безопасность IIS

    Защита без компромиссов

    В последнее время проблемам безопасности Microsoft IIS уделялось мало внимания. Прошло почти два года с тех пор, как компания Microsoft выпустила последнее исправление для Internet Information Services (IIS) 5.0, и исправлений, предназначенных непосредственно для IIS 6.0, пока не появилось. Благодаря изменениям в механизмах защиты Windows Server 2003 администраторы могут свободно запускать сервер IIS 6.0. Даже защиту IIS 5.0 можно быстро и довольно надежно усилить с помощью инструмента IIS Lockdown Tool.

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

    Детальное управление доступом

    Ключ к надежной защите Web-узла IIS — использование имеющихся в распоряжении администратора функций управления доступом. Чтобы управлять доступом, можно определять разрешенные типы файлов и операции (verb) HTTP, применимые к каждому типу файлов; ограничивать обращения к определенному контенту по каналам IP; позволять или запрещать запись, чтение и доступ к каталогам. Эти параметры можно настроить из интерфейса пользователя IIS Manager в IIS 6.0 или через оснастку IIS консоли Microsoft Management Console (MMC) в IIS 6.0 и более ранних версиях. Кроме того, можно с успехом задействовать детальные файловые разрешения NTFS и назначать отдельные разрешения для каждого типа контента и области Web-узла. О разрешениях NTFS рассказано в статье «Разрешения NTFS для Web-сервера» Windows 2000 Magazine/RE № 7 за 2002 год.

    Обратите внимание на разрешения для индивидуальных файлов. Например, лишь немногим администраторам известно, что не нужно разрешать доступ по чтению к файлам .asp и что следует сбросить флажок Read для всех .asp-файлов из консоли IIS Manager (см. экран 1).

    Экран 1. Настройка разрешений для .asp-файлов

    В NTFS можно задать список управления доступом ACL с конкретными разрешениями для папки, любых дочерних объектов (например, файлов) и любых дочерних контейнеров (например, подкаталогов). Следовательно, каталогу можно назначить строгие ограничения, запретив доступ ко всем дочерним объектам, а затем явно изменить разрешения для отдельных файлов в этом каталоге, предоставив пользователям любые, необходимые им для доступа. Затем пользователи могут обращаться к отдельным файлам, но каждый раз, когда в этом каталоге создается новый файл, он автоматически наследует строгие ограничения, установленные для каталога.

    Учетная запись IUSR обрабатывает анонимные запросы к Web-ресурсам. Назначая разрешения NTFS, следует предоставить доступ Read в анонимном режиме и доступ Read для конкретных пользователей или групп в режиме с аутентификацией. Если запретить учетной записи IUSR доступ Read, например, к файлу index.html, то анонимные пользователи Web не смогут обратиться к нему.

    Установка URLScan

    Многие администраторы разворачивают URLScan на Web-узлах IIS 5.0 в качестве дополнительного уровня защиты. URLScan — фильтр Internet Server API (ISAPI), который перехватывает запросы, получаемые Web-сервером из Internet и анализирует их в поисках необычных элементов. Инструмент можно загрузить с сайта по адресу http://www.microsoft.com/technet/security/ tools/urlscan.mspx .

    Многие функции URLScan встроены в IIS 6.0 или стали ненужными в обновленной архитектуре, но URLScan по-прежнему может пригодиться для защиты IIS 6.0, и я рекомендую установить утилиту. URLScan располагает гибкими параметрами фильтрации для отражения новых атак и возможностями более детального управления Web-запросами через функцию DenyUrlSequences. Например, администратор IIS 6.0 может ограничить длину определенных частей запроса, а с помощью URLScan можно определить длину заголовков индивидуальных запросов HTTP. Ограничение длины защищает от длинных строк, способных вызвать переполнение буфера. Вероятно, главное достоинство URLScan заключается в дополнительном уровне защиты, который будет полезен, если во встроенных механизмах безопасности IIS 6.0 будут все-таки обнаружены уязвимые места.

    Хранение данных, не размещаемых в Web

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

    Изолированные административные каталоги

    Существует на удивление много Web-узлов, административным каталогам которых присвоены такие легко угадываемые имена, как admin, backup, logs или stats. Подобных каталогов на общедоступном Web-узле быть не должно. Они представляют собой отличную мишень для злоумышленников, которым не потребуется много времени для установления их местоположения.

    Поэтому конфиденциальную информацию желательно разместить на особом сайте и спрятать с помощью хост-заголовков (host header) и нестандартных портов (портов с более высокими номерами или портов других прикладных протоколов). Хост-заголовки позволяют разместить по одному IP-адресу несколько Web-узлов, различаемых по хост-имени. Например, по одному IP-адресу можно разместить основной Web-узел http://www.example.com и дополнительный сайт admin.example.com. Доступ к сайту ограничивается разрешениями и аутентификацией, применяемыми к IP-адресу. Если конфиденциальный каталог необходимо оставить на общедоступном Web-узле, то нужно, по крайней мере, изменить имя каталога на трудно угадываемое и ввести ограничения по IP-адресу и доступу пользователей, например потребовать клиентские сертификаты Secure Sockets Layer (SSL). Важно отметить, что непонятные имена не ограничивают доступ к сайту, но сайт становится менее очевидной мишенью.

    Привести Webroot в порядок

    Есть ли в Web-узле файл с именем вроде test.asp? Если такой файл имеется, значит, администратор пренебрегал «уборкой мусора» в каталогах Web-контента. Тестовые сценарии, резервные копии, старые версии файлов, устаревший контент и временные файлы могут подорвать безопасность сервера. Даже самые бессодержательные файлы несут крупицу информации, которая может пригодиться взломщику. Если эти файлы удалить, то взломщик не сможет использовать их против Web-узла.

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

    Еще один совет: при публикации новой редакции Web-узла следует пометить все файлы одним временем. Это облегчит поиск файлов, измененных или созданных взломщиком.

    Тонкая настройка параметров IIS

    Многие параметры IIS недоступны непосредственно из IIS Manager, но с их помощью можно остановить атаку или сузить ее область. Например, в ходе атаки с переполнением буфера на Web-узел обрушивается огромное количество данных. Администраторы IIS 6.0 могут использовать параметры метабазы MaxRequestEntityAllowed и AspMaxRequestEntityAllowed, чтобы ограничить размер тела запроса или запроса Active Server Pages (ASP) соответственно. Эти параметры позволяют установить максимальный размер в байтах тела запроса, указанный в заголовке величины контента HTTP. Редактировать базу данных можно с помощью инструмента IIS Metabase Explorer (см. экран 2). Metabase Explorer входит в пакет Microsoft IIS 6.0 Resource Kit Tools, который можно загрузить с сайта http://www.microsoft.com. В табл. 1 показаны некоторые параметры метабазы, которые иногда полезно менять. В табл. 2 приведено несколько параметров реестра, изменение которых также желательно.

    Экран 2. Редактирование метабазы IIS

    Следовать философии Microsoft

    Самое очевидное различие между стандартными установками IIS 6.0 и IIS 5.0 заключается в том, что первый отражает новую стратегию «безопасности по умолчанию», принятую в Microsoft. Для реализации нового подхода Microsoft отказалась от установки компонентов по умолчанию и назначает самые строгие параметры безопасности, сохраняя при этом возможность организовать базовый Web-узел. Но лишь немногие администраторы реализуют этот подход на практике; они устанавливают функции, которых не используют, или ослабляют режим безопасности до такой степени, что сервер становится уязвимым.

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

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

    Автор, специализирующийся на проблемах безопасности Windows. Имеет сертификат IIS MVP. Его книга Hacking the Code вышла в издательстве Syngress. С ним можно связаться по адресу (mburnett@xato.net)

    Поделитесь материалом с коллегами и друзьями

    Илон Маск рекомендует:  Метод предельных упрощений (мпу)
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL