Контрольный список для обеспечения масштабируемости и производительности для Хранилища очередей
Корпорация Майкрософт разработала множество проверенных методик разработки высокопроизводительных приложений с помощью служба хранилища очередей. Этот контрольный список определяет основные методики, которые помогут разработчикам оптимизировать производительность. Имейте в виду эти методики при разработке приложения и на протяжении всего процесса.
Служба хранилища Azure имеет целевые показатели по масштабируемости и производительности, выраженные в объемах, скорости транзакций и пропускной способности. См. дополнительные сведения о целевых показателях масштабируемости для учетных записей хранения (цен. категории "Стандартный") и Хранилища очередей в службе хранилища Azure.
Контрольный список
В этой статье проверенные методы повышения производительности собраны в контрольный список, который поможет вам при разработке приложений Хранилища очередей.
Целевые показатели масштабируемости
Если приложение приближается или превышает любой из целевых показателей масштабируемости, может возникнуть повышенная задержка транзакций или регулирование. Когда служба хранилища Azure применяет регулирование для приложения, она начинает возвращать коды ошибок 503 (Server Busy) или 500 (Operation Timeout). Этих ошибок можно избежать, строго соблюдая ограничения для целевых показателей масштабируемости. Это важная часть стратегии по повышению производительности приложения.
Дополнительные сведения о целевых показателях масштабируемости для Хранилища очередей см. в статье Целевые показатели масштабируемости и производительности для службы хранилища Azure.
Максимальное количество учетных записей хранения
Если количество учетных записей хранения приближается к максимальному разрешенному количеству для вашего сочетания подписки и региона, используете ли вы несколько учетных записей хранения на каждый сегмент, чтобы повысить скорость приема, передачи, количество операций ввода-вывода в секунду (IOPS) или емкость хранилища? Для такой ситуации корпорация Майкрософт рекомендует увеличить ограничения по учетным записям хранения, если это возможно, чтобы сократить количество учетных записей хранения для рабочей нагрузки. Запрос на увеличение ограничений на количество учетных записей хранения следует направлять в службу поддержки Azure.
Целевые показатели емкости и транзакций
Если приложение достигает целевых показателей масштабируемости, когда речь идет об одной учетной записи хранения, рассмотрите вопрос об использовании одного из следующих подходов:
- Если для вашего приложения этих целевых показателей недостаточно, создайте несколько очередей и распределите сообщения между ними.
- Пересмотрите рабочую нагрузку, которая приводит к достижению приложением целевого показателя масштабируемости или его превышению. Вы можете спроектировать его по-другому, чтобы использовать меньшую полосу пропускания или производительность, или меньшее количество транзакций?
- Если приложение должно превышать какой-то из целевых показателей масштабируемости, создайте несколько учетных записей хранения и сегментируйте между ними данные приложения. При использовании этого подхода необходимо разработать приложение таким образом, чтобы в будущем для балансировки нагрузки в него можно было добавлять другие учетные записи хранения. Плата взимается только за потребление, то есть объем хранимых и передаваемых данных и совершенные транзакции, но не за сами учетные записи хранения.
- Если приложение приближается к целевым показателям пропускной способности, попробуйте применить сжатие данных на стороне клиента, чтобы снизить пропускную способность, требуемую для отправки данных в службу хранилища Azure. В то время как сжатие данных может сохранить пропускную способность и повысить производительность сети, она также может оказать негативное влияние на производительность. Оцените, как дополнительная работа по сжатию и распаковке данных на стороне клиента влияет на производительность. Помните, что хранение сжатых данных может сделать устранение неполадок более сложным, так как это может оказаться более сложным для просмотра данных с помощью стандартных средств.
- Если приложение приближается к целевым показателям масштабируемости, убедитесь, что вы используете экспоненциальный обратный выход для повторных попыток. Лучше всего сделать так, чтобы приложение не приближалось к целевым показателям масштабируемости. Для этого примените описанные в этой статье рекомендации. Однако использование экспоненциальной обратной передачи для повторных попыток предотвращает быстрое повторение приложения, что может привести к более плохому регулированию. Дополнительные сведения см. в разделе Ошибки времени ожидания и занятости сервера.
Сеть
Ограничения физической сети приложения могут оказать значительное влияние на производительность. В следующих разделах описаны некоторые ограничения, с которыми могут столкнуться пользователи.
Возможности клиентской сети
Пропускная способность и качество сетевого подключения являются важными факторами, влияющими на производительность приложения, как описано в следующих разделах.
Пропускная способность
Что касается полосы пропускания, частой проблемой являются возможности клиента. Очень крупные экземпляры Azure имеют сетевые карты, обладающие большими возможностями, поэтому если необходимы более высокие сетевые ограничения от одной машины, следует рассмотреть возможность использования более крупного экземпляра или большего количества виртуальных машин. Если вы обращаетесь к служба хранилища Azure из локального приложения, то применяется то же правило: понять сетевые возможности клиентского устройства и сетевое подключение к расположению служба хранилища Azure и улучшить их по мере необходимости или разработать приложение для работы в пределах своих возможностей.
Качество связи
Как и при любом использовании сети, следует помнить, что сетевые условия приводят к ошибкам и потере пакетов замедляет эффективную пропускную способность. Использование Wireshark или Сетевого монитора может помочь в диагностике этой проблемы.
Местонахождение
В любой распределенной среде наилучшее быстродействие достигается при нахождении клиента рядом с сервером. Для доступа к хранилищу Azure с наименьшей задержкой лучшим местом для клиента будет его нахождение в том же регионе Azure. Например, если ваше веб-приложение Azure использует службу хранилища Azure, разместите их в одном регионе (западная часть США, Юго-Восточная Азия и т. д.). Совместное размещение ресурсов уменьшает задержку и снижает стоимость, так как трафик в пределах одного региона остается бесплатным.
Если клиентские приложения получают доступ к служба хранилища Azure, но не размещаются в Azure, например приложения мобильных устройств или локальные корпоративные службы, то поиск учетной записи хранения в регионе рядом с этими клиентами может снизить задержку. Если клиенты разбросаны по всему миру (например, часть в Северной Америке, а остальные в Европе), обдумайте вариант с несколькими учетными записями хранения, по одной в каждом регионе. Этот подход проще реализовать, если данные хранилища приложений зависят от отдельных пользователей и не требуют реплика данных между учетными записями хранения.
SAS и CORS
Предположим, что вам нужно создать код JavaScript, который выполняется в веб-браузере пользователя или приложении на мобильном телефоне и обращается к данным в службе хранилища Azure. Один из вариантов — создать приложение-службу, которое выполнит роль прокси-сервера. Устройство пользователя проходит проверку подлинности в этой службе, которая, в свою очередь, предоставляет доступ к ресурсам службы хранилища Azure. Таким образом, на небезопасных устройствах можно не сообщать ключи своей учетной записи хранения. Но такой подход создает значительную нагрузку на приложение-службу, через которое проходят все данные, передаваемые между пользовательским устройством и службой хранилища Azure.
Вы можете обойтись без приложения-службы прокси-сервера, обращаясь к службе хранилища Azure с использованием подписанных URL-адресов (SAS). С технологией SAS вы можете разрешить пользовательскому устройству напрямую обращаться к службе хранилища Azure с маркером ограниченного доступа. Например, если пользователь хочет отправить фотографию в приложение, приложение-служба создаст SAS и отправит его на устройство пользователя. Маркер SAS может предоставлять разрешение на запись в ресурс службы хранилища Azure в течение указанного интервала времени. По истечении этого времени маркер SAS становится недействительным. Дополнительные сведения о подписанных URL-адресах см. в статье об использование подписанных URL-адресов SAS в службе хранилища Azure.
Как правило, веб-браузер не разрешает JavaScript на странице, размещенной веб-сайтом на одном домене, выполнять определенные операции, такие как операции записи, в другой домен. Эта политика использования одного источника не позволяет вредоносному коду с любой веб-страницы получить доступ к данным, размещенным на другой странице. Но при создании облачного решения политика использования одного источника становится неудобным ограничением. Реализуемая на уровне браузера технология CORS (общий доступ к ресурсам независимо от источника) позволяет целевому домену сообщать браузеру, что он доверяет запросам, поступающим из определенных исходных доменов.
Предположим, что выполняемое в Azure веб-приложение обращается к ресурсу в учетной записи хранения Azure. В этом сценарии веб-приложение выполняет роль исходного домена, а учетная запись хранения является целевым доменом. Вы можете настроить CORS для любой из служб хранилища Azure, чтобы она сообщала веб-браузеру о том, что служба хранилища Azure доверяет запросам, поступающим из исходного домена. Дополнительные сведения о технологии CORS см. в статье Cross-Origin Resource Sharing (CORS) support for Azure Storage (Поддержка общего доступа к ресурсам независимо от источника (CORS) для службы хранилища Azure).
Технологии SAS и CORS помогают избавиться от лишней нагрузки на веб-приложения.
Конфигурация .NET
Для проектов, использующих платформа .NET Framework, в этом разделе перечислены некоторые быстрые параметры конфигурации, которые можно использовать для повышения производительности. Если вы используете язык, отличный от .NET, проверка, чтобы узнать, применяются ли аналогичные понятия в выбранном языке.
Увеличение стандартного ограничения на количество подключений
Примечание.
Этот раздел применяется к проектам с помощью платформа .NET Framework, так как пул подключений управляется классом ServicePointManager. .NET Core представила значительное изменение управления пулом подключений, где пул подключений происходит на уровне HttpClient, а размер пула по умолчанию не ограничен. Это означает, что HTTP-подключения автоматически масштабируются для удовлетворения рабочей нагрузки. По возможности рекомендуется использовать последнюю версию .NET, чтобы воспользоваться преимуществами улучшений производительности.
Для проектов, использующих платформа .NET Framework, можно использовать следующий код, чтобы увеличить ограничение подключения по умолчанию (обычно 2 в клиентской среде или 10 в серверной среде) до 100. В обычном случае следует установить значение, приблизительно соответствующее количеству потоков, используемых приложением. Ограничение количества подключений должно быть установлено до открытия каких-либо подключений.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Дополнительные сведения об ограничениях пула подключений в платформа .NET Framework см. в статье платформа .NET Framework Подключение ограничения пула подключений и новый пакет SDK Azure для .NET.
Что касается других языков программирования, то для определения механизма установки ограничения количества подключений см. документацию.
Увеличение минимального количества потоков
Если вы используете синхронные вызовы вместе с асинхронными задачами, может потребоваться увеличить количество потоков в пуле потоков:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
См. описание метода ThreadPool.SetMinThreads.
Неограниченный параллелизм
Хотя параллелизм может быть отличным для производительности, будьте осторожны с использованием несвязанного параллелизма, то есть нет ограничений, применяемых к количеству потоков или параллельных запросов. Обязательно ограничьте количество параллельных запросов на отправку или скачивание данных, на доступ к нескольким секциям в одной учетной записи хранения и на доступ к нескольким элементам в одной секции. При неограниченном параллелизме приложение сможет превысить возможности клиентского устройства или целевые показатели масштабируемости для учетных записей хранения, что приведет к увеличению задержек и применению регулирования.
Клиентские библиотеки и средства
Для повышения производительности всегда используйте самые последние версии клиентских библиотек и средств, предоставляемых корпорацией Майкрософт. служба хранилища Azure клиентские библиотеки доступны для различных языков. Обозреватель службы хранилища также поддерживает PowerShell и Azure CLI. Корпорация Майкрософт активно развивает эти клиентские библиотеки и средства, оптимизируя их производительность, поддерживая их согласованность с последними версиями служб и реализуя внутреннюю поддержку для многих проверенных методов повышения производительности. Дополнительные сведения см. в документации по службе хранилища Azure.
Обработка ошибок службы
служба хранилища Azure возвращает ошибку, когда служба не может обработать запрос. Понимание ошибок, которые могут быть возвращены служба хранилища Azure в данном сценарии, полезно для оптимизации производительности.
Ошибки времени ожидания и занятости сервера
служба хранилища Azure может ограничить приложение, если оно приближается к ограничениям масштабируемости. В некоторых случаях служба хранилища Azure может быть не удается обработать запрос из-за некоторого временного состояния. В обоих случаях служба может вернуть ошибку 503 (Server Busy) или 500 (Timeout). Эти же ошибки могут возникать, когда служба перераспределяет сегменты данных для повышения пропускной способности. В большинстве случаев при получении таких ошибок приложению следует повторить операцию, которая их вызвала. Однако если служба хранилища Azure регулирует приложение, так как оно превышает целевые показатели масштабируемости или даже если служба не могла обслуживать запрос по какой-либо другой причине, агрессивные повторные попытки могут привести к проблеме хуже. Мы рекомендуем использовать экспоненциальную задержку для политики повтора. Во всех клиентских библиотеках именно такое поведение является вариантом по умолчанию. Например, приложение может повторить попытку через 2 секунды, а затем 4 секунды, а затем 10 секунд, а затем 30 секунд, а затем полностью отказаться. Это позволяет приложению значительно снизить нагрузку на службу и не усугублять проблемы, связанные с регулированием.
Подключение ошибок может быть получен немедленно, так как они не являются результатом регулирования и, как ожидается, будут временными.
Ошибки без возможности повтора
Клиентские библиотеки обрабатывают повторные попытки с пониманием того, какие ошибки могут быть извлечены и которые не могут. Однако если вы вызываете служба хранилища Azure REST API напрямую, возникают некоторые ошибки, которые не следует повторить. Например, ошибка 400 (Bad Request) указывает, что клиентское приложение отправило запрос, который не удалось обработать, так как он не был в ожидаемой форме. Повторное выполнение этого запроса приводит к тому же ответу каждый раз, поэтому нет смысла повторять его. Если вы вызываете служба хранилища Azure REST API напрямую, помните о потенциальных ошибках и о необходимости их извлечения.
Дополнительные сведения о кодах ошибок в службе хранилища Azure вы найдете в статье Status and Error Codes (Коды ошибок и состояний).
Отключение алгоритма Нейгла
Алгоритм Нейгла широко применяется во всех TCP/IP-сетях в качестве средства повышения производительности сети. Однако это не оптимально во всех обстоятельствах (например, высокоактивные среды). Алгоритм Нейгла оказывает негативное влияние на производительность запросов к Хранилищу таблиц Azure, поэтому при возможности его следует отключить.
Размер сообщения
Производительность и масштабируемость очередей уменьшается по мере увеличения размера сообщений. Размещайте в сообщении только ту информацию, которая необходима получателю.
Пакетное извлечение
В одной операции из очереди можно извлечь до 32 сообщений. Такое пакетное извлечение поможет уменьшить количество запросов из клиентского приложения, что особенно полезно в средах с большой задержкой, например при работе с мобильными устройствами.
Интервал опроса очереди
Большинство приложений опрашивают сообщения из такой очереди, которая может быть одним из самых крупных источников транзакций для этих приложений. Выбирайте интервал опроса тщательно: слишком высокая частота опросов может привести к тому, что будет достигнуто целевое значений масштабируемости очереди. Тем не менее, в 200 000 транзакций за $ 0,01 (во время написания), один процессор опрос один раз в секунду в течение месяца будет стоить менее 15 центов, поэтому стоимость обычно не является фактором, который влияет на выбор интервала опроса.
Актуальные сведения о стоимости см. на странице цен на службу хранилища Azure.
Выполнение операции обновления сообщения
Чтобы увеличить время ожидания невидимости или обновить информацию о состоянии сообщения, можно использовать операцию обновления сообщения. Такой подход может оказаться более эффективным, чем создание рабочего процесса для передачи задания из одной очереди в другую по мере завершения этапов этого задания. Приложение сможет сохранять состояние задания в сообщении и продолжать свою работу вместо того, чтобы повторно размещать сообщение в очереди после завершения каждого шага. Но не забывайте, что каждая операция обновления сообщения учитывается при подсчете целевого показателя масштабируемости.
Архитектура приложения
Чтобы сделать архитектуру приложения масштабируемой, используйте очереди. Ниже перечислены некоторые способы использования очередей для того, чтобы сделать приложение более масштабируемым:
- Очереди можно использовать для инициации отставания от работы, необходимого для обработки и сглаживания рабочих нагрузок в приложении. Например, запросы от пользователей можно поместить в очередь, чтобы позволить процессору выполнить трудоемкую работу, такую как изменение размера загружаемых изображений.
- Очереди можно использовать, чтобы отделить части приложения для их независимого масштабирования. Например, клиент веб-интерфейса может разместить результаты опроса пользователей в очередь для последующего анализа и хранения. По мере необходимости для обработки данных очереди можно добавлять экземпляры роли worker.