При какой максимальной скорости webjob может обрабатывать сообщения о хранении очереди?

Я работаю над локальной средой разработчиков с помощью проводника хранилища (подключен к локальному эмулируемому хранилищу), и мой веб-сайт запускается в новых сообщениях очереди. Для тестирования я публикую 100 сообщений очереди и моя функция webjob выводит значение счетчика в журнале консоли:При какой максимальной скорости webjob может обрабатывать сообщения о хранении очереди?

 Interlocked.Increment(ref counter); 
     log.WriteLine($"counter: {counter}");

(счетчик является статическим ИНТ)

Это займет 30 секунд, чтобы пройти через 100 сообщений. Ожидается ли скорость/скорость? Есть ли способ сделать это быстрее, учитывая, что операция функции довольно проста и не записывается в DB/table?

Я отправляю это в отношении к моему первоначальному вопросу, к которому в настоящее время нет никакого решения: Slow azure queue webjob performance (local dev)

источник

2017-02-20 Alex E

Вы работаете против локального эмулятора хранилища? Или вы работаете локально с фактической очередью хранения Azure? –

работает локально против эмулятора памяти –

Это зависит от размера вашего сообщения, конечно, но я подозреваю, что инфраструктуру и аппаратное обеспечение играет определенную роль , Какой план обслуживания приложений работает на вашем веб-сайте и насколько велики ваши сообщения?

Согласно документации https://docs.microsoft.com/en-us/azure/storage/storage-performance-checklist#queues

Одна очередь может обрабатывать около 2000 сообщений (1kB каждая) в секунду (каждый AddMessage, GetMessage и DeleteMessage рассчитывать как сообщение здесь).

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

источник

2017-02-20 17:47:14

Хмм Donwnvote, но без комментариев. Не могу узнать об этом –

Привет, Питер, я не сделал ни одного комментария к вашему комментарию. Когда я в последний раз просмотрел ответы, я обнаружил, что это был мой вопрос, который был занижен из-за отсутствия исследований и т. Д. Я думаю, что ваш ответ имеет хорошую информацию, по крайней мере, для моих целей, потому что теперь я знаю, что пропускная способность обработки очереди/webjob при ее развертывании к Лазуру. Основываясь на ответе Роба, кажется, что моя работа страдает, потому что я разрабатываю/тестирую все локально, а эмулятор памяти работает на Ms SQL. Я проверю свою производительность после развертывания приложения в Azure. –

Локальный эмулятор хранилища никоим образом не указывает на производительность, которую вы увидите против реальной очереди хранения Azure. В локальном эмуляторе хранилища используется локальный экземпляр SQL Server, который создается за кулисами, чтобы имитировать службы хранения. Это медленное сравнение. Он также имеет ограниченную поддержку параллелизма.

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

источник

2017-02-20 20:58:45

При какой максимальной скорости webjob может обрабатывать сообщения о хранении очереди?

ответ

Смежные вопросы