Высокая производительность WSO2 CEP на той же JVM

В следующей статье рассказывается об очень высокой производительности WSO2 CEP на той же JVM. Как с помощью CEP запустить другое Java-приложение (основной класс), работающее на той же JVM. то есть, если я запускаю программу Java с помощью команды JAVA, она будет работать на другом jvm, чем CEP runnign jvm.

http://wso2.com/library/blog-post/2013/08/cep-performance-processing-100k-to-millions-of-events-per-second-using-wso2-complex-event/

Я заинтересован в достижении очень высокого показателя TPS. Я думаю, что транспорты websokets и wso2events могут дать мне высокие показатели TPS из поддерживаемого списка транспортных средств CEP. Поэтому я написал примеры генераторов сообщений (java-программы) как для веб-сокетов, так и для wso2events, но мне не удалось достичь показателей TPS, упомянутых в приведенной выше ссылке. Так что здесь может быть проблема с JVM.


person lsc    schedule 05.05.2016    source источник


Ответы (1)


Вышеупомянутая статья написана для старой версии CEP, nFrom CEP 4.0.0 и выше можно настроить для достижения более высокого TPS. Мы рекомендуем вам использовать wso2event, и вам необходимо настроить агент данных протокола thrift и мост данных.

Если для публикации событий в CEP вы используете издатель агента данных Thrift, увеличьте размер QueueSize в файле data-agent-config.xml. Вы можете использовать пример клиента производительности для публикации событий [1]. Файл data-agent-config.xml этого производителя образцов находится в каталоге ресурсов [2].

В зависимости от обработки и запросов siddhi вашего CEP вам, возможно, придется увеличить eventBufferCapacity в data-bridge-config.xml, который находится в каталоге /repository/conf/data-bridge/. Если вы публикуете события из CEP, используйте wso2event publisher и увеличьте QueueSize для /repository/conf/data-bridge/.

Дополнительные сведения см. в Рекомендации по настройке производительности [3]. С другой стороны, настройка экземпляра CEP с очень высоким TPS также приведет к высокой задержке.

[1] https://github.com/wso2/product-cep/tree/master/modules/samples/producers/wso2-event-performance

[2] https://github.com/wso2/product-cep/tree/master/modules/samples/producers/wso2-event-performance/src/main/resources

[3] https://docs.wso2.com/display/CEP400/Performance+Tuning+Recommendations

person Tharik Kanaka    schedule 05.05.2016
comment
Значит ли это, что та же JVM больше не является фактором для новых выпусков CEP? - person lsc; 06.05.2016
comment
Кроме того, эта статья посвящена производительности механизма Siddhi, встроенного в само приложение (источник событий), поэтому они оба работают в одном и том же jvm, тогда как в вашем вопросе вы пробовали автономный продукт CEP с производителем событий в другом jvm. И в новых выпусках для адаптеров событий сделано много оптимизаций производительности, но все же производительность во многом зависит от используемого транспорта (движок siddhi может работать намного быстрее, как предлагается в статье, но он недоиспользуется из-за ограниченной производительности транспорта) - person Rajeev Sampath; 06.05.2016
comment
@RajeevSampath В моей реализации и Java-программа генерации событий wso2, и CEP находятся на одном компьютере. Поэтому мне интересно, смогу ли я запустить оба на одном экземпляре JVM, тогда я смогу получить большую производительность, чем это. Но я не знаю, как запустить java-программу (генератор событий) с той же JVM, на которой работает CEP. Здесь может помочь углеродное приложение. - person lsc; 06.05.2016
comment
@Isc Если вы используете сервер CEP, даже если вы используете ту же JVM, значительного прироста производительности не будет, поскольку события будут публиковаться с использованием протокола бережливости через приемники событий wso2. Как я уже упоминал, настроив агент данных и мост, вы можете достичь более 100 тыс. Другой вариант: вы можете встроить Siddhi в качестве библиотеки в свой код как Rajeev, как указано, что позволит обойти транспортный протокол бережливости. - person Tharik Kanaka; 06.05.2016