Hi Leo, Let me add couple of words as well
On Mon, Mar 10, 2014 at 9:16 AM, Sriskandarajah Suhothayan <s...@wso2.com>wrote: > Thanks for you interest in WSO2 CEP & Siddhi > > Sorry for the late reply, I some how missed the mail > > > On Fri, Mar 7, 2014 at 4:48 AM, Leo Romanoff <romix...@yahoo.com> wrote: > >> Hi, >> >> I've started playing with WSO2 CEP recently and after some experiments >> with it I collected a few questions, which I cannot answer by reading the >> docs. Hopefully I'll have them answered by posting them on this list. >> >> First of all, some background information. I have some previous >> experience with Esper and Drools. Currently, I'm mostly interested in using >> Siddhi in embedded mode, i.e. as a library. I could built a few small test >> projects using it without any serious problems. But now I'm trying to >> understand some more complex things about it. >> >> So, here are my questions: >> >> 1) How many rules/queries can be defined in one engine. How does it >> affect performance? >> >> For example, can I define (tens of) thousands of queries using the >> same (or multiple) instance of SiddhiManager? Would it make processing much >> slower? Or is the speed not proportional to the number of queries? E.g. >> when a new event arrives, does Siddhi test it in a linear fashion against >> each query or does Siddhi keep an internal state machine that tries to >> match an event against all rules at once? >> > > SiddhiManager can have many queries, and if you chain the queries in a > liner fashion then all those queries will be executed one after the other > and you might see some performance degradation, but if you have have then > parallel then there wont be any issues. > > >> >> 2) Is it possible to easily disable/enable some queries? >> >> In my use-cases I have a lot of queries. Actually, I have a lot of >> tenants and each tenant may have something like 10-100 queries. Rather >> often (e.g. few times a day), tenants would like to disable/enable some of >> their queries. What is a proper way to do it? Is it a costly operation, >> i.e. does Siddhi need to perform a lot of processing to disable or enabled >> a query? >> Is it better to keep a dedicated SiddhiManager instance per tenant or is >> it OK to have one SiddhiManager instance which handles all those tenants >> with all their queries? >> >> The general norm is, you have to use a SiddhiManager per scenario, where > each scenario might contain one or more queries, with this modal its easy > if any tenant want to add a remove a scenario and it will not affect other > queries and tenants. > > 3) What is the semantics of distributed execution? I have found that >> Siddhi supports it by means of Hazelcast. But what does distributed >> execution means? E.g. what happens when I feed in an event at one of the >> instances? How can this distributed execution be controlled besides >> enabling/disabling it? >> >> Currently Siddhi share its states among its different nodes via > Hazelcast. We are currently working on alternative ways to improve its > distribution capability. > We found hazelcast is too slow for distributed processing. We are working on a storm based model, see "WSO2 CEP/Siddhi Storm Integration" thread some time back. This should come out Q2/Q3. > > 4) What is the semantics of async processing? I have found >> "setAsyncProcessing" method, but what would be the effect of enabling this >> kind of processing as compared to the usual way of operation? What are the >> benefits and what are the drawbacks? When should it be used? >> > > By default Siddhi uses the request thread to do the event processing, but > if you want to handover the data to another thread process then you can > enable async processing. Its useful if you are doing very complex time > consuming process using Siddhi. > If you do this, event are processed by placing them in a queues between any two queries and assigning threads to queries. However, we found often single thread (async model is faster). > >> 5) I figured out that Siddhi can persist its state and later on restore >> it. This is a cool feature, but I'd like to understand better what kind of >> information is being persisted. Is it only events whose processing is not >> finished yet? Does it include a set of queries currently defined in a >> given SiddhiManager? Does it include all of SiddhiManager's settings? What >> kind of information is restored and what kind of information should be >> provided again in addition to restored one? What is a typical situation >> when Siddhi persistence could/should be used? >> >> >> It only stores the state information of the processing, E.g the current > running Avg of the average calculation. This will be used when server > recovers from a failure. > > >> I hope that most of my questions are pretty simple to answer for those, >> who are familiar with Siddhi's architecture and its inner workings. >> >> > Hope these information is very useful. > > > Regards, > Suho > > Thanks, >> Leo >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > > > > -- > > *S. Suhothayan* > Associate Technical Lead, > *WSO2 Inc. *http://wso2.com > * <http://wso2.com/>* > lean . enterprise . middleware > > > *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog: > http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/> twitter: > http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: > http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>* > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- ============================ Srinath Perera, Ph.D. http://people.apache.org/~hemapani/ http://srinathsview.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
