Производительность архитектуры REST для обмена сообщениями Java / C #

Question

В настоящее время у меня есть приложение, которое отправляет XML через сокеты TCP с клиента Windows на сервер Windows.

Мы переписываем архитектуру, и наши серверы будут на Java. Одна из рассматриваемых нами архитектур - это архитектура REST через http. Таким образом, клиенты C # WinForm будут отправлять информацию, используя это. Мы ищем высокую пропускную способность и низкую задержку.

Есть ли у кого-нибудь какие-либо показатели производительности при таком подходе по сравнению с некоторыми другими вариантами взаимодействия клиента C # с сервером Java.

Answer 1

Это не достаточно хорошо определено, чтобы делать какие-либо метрические заявления; насколько велики сообщения, как часто вы обращаетесь к службе REST, это прямой HTTP или вам нужно защитить его с помощью SSL? Другими словами, что вы можете сказать нам о параметрах рабочей нагрузки ?

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

Тем не менее, вы можете сделать некоторые хорошие оценки, просто посмотрев, сколько сообщений вы хотите обменять, потому что время установки TCP / IP часто доминирует в REST. REST предлагает здесь два преимущества: во-первых, время TCP / IP часто доминирует в передаче сообщений, и это довольно хорошо оптимизировано на производственных веб-серверах, таких как Apache или lighttpd; во-вторых, архитектура RESTful повышает масштабируемость за счет исключения состояния сеанса. Это означает, что вы можете свободно масштабировать, используя простой балансировщик нагрузки TCP / IP.

Answer 2

Это будет достаточно быстро, если только у вас не будет очень, очень много одновременно работающих клиентов, которые будут работать на этих серверах. Уничтожение XML ускоряется как в Java, так и в .NET. Если вы используете CLR2 и Java 5 или выше, все будет в порядке. Но, конечно, вам все равно нужно сделать тесты для проверки.

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

И, если вы правильно проектируете свой программный продукт, в очень маловероятной ситуации, когда REST не достаточно, то замена уровня формата сообщений (REST => protobufs) обеспечит вам лучшую производительность передачи с минимальным нарушением.

Но прежде чем вам нужно будет туда отправиться, вы сможете отправить немного денег в Cisco и получить гораздо больше запаса.

Answer 3

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

Как отмечалось в предыдущем посте, недостаточно подробностей, чтобы действительно судить о том, каким будет представление. например

1. Ваша структура / формат сообщений будут такими же, но только по HTTP, а не по необработанным сокетам?
2. вы собираетесь отправлять подмножества данных XML? Обработка больших объемов XML может занимать много памяти (например, если вы используете подход на основе DOM).
3. Какие издержки будет внедрять выбранная вами среда REST (надеюсь, очень мало, но на данный момент мы не знаем).

Лучшее решение - это настроить что-нибудь, скажем, Джерси и потратить некоторое время на тестирование различных сценариев. Если вы реорганизуете решение, стоит потратить несколько дней на изучение производительности (не говоря уже о функциональности, простоте разработки и т. Д.)