На прошлой неделе мы с Ксавье были очень рады, что достигли вехи. После нескольких вечеров, посвященных интеграции Visual Studio Online с MyGet , мы были счастливы, что нас упомянули в лейтмотиве TechEd, и даже всплыли на некоторых сессиях. Мы также узнали, что скоро появится ASP.NET vNext, и он будет использовать NuGet как важную его часть. Однако мы не знали, что команда ASP.NET будет размещать все пакеты предварительного просмотра vNext из MyGet. Но вскоре мы заметили и обнаружили, что наши вечерние часы будут очень сосредоточены еще несколько дней …
12 мая мы внезапно увидели, что использование нашего сервиса удвоилось. Ой! Вот что Google Analytics сказал нам:
К счастью для нас, мы размещены на Azure и можем просто потянуть ползунок вправо и добавить больше серверов. Масштаб для победы! Помимо некоторых проблем, когда мы включили автоматическое масштабирование (мы думали, что трафик будет падать в некоторые моменты в течение дня), MyGet справлялся с трафиком довольно хорошо. Но все же нам пришлось удвоить емкость нашего сервера, чтобы иметь возможность разместить один канал NuGet с большим трафиком. И хотя мы удвоили производительность, время отклика также увеличилось.
Время действовать! Но что…
Некоторые сведения о нашем приложении
Когда мы запустили MyGet, нашей идеей было использовать хранилище таблиц и хранилище больших двоичных объектов и полностью избегать SQL. Причиной этого является то, что тогда MyGet был простым испытанием концепции, и мы хотели поиграть с новыми технологиями. Растя, набирая обороты и привлекая пользователей, мы обнаружили, что с тем, что у нас было для работы с этим бэкэндом, было очень приятно работать, и с тех пор мы перешли на более CQRS-иш-ориентированную (-ish) архитектуру.
Но со всеми хорошими вещами приходят и плохие. Добавление функций, улучшение кода, реализация квоты, чтобы мы могли фактически измерять то, что делали наши пользователи, и указывать цену, добавили довольно много вызовов в хранилище таблиц. И хотя это невероятно быстро, если вы знаете, что делаете , они по-прежнему обращаются к внешней системе, которая должна открыть TCP-соединение, выполнить SSL-рукопожатие и так далее. Не так много миллисекунд, но, суммируя их все вместе, они складываются. Итак, как вы узнаете, что происходит? Давайте посмотрим…
Анализ трафика хранилища Azure
В настоящее время нет профилировщика, который позволял бы вам легко отслеживать, какой трафик передается по хранилищу Azure. К счастью для нас, команда Azure добавила способ подключения прокси-сервера между вашим приложением и самим хранилищем. Используя эмулятор хранилища для разработки, мы можем просто изменить строку подключения к хранилищу на следующую и подключить Fiddler:
UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://ipv4.fiddler
Большой! Теперь у нас есть Fiddler для анализа нашего трафика в хранилище Azure. Теперь все запросы, поступающие в службы хранения BLOB-объектов, таблиц или очередей, теперь видны: URL-адрес, результат, время и т. Д.
Картинка выше не из MyGet, а просто для иллюстрации идеи. Вы можете очистить список запросов, загрузить определенную страницу или действие в вашем приложении и увидеть, как звонки поступают в хранилище. И у нас было несколько критических путей, по которым мы сделали более 7 запросов. Если каждое из них составляет в среднем 30 мс, то это 210 мс, чтобы получить некоторые данные. А потом вы даже ничего с этим не сделали … Поэтому мы решили заняться этим в нашем коде.
Еще одна вещь, которую мы заметили при просмотре URL-адресов, заключается в том, что некоторые из этих запросов были отфильтрованы только с использованием хранилища таблиц RowKey, что привело к +/- 2 секундам в обоих направлениях. Это плохо. И поэтому мы также исправили это (в некоторых случаях путем добавления некоторого кэширования, в других — путем реструктуризации способа хранения данных и перемещения нашего фильтра в PartitionKey или комбинации PartitionKey и RowKey, как вы должны ).
Результат этого? Давайте посмотрим на ту картинку выше, где показано наше время отклика: нам удалось резко сократить время отклика, сделав себя счастливыми (мы могли бы убить несколько виртуальных машин), а также наших пользователей, потому что все быстрее.
Простой трюк с отличными результатами!