Исследование производительности ASP.NET-приложений



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

Ключевые слова: ASP.NET, производительность, веб-приложение, быстродействие

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

ASP.NET представляет из себя часть технологии.NET, предназначенную для создания динамических HTML-страниц. Она позволяет писать мощные клиент-серверные веб-приложения. ASP.NET возникла в результате объединения более старой технологии ASP (active server pages) и.NET Framework. В ней содержатся готовые элементы управления, позволяющие быстро и качественно создавать готовые интерактивные интернет-сайты. Ключевое слово здесь — быстро. Также имеется возможность использовать сервисы других сайтов максимально понятно и прозрачно для пользователей.

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

В первом случае пользователя интересует скорость реакции на его запрос, то есть время отклика приложения. Остальное его не интересует. При относительно малом времени отклика пользователя не будет возникать других вопросов к приложению, касающихся его производительности [1].

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

Подходы к повышению производительности можно условно разделить на три группы: уменьшение времени обработки страницы на стороне клиента, на стороне сервера и уменьшение объема передаваемых данных [2].

Чтобы уменьшить время обработки страницы на стороне клиента нужно придерживаться некоторых правил:

− Максимально использовать таблицы стилей CSS.

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

− Максимально оптимизировать HTML.

− Максимально оптимизировать JavaScript. Соблюдение последних двух условий может позволить добиться существенного прироста в скорости загрузки страницы.

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

Уменьшение объема передаваемых данных:

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

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

− Использование SSL только там, где это действительно необходимо. Любое шифрование почти всегда повышает объем передаваемых данных. Зачастую оно используется там, где не приносит пользы. Многие страницы и приложения не содержат никакой конфиденциальной или другой информации, которую следовало бы шифровать. Хотя во многих других случаях использование SSL оправданно. Необходимо стремиться к тому, чтобы шифрование применялось только в последних случаях.

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

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

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

Уменьшение времени обработки страницы на стороне сервера:

Здесь правил больше всего, и их выполнение особенно важно, так как время обработки запроса сервером часто превышает время на других этапах работы веб-приложения [3].

− Максимальная оптимизация кода и использования ресурсов. Здесь комментарии не требуются. Чем быстрее будет происходить обработка запроса на сервере, там быстрее ответ будет приходить к клиенту.

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

− Отключение неиспользуемых HTTPModule

− Оптимизация конфигурации ASP.NET. В большинстве случаев использования ASP.NET файлам конфигурации не уделяют должного внимания. Стандартная конфигурация ASP.NET универсальна — она удовлетворяет большинству требований, то в каждом конкретном отдельно взятом случае она не является оптимальной. Конфигурацию следует подстраивать уникально, в зависимости от функций.

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

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

− Кэширование. Последние три свойства являются основными в этой группе. Кэширование — одно из них. В самом простом случае оно подразумевает сохранение копии данных на определенное время на стороне клиента. Это позволяет при большинстве запросов не выполнять загрузку данных с сервера по линии соединения, а загружать ее из кэша, что существенно снижает нагрузку на соединение. Все изменения, которые производятся со страницей, сохраняются именно в этой копии у клиента. Чаще всего кэширование производится на заданной временной промежуток. В этом случае первая операция, обращенная к странице, произошедшая по истечении этого промежутка времени, уже действительно загрузит страницу по сети, тем самым обновив ее копию в кэше, а все предыдущие операции будут работать лишь с этой копией. Причем в ASP.NET реализованы так называемые профили кэширования. Они позволяют заранее создать в файле web.config настройки кэширования, такие как время хранения копии и другие параметры, а затем лишь обращаться к этим профилям, не обозначая всех параметров. Однако, при использовании кэширования следует помнить об одном важном моменте. При использовании копии данных, сохраненных на стороне клиента, можно добиться повышения скорости работы веб-приложения, но, как только будет превышено определенное количество данных, хранящихся в кэше, произойдет серьезное падение производительности, так как память клиента имеет физические ограничения, и хранить на ней данных в полном объеме не получится. Поэтому при использовании кэширования следует соблюдать баланс между общим объемом информации и той частью, которая сохраняется в кэше клиента.

− Асинхронность. На веб-сервере платформы.NET Framework поддерживается пул потоков, которые используются для обслуживания запросов ASP.NET. При получении запроса, для его обработки из этого пула выделяется поток (thread). Если запрос обрабатывается синхронно, то поток, который обрабатывает запрос, блокируется на время обработки запроса. Такой поток не может обслуживать другой запрос. Это может не составлять проблемы, так как пул потоков можно сделать достаточно большим для вмещения множества заблокированных потоков. Однако, количество потоков в пуле ограничено. В больших приложениях, которые обрабатывают несколько одновременных запросов, которые выполняются длительное время, все доступные потоки могут быть заблокированы. Такая ситуация называется нехваткой потоков. При наступлении этой ситуации веб-сервер помещает запросы в очередь. После заполнения очереди запросов веб-сервер отклоняет запросы, возвращая код ошибки HTTP 503 (сервер перегружен). В приложениях, в которых может возникнуть нехватка потоков, можно настроить действия, которые обрабатываются асинхронно. Асинхронный запрос обрабатывается такое же количество времени, что и синхронный запрос. Например, если запрос выполняет сетевой вызов, который требует две секунды для выполнения, запрос будет обрабатываться две секунды, независимо от того, выполнен он синхронным или асинхронным способом. Однако, при асинхронном вызове сервер не заблокирован для ответов на другие запросы во время ожидания выполнения первого запроса. Поэтому асинхронные запросы предупреждают постановку запросов в очередь в ситуации, когда существует множество запросов, которые вызывают длительные по времени операции.

− Многопоточность. Это свойство позволяет достаточно просто и производительно реализовать процессы, не связанные с пользовательским интерфейсом, или требующие запуска по расписанию. Без использования многопоточности эти операции приводят к блокированию пользовательского интерфейса. Например, это может быть обращение к какому-то серверу в сети. В этом случае пользователю придется дожидаться момента, когда от этого сервера вернется ответ. Только тогда он сможет продолжить работа с приложением. Разумнее было бы предоставить в это время пользователю возможность выполнять какие-то другие действия или вообще отменить этот запрос. В любой ситуации, когда требуется ожидание, будь то запрос к базе данных, файлу или сети, может запускаться новый поток, позволяющий в это время решать другие задачи. Это и есть многопоточность. Она может быть реализована через обработку потоков одного и того же запроса разными процессорами или, что бывает чаще, разными ядрами одного процессора. При этом могут возникать определенные проблемы. Например, в случае, когда разные потоки пытаются одновременно получить доступ к одним и тем же данным. Поэтому при использовании многопоточности следует помнить о механизмах синхронизации потоков. В этом случае многопоточность оправдана и способна принести очень существенный вклад в повышение производительности приложения [4].

Литература:

1. 10 Useful Findings About How People View Websites // ConversionXL. URL: https://conversionxl.com/ (дата обращения: 30.05.2017).
2. Анатомия ASP.NET. ASP.NET в действии // Сайтостроение от А до Я. URL: http://www.internet-technologies.ru. (дата обращения 03.05.2017).
3. Оптимизация ASP.NET — практические советы по работе с IIS // Хабрахабр. URL: http://habrahabr.ru. (дата обращения 03.04.2017).
4. Эспозито Д. Знакомство с технологией Microsoft ASP.NET 2.0 AJAX. — СПб.: Русская редакция, 2008. — 320 с.