without a sample of the rules, it's difficult to know what is happening. peter
On Wed, Feb 18, 2009 at 6:21 PM, Lars Ermert <[email protected]> wrote: > Hello, > i am currently writing a paper about the applicability of JESS as a > Event Stream Processing Engine to evaluate its usefulness as a solution > in such an environment. > > I emulate event streams by generating a certain number of different fact > types via deftemplate and insert facts of these types directly from JAVA > as a JavaBean into the engine. Before the engine is started via > RunUntilHalt(), rules are defined for every fact type which wait for the > occurrence of such a fact, and if one is found, create a new fact named > stream-facttypename (also deffed in advance), adds a time stamp and > inserts the data from the original fact which consists just of the name, > an id and a float value while retracting the original fact. > Every stream has a size restriction, half the streams are restricted by > a maximum stream length, the others by a time window. To enforce these > restrictions another rule per stream is added to remove deprecated facts > from the stream. > > Now i need to evaluate the performance of the whole system. While > everything works fine and the events are moved to the respective > streams and purged according to the streams restriction, i have some > problems with the performance. > > The pdf document provided by this link : > > http://www.betonesel.net/JESS-testreihe-800EPS-p17-19.pdf > > shows the results of the tests. > > For the first charts a fact per second number of 800 was assumed and > inserted in different ways. > The line after Chart X means: I "number of event types" "number of > insertions per second" "runtime of test in seconds" > Half of the event/fact types will be collected in time restricted > streams, half in length restricted. > "number of insertions per second" means how often per second will an > event be generated for every event type, so for 5 events and a 5 > insertions per second 25 events will be generated per second. Unassigned > events means how many events are in the knowledge base which > have not been moved to their streams. Low numbers are due to the > interruption of the processing, large number show the congestion of the > system ( CPU, memory?!?! ) > The red graph shows the CPU usage of the engine thread alone. > > The JAVA Heap was set to sufficient 768MB, which is never used > completely as the blue line shows (belongs to left Y-Axis) > > CHART 4 shows that with 800 fact types/streams and one insertion per > second everything works fine while a bit rough > > CHART 1 if we try it the other way around with 100 types and 8 > insertions per second the whole system breaks down > > CHART 2+3 show different versions of the same problem with 800 events > per second > > CHART 5+6 try to use the same insert per second value but lower the > number of streams/facts. while it happens a bit later with less events > per second, sooner or later the engine will suddenly need more CPU time > and finally max out > > Can you give me any suggestions why this might happen? > > I know it is difficult to say without the source code and more knowledge > about the exact proceedings, but before i delve into it with more detail > i was wondering if you could give me any hints on how to optimize the > engine for this kind of task. > > It does not seem to be a problem with the removal rules which have been > optimized several times while improving the overal processing speed. > > Is it possible that the constant addition of new facts is a problem for > JESS? No new rules are added during runtime yet. > > Sincerely > Lars Ermert > > > > > > -------------------------------------------------------------------- > To unsubscribe, send the words 'unsubscribe jess-users [email protected]' > in the BODY of a message to [email protected], NOT to the list > (use your own address!) List problems? Notify [email protected]. > -------------------------------------------------------------------- > > -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [email protected]' in the BODY of a message to [email protected], NOT to the list (use your own address!) List problems? Notify [email protected]. --------------------------------------------------------------------
