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].
--------------------------------------------------------------------
