Этот вопрос на самом деле не имеет легкого ответа, поскольку он в значительной степени зависит от характера выполняемой работы и от необходимости быстрого развертывания и/или требований для управления средой на машине. Я согласен с тем, что роль рабочего в облачных сервисах - это хороший вариант для просмотра, однако вы также можете выполнить эту работу с использованием веб-сайтов Windows Azure с новой функцией «всегда включен», которая была анонсирована на прошлой неделе. Вы можете написать веб-приложение, которое тянет задания с фоновым потоком и при необходимости создает новые потоки. Подход веб-сайтов, скорее всего, будет работать лучше всего в стандартном режиме, когда вам предоставляется выделенная виртуальная машина, но в этот момент лучше всего перейти на маршрут облачных служб. Облачные услуги немного дешевле в час, чем веб-сайты в стандартном режиме для машины того же размера; однако веб-службы предлагают более быстрый механизм развертывания. На вопрос есть много вопросов, прежде чем я скажу, что один из них лучше для вас. Пока мы предположим, что вы переходите по пути к роли «Рабочий» в облачных службах.
В идеале вы хотите как можно больше использовать каждую машину без полного ее максимизации, прежде чем вы начнете использовать другой экземпляр. Если ваши рабочие места связаны с тяжелым процессором, тогда, если на коробке имеется всего несколько ядер, вы не сможете обрабатывать столько рабочих мест одновременно на одной машине. Работы задания с привязкой к процессору должны выполняться как можно быстрее, но все процессоры привязаны на 100%, и больше рабочих мест на одной машине не поможет после использования всех ЦП. Thrashing начинает происходить, поскольку все задания конкурируют за процессор. В этом случае использование нескольких экземпляров поможет вам масштабировать. Однако, если у вас есть связанное с IO задание, то что-то, что читает/записывает в базу данных, хранилище BLOB и т. Д., Тогда центральный процессор в основном неактивен, и поэтому вы можете обрабатывать LOT этих типов заданий на одной машине до тех пор, пока вы насыщаете емкость сети.
Вы упомянули, что каждая нить может иметь другую «работу», что означает, что она может иметь разные характеристики, что, в свою очередь, делает решение немного сложнее. Самое лучшее, что я могу сказать, - начать измерять характеристики каждого задания, связано ли это с CPU, привязкой IO и т. Д. И посмотреть на то, что имеет наибольший смысл. Это может означать, что вы идентифицируете задания, которые являются тем или иным типом, и сегментируйте их так, чтобы привязанные к IO задания выполнялись только на одном наборе рабочих, в то время как CPU привязывал один запуск к другому набору. Это позволит вам масштабировать их самостоятельно.
Вы также можете увидеть, как вам помогут многоядерные машины; обратите внимание, что масштабирование довольно линейно, так что 2-ядерный ящик стоит вдвое меньше, чем 4-ядерный ящик. Таким образом, хотя наклон может состоять в том, чтобы получить самую большую коробку, если вы в конечном итоге нуждаетесь в 10 ядрах, чтобы выполнить эту работу, было бы лучше иметь десять 1 базовый экземпляр, а не три ядро с четырьмя ядрами, потому что вы получите более тонкий зерно масштабируемости, и если одна машина выходит в автономный режим, вы не теряете столько возможностей. Я укажу, что чем больше поле, которое вы выбираете, тем больше емкость сети вы также назначаете, поэтому, если ваше узкое место является пропускной способностью сети, вам понадобится больший бокс.
Независимо от того, что вы делаете, не просто запускайте один поток в роли рабочего и масштабируйте его по мере необходимости.Вероятно, это будет полная трата ресурсов. Измерить свои рабочие нагрузки и принять наилучшее решение для вашего сценария.
Очень подробный и полезный ответ. – AsValeO