Very well,
here is the template for a time based stream, the only upper-case names
will be substituted
by the program to create individual streams, timestamp is on single
ordered fact that contains
the systems timestamp which will be updated every 100 ms.jess_stockevent
is the JESS
representation of the Java bean, the stream will be created depending on
the stockname string
of the Java bean.
Here you can see the results:
http://www.betonesel.net/JESS-length-tests-19-20.pdf
The first table is from a length based stream which works fine, the next
three are from time based
streams, as described before with
NO_OF_STREAMS NO_OF_INSERTS_PER_SECOND RUNTIME_IN_SECONDS
So for example the 2nd one : "Time 80 10 300" means 80 streams with 10
events per second for 300
seconds. ( In this caseonly time based)
The time windows are between 15 and 30 seconds.
I would be also very grateful if you could give me any suggestions on
how to optimize the engine
for constant running,if necessary or possible.
; ---------------------------------------------------------
; TIME based stream TEMPLATE
; ---------------------------------------------------------
;
; ---------------------------------------------------------
; template for automatic stream moving rule genereation
( defrule STREAMNAME_move
?jse<-( jess_stockevent
(timestamp ?ts )
(stockid ?id )
(stockname NAMERSTR )
(price ?p ) )
?ses<-( STREAMNAME-stats
(count ?c)
(sum ?s)
; (last ?l) only for length based necessary
)
=>
( assert ( STREAMNAME
( id ?id )
( price ?p )
( timestamp ?ts )
( name NAMERSTR )
))
( retract ?jse )
( modify ?ses
(count (+ ?c 1 ))
(sum (+ ?s ?p ))
(avg (/ (+ ?s ?p) (+ ?c 1) )) )
)
; template for automatic time stream sanitation
( defrule STREAMNAME_sanitize
(timestamp ?st)
?se<- ( STREAMNAME
(timestamp ?t1&:(> (- ?st ?t1) RESTRICT ))
(price ?p ) )
?ses<-( STREAMNAME-stats
(count ?c)
(sum ?s) )
=>
( retract ?se )
( modify ?ses
(count (- ?c 1 ) )
(sum (- ?s ?p ) )
(avg (/ (- ?s ?p) (- ?c 1) ) ) )
)
Peter Lin wrote:
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].
--------------------------------------------------------------------
--------------------------------------------------------------------
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].
--------------------------------------------------------------------
