Предупреждение: если у вас есть претензии к бенчмарку и/или к коду, бенчмарк выложен на Гитхабе, что позволяет вам править баги самим или сообщить о багах автору.
Подробнее о проблеме 10000 соединений: ru.wikipedia.org/wiki/Проблема_10000_соединений
Как с проблемой 10000 соединений через вебсокеты справятся Erlang, Go, Haskell (Snap), Java (Webbit), Node.js (websocket) и Pythin (ws4py)?
Во время бенчмарка каждую миллисекунду запускается новый клиент. Раз в секунду каждый клиент отсылает сообщение с текущим временем на сервер, а сервер отсылает это сообщение назад.
Реализация | Время на подсоединение (среднее) | Латентность (среднее) | Сообщений | Соединений | Таймаутов соединения |
---|---|---|---|---|---|
Erlang | 865ms | 17ms | 2849294 | 10000 | 0 |
Haskell (Snap) | 168ms | 227ms | 1187413 | 4996 | 108 |
Java (Webbit) | 567ms | 835ms | 1028390 | 4637 | 157 |
Go | 284ms | 18503ms | 2398180 | 9775 | 225 |
Node.js (websocket) | 768ms | 42580ms | 1170847 | 5701 | 4299 |
Python (ws4py) | 1561ms | 34889ms | 1052996 | 4792 | 5208 |
Реализации на Питоне и Node.js падали на примерно половине соединений.
Несмотря на то, что ожидалось, что Go порвет Erlang по производительности, латентность была намного выше и на 225 соединениях сервер запрос не обработал.
Java Webbit была темной лошадкой, но в итоге показала результаты лучше, чем Go (157 необработанных подсоединений).
Самое удивительное, что gevent (Python) и node.js перестали работать после 5001 и 4792 соединений соответсвенно, несмотря на то, что и тот и другой были реализованы специально для решения проблемы C10k.
Более детальное описание, код и сырые данные — на GitHub'е: github.com/ericmoritz/wsdemo/blob/master/results.md
Автор: dmitriid