С предстоящим выпуском Cometd-2.0.0 пришло время опубликовать некоторые из наших собственных лжи, проклятых лжи и тестов . Прошло более двух лет с тех пор, как мы опубликовали 20 000 причин, по которым Cometd масштабируется, и за это время мы полностью переделали и клиентскую, и серверную стороны Cometd, плюс мы перешли на Jetty 7.1.4 из eclipse в качестве основного веб-сервера для cometd.
Cometd — это платформа подписки для публикации, которая доставляет события с помощью технологий push- сообщений комет- сервера с HTTP-сервера в браузер. Cometd-1 был разработан параллельно с разработкой многих идей и техник для кометы, поэтому кодовая база отразила некоторые измененные идеи и старое мышление, которые нуждались в очистке. Cometd-2 полностью переработал все части кодовой базы java и javascript и предоставляет:
- Улучшенный Java API для взаимодействия на стороне клиента и сервера.
- Улучшенный параллелизм в базе кода сервера и клиента.
- Полностью подключаемые транспорты
- Поддержка транспорта веб-сокетов (который работает с последними браузерами Chromium ).
- Улучшенные расширения
- Более всестороннее тестирование и примеры.
- Более изящная деградация при экстремальных нагрузках.
Результатом стало резкое увеличение пропускной способности при сохранении задержек менее секунды и отличной масштабируемости.
На приведенной выше диаграмме показаны предварительные результаты недавнего сравнительного анализа, проведенного Симоной Борде для сервера чата на 100 комнат. Тест проводился на узлах Amazon EC2 с 2 процессорами amd64 и 8 ГБ памяти, работающими под управлением Ubuntu Linux 2.6.32 с JVM Sun 1.6.0_20-b02. Симона провела некоторую настройку java-кучи и сборщика мусора, но операционная система не была настроена иначе, как для увеличения ограничений дескриптора файла. В тесте использовался транспорт с длинным опросом HTTP. Использовался один серверный компьютер, и 4 идентичные машины использовались для генерации нагрузки с использованием Java-клиента Cometd, который входит в состав выпуска Cometd.
Стоит помнить, что измеренные задержки / пропускная способность включают время в генераторе клиентской нагрузки, каждый из которых запускает полный стек HTTP / cometd для многих тысяч клиентов, когда в реальном развертывании у каждого клиента будет компьютер / браузер. Также следует отметить, что сервер является не просто выделенным комет-сервером, но и полнофункциональным контейнером Jetty Java Servlet, а сообщения cometd обрабатываются в предоставленном расширенном контексте приложения.
Из приведенной выше диаграммы видно, что скорость сообщений значительно улучшилась по сравнению с 3800 с / с, достигнутыми в 2008 году. Все протестированные сценарии могли достигать 10000 сообщений в секунду с отличной задержкой. Только с 20 000 клиентов средняя задержка начала быстро расти, когда скорость передачи сообщений превысила 8000 / с. Максимальная средняя загрузка ЦП сервера составила 140/200, и в большинстве случаев задержки в сети Amazon составляли менее 100 мс, что указывает на наличие некоторой дополнительной емкости для этого сервера. Наш опыт работы с Cometd в дикой природе показывает, что можно ожидать еще одну задержку в сети от 50 до 200 мс, пересекающую общедоступный Интернет, но из-за асинхронной конструкции Cometd дополнительная задержка не снижает пропускную способность.
Ниже приведен пример необработанного вывода одного из 4 генераторов нагрузки, который демонстрирует некоторые возможности клиента java cometd, которые можно использовать для разработки генераторов нагрузки, специфичных для вашего собственного приложения:
Statistics Started at Mon Jun 21 15:50:58 UTC 2010
Operative System: Linux 2.6.32-305-ec2 amd64
JVM : Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM runtime 16.3-b01 1.6.0_20-b02
Processors: 2
System Memory: 93.82409% used of 7.5002174 GiB
Used Heap Size: 2453.7236 MiB
Max Heap Size: 5895.0 MiB
Young Generation Heap Size: 2823.0 MiB
- - - - - - - - - - - - - - - - - - - -
Testing 2500 clients in 100 rooms
Sending 3000 batches of 1x50B messages every 8000µs
- - - - - - - - - - - - - - - - - - - -
Statistics Ended at Mon Jun 21 15:51:29 UTC 2010
Elapsed time: 30164 ms
Time in JIT compilation: 12 ms
Time in Young Generation GC: 0 ms (0 collections)
Time in Old Generation GC: 0 ms (0 collections)
Garbage Generated in Young Generation: 1848.7974 MiB
Garbage Generated in Survivor Generation: 0.0 MiB
Garbage Generated in Old Generation: 0.0 MiB
Average CPU Load: 109.96191/200
----------------------------------------
Outgoing: Elapsed = 30164 ms | Rate = 99 messages/s - 99 requests/s
Waiting for messages to arrive 74450/75081
All messages arrived 75081/75081
Messages - Success/Expected = 75081/75081
Incoming - Elapsed = 30470 ms | Rate = 2464 messages/s - 2368 responses/s (96.14%)
Messages - Wall Latency Distribution Curve (X axis: Frequency, Y axis: Latency):
@ _ 56 ms (19201, 25.57%)
@ _ 112 ms (33230, 44.26%) ^50%
@ _ 167 ms (10282, 13.69%)
@ _ 222 ms (3438, 4.58%) ^85%
@ _ 277 ms (2479, 3.30%)
@ _ 332 ms (1647, 2.19%)
@ _ 388 ms (1462, 1.95%) ^95%
@ _ 443 ms (971, 1.29%)
@ _ 498 ms (424, 0.56%)
@ _ 553 ms (443, 0.59%)
@ _ 609 ms (309, 0.41%)
@ _ 664 ms (363, 0.48%)
@ _ 719 ms (338, 0.45%) ^99%
@ _ 774 ms (289, 0.38%)
@ _ 829 ms (153, 0.20%) ^99.9%
@ _ 885 ms (46, 0.06%)
@ _ 940 ms (3, 0.00%)
@ _ 995 ms (1, 0.00%)
@ _ 1050 ms (1, 0.00%)
@ _ 1105 ms (1, 0.00%)
Messages - Wall Latency Min/Ave/Max = 1/120/1105 ms
Messages - Network Latency Min/Ave/Max = 1/108/1100 ms
Если позволит время, мы хотели бы обновить наш Java-клиент, чтобы он также поддерживал протокол websocket, чтобы мы также могли генерировать нагрузку из 20 000 клиентов websocket и посмотреть, как этот новый протокол может еще больше повысить пропускную способность и задержку.
От http://blogs.webtide.com/gregw/entry/cometd_2_throughput_vs_latency