ASP.NET Web API — отличная технология. Написание веб-API настолько просто, что многие разработчики не тратят время на структурирование своих приложений для достижения хорошей производительности выполнения.
В этой статье я рассмотрю 8 методов повышения производительности ASP.NET веб-API.
1) Используйте самый быстрый инструмент сериализации JSON
Сериализация JSON имеет критическое влияние на производительность всего ASP.NET Web API. В одном из моих проектов я перешёл с сериалайзера JSON.NET на ServiceStack.Text на полтора года.
Я измерил, что производительность веб-API улучшилась примерно на 20%. Очень рекомендую попробовать этот инструмент сериализации. Вот некоторые недавние сравнительные данные по производительности популярных инструментов сериализации.
SerializerPerformanceGraf
Источник: theburningmonk
Обновление: Похоже, что StackOverflow использует Jil, их заявленный на сегодняшний день инструмент сериализации JSON. Тестовые данные можно найти на их странице GitHub под названием Jil serializer.
2) Ручная сериализация JSON из DataReader
Я использовал этот подход в своих проектах и получал преимущества по производительности.
Вы можете вручную создавать JSON-строки из DataReader и избегать ненужного создания объектов, чтобы не брать значения из DataReader и записывать их в объекты, затем брать значения из этих объектов и использовать JSON Serializer для генерации JSON.
Используйте StringBuilder для генерации JSON и возврата StringContent в конце как содержимое ответа в WebAPI.
Больше способов сделать это можно в блоге Рика Страла
3) Максимально использовать другие форматы протоколов (буфер протокола, пакет сообщений)
Если вы можете использовать другие форматы сообщений в вашем проекте, такие как буферы протокола или пакеты сообщений, вместо использования JSON.
Вы получите огромное преимущество в производительности не только потому, что буферы протокола очень быстры в сериализации, но и потому, что они форматируются быстрее, чем JSON, в полученных результатах.
4) Реализовать сжатие
Используйте GZIP или Deflate в вашем ASP.NET веб-API.
Сжатие — это простой и эффективный способ уменьшить размер и оперативность ответных пакетов.
Это очень необходимая функция, вы можете ознакомиться с другими статьями о сжатии в моём блоге ASP.NET Web API GZip compression ActionFilter с 8 строками кода.
5) Использование кэширования
Использование кэширования выхода в методе Web API — это очень важно. Например, если большое количество пользователей получает доступ к контенту с ответами, это меняется только раз в день.
Если вы хотите реализовать ручное кэширование, например, кэшировать пароли пользователей в память, смотрите мой пост в блоге «Простой способ реализовать кэширование в ASP.NET веб-API».
6) Используйте типичные ADO.NET по возможности
Ручной ADO.NET всё ещё самый быстрый способ получить значения из базы данных. Если производительность ваших веб-API для вас действительно важна, не используйте ORM.
Вы можете увидеть сравнение производительности самых популярных ORM.
ORMMapper
Dapper и рукописный код для поиска быстры, и, конечно, все ORM медленнее трёх.
LLBLGen с кэшем наборов результатов работает быстро, но ему приходится повторно итерировать набор результатов и снова создавать объект в памяти.
7) Реализовать асинхронный подход в веб-API
Использование асинхронного веб-API значительно увеличивает количество HTTP-запросов, которые обрабатывают веб-API.
Реализация проста: просто используйте ключевое слово async и измените тип возвращаемого значения метода на Task.
8) Возвращает несколько наборов результатов и их комбинаций
Сокращение количества переносов полезно не только для нескольких баз данных, но и для веб-API, позволяющих использовать возможности наборов результатов.
Это означает, что вы можете извлечь несколько наборов результатов из DataReader, см. следующий демонстрационный код:
Вы можете вернуть несколько объектов в одном ответе из веб-API, попробуйте объединить возвращённые объекты и вернуть следующие объекты:
Это сократит количество HTTP-запросов к вашему WEB API.
Спасибо, что прочитали эту статью.
|
Опубликовано 11.01.2016 14:37:43
|
|
|
|
