Каков наилучший способ масштабирования работы на нескольких машинах?

Question

Мы разрабатываем .NET-приложение, которое должно выполнять до десятков тысяч небольших вызовов веб-сервиса стороннему веб-сервису.Мы бы предпочли более "объемный" вызов, но третья сторона его не поддерживает.Мы спроектировали клиент так, чтобы он использовал настраиваемое количество рабочих потоков, и в результате тестирования получили код, который довольно хорошо оптимизирован для одной многоядерной машины.Тем не менее, мы по-прежнему хотим повысить скорость и рассматриваем возможность распределения работы между несколькими машинами.Мы хорошо разбираемся в типичных приложениях клиент / сервер / база данных, но новички в проектировании для нескольких машин.Итак, несколько вопросов, связанных с этим:

• Есть ли какая-либо другая оптимизация на стороне клиента, помимо многопоточности, на которую нам следует обратить внимание, которая могла бы улучшить скорость http-запроса / ответа?(Я должен отметить, что это нестандартный веб-сервис, поэтому реализован с использованием WebClient, а не клиента WCF или SOAP)
• В настоящее время мы думаем использовать WCF для публикации фрагментов работы в MSMQ и запуска клиентов на одной или нескольких машинах, чтобы удалить работу из очереди.У нас есть опыт работы с WCF + MSMQ, но мы хотим быть уверены, что не упустили лучшие варианты.Есть ли другие, лучшие способы сделать это сегодня?
• Я видел некоторые сторонние инструменты, такие как DigiPede и предложения Microsoft для HPC, но они кажутся излишними.Есть какой-нибудь опыт работы с этими продуктами или причины, по которым мы должны рассмотреть их вместо того, чтобы выпускать самостоятельно?

Answer 1

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

Обязательно посмотрите на свой ограничения на подключение на стороне клиента.По умолчанию, я думаю, системное значение по умолчанию равно 2 соединениям.Я сам этого не пробовал, но, увеличив количество подключений с помощью этого свойства, вы теоретически должны увидеть эффект мультипликатора с точки зрения генерации большего количества запросов за счет генерации большего количества подключений с одной машины.Там есть Подробная информация на форумах MS.

Опция MSMQ работает хорошо.Я сам запускаю эту конфигурацию.ActiveMQ также является прекрасным решением, но MSMQ уже находится на сервере.

У вас есть хорошая отправная точка.Запустите это в работу, затем переходите к производительности и пропускной способности.

Answer 2

В этом году на CodeMash Уэсли Фалер сделал интересную презентацию по такого рода проблемам.Его решение состояло в том, чтобы хранить "задания" в базе данных, затем использовать клиентов для сворачивания работы и отметки статуса по завершении.

Затем он перенес всю инфраструктуру на Amazon EC2.

Вот его слайды из презентации - они должны дать вам основную идею:

Я делал нечто подобное на нескольких компьютерах локально - основы управления рабочей нагрузкой были аналогичны подходу Фалера.

Answer 3

Если вы оптимизировали код, вы могли бы рассмотреть возможность оптимизации сетевой части, чтобы свести к минимуму количество отправляемых пакетов:

• повторное использование HTTP-сеансов (т.е.:несколько транзакций в одном сеансе за счет сохранения соединения открытым сокращает накладные расходы TCP)
• сократите количество HTTP-заголовков в запросе до минимума, чтобы сэкономить пропускную способность
• если поддерживается сервером, используйте gzip для сжатия тела запроса (необходимо сбалансировать загрузку процессора для выполнения сжатия и экономию пропускной способности).

Answer 4

Возможно, вы захотите рассмотреть Служебный автобус Rhino вместо MSMQ.Источник доступен здесь.