2015-01-24 1 views
2

Надеюсь, что ниже объясняется моя проблема.Как сделать масштаб роли рабочей среды Azure, если ожидание потока занято?

У меня есть рабочая роль, которая работает в течение (истинного) цикла. Этот рабочий снимает сообщения с очереди и обрабатывает их. Он никогда не заканчивается, просто проверяет очередь и обрабатывает сообщения.

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

Что я хочу - это решение, которое либо остановит, либо смягчит это из-за происходящего.

Мое настоящее настоящее мировое решение состоит в том, что у меня есть рабочая роль, которая использует параллельную библиотеку задач для создания нескольких процессоров сообщений, которые работают параллельно и берут из очереди. Но эта проблема может возникнуть, если все потоки, на которых работают мои обработчики сообщений, застревают в ожидании службы.

Я знаю, что я должен использовать async-запросы для служб, но есть и другие примеры, где async не поможет. Я бы предпочел не вдаваться в подробности.

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

Эта рабочая роль теперь не будет иметь ситуации, когда застрял в ожидании чего-то.

Но я не доволен этим. Что делать, если моя рабочая роль, использующая параллельную библиотеку задач для создания нескольких процессоров очереди, недостаточно быстра. Я не думаю, что процессор будет даже подчеркивать, потому что замедление будет заключаться в получении сообщения и отправке его в веб-службу, причем не интенсивность процессора.

Так что мне нужно БОЛЬШЕ процессоров очереди, которые должны быть созданы путем нереста экземпляров моего процессора очереди, исходя из того, насколько занята моя очередь. Поэтому, когда в очереди много элементов, Azure создаст новый экземпляр, который поможет мне обработать их.

Я не уверен в этом решении. Я чувствую, что это должно быть проще. Почему теперь я создаю веб-службу для потребления сообщений, которые отправляются из рабочей роли, которая, в свою очередь, масштабируется на основе моей очереди сообщений.

Имеет ли мое решение смысл или есть альтернативы?

+0

Async IO не имеет никакого значения здесь, поскольку ваша степень параллелизма довольно мала (например, десятки параллельных сообщений). Не проблема, чтобы потоки «застревали», пока существует достаточно потоков. – usr

+0

Я не понимаю, в чем проблема. Не можете ли вы просто создать N потоков/асинхронных задач, чтобы вытащить из очереди? Есть ли конкретная проблема с этим? Загрузка процессора, по-видимому, не является проблемой для вас. Если загрузка процессора не является проблемой, вам не нужно масштабировать до большего количества процессоров. – usr

+0

Я думаю, что: A. Вы должны опубликовать свой код B. Измерение, измерение, измерение. –

ответ

2

Посмотрите на причину вам нужно масштабировать

Гипотетически, скажем, этот запрос занимает 10 секунд. Теперь моя рабочая роль находится в середине моего цикла, ожидающего ответа. Тем временем очередь сообщений заполняется.

Проблема заключается не столько в том, что работник занимает много времени, а скорее очереди получает резервное копирование - это именно то, почему Azure предлагает масштабирование варианты, которые включают в себя размер очереди.

Кроме того, если ваши услуги имеют интенсивность процессора, тогда масштабирование только распространяет проблему на несколько экземпляров - это всего лишь вопрос времени, прежде чем вы столкнетесь с тем же узким местом.

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

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

  • Нет связанных вопросов^_^