1) Call (set-node-index-hash 13) -before- loading the rules. This
reduces the size of the Rete memories' hashtables, and will conserve
memory -if- the number of partial matches tends to be smallish. You
can try other small primes besides 13. The default is 101. The
potential savings here is (101-13)*4 bytes*2 memories*3 patterns*200
rules is ~0.4M per Rete object.
2) Try Jess 6.0a3, which has a new architecture that shares some the
standard function objects across all Rete instances. Future versions
of 6.0, as I work towards including modules, will give you the ability
to share more data across Rete instances. In this particular case all
of the Defclasses amd Deftemplates could be shared.
I think Lucero, Michael wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Jess users,
>
> I have a web application running a pool of Rete objects on the
> server. Each new user session retrieves a Rete object from the pool and
> uses it as a rules engine for the duration of the session - the engine must
> be 'stateful' for the life of that session.
>
> This design appears to be prohibitive due to the memory footprint of
> the rules engine.
>
> My rule set contains approximately 200 rules, 150 defclasses and
> deftemplates, 10 defglobals. The engine, with only the rules and about 10
> initial facts, is about 2 MB. The Rete Object itself, without my rules,
> appears to be about 700K (does that sound right?).
>
> Each rule, on average, contains 3 patterns - I've paid close
> attention to the guidelines I've read on writing rules that will
> pattern-match efficiently, and sharing of input nodes. The defclasses
> contains 11 - 16 slots. Rules that match on definstances of these facts
> only care about 4 or 5 of those slots. There is some use of inheritance
> between deftemplates and defclasses.
>
> I am using Jess 5.1, JDK 1.1.8, on Windows NT.
>
> At 2 MB per session just at initialization, the server will
> certainly run into memory problems with any kind of moderate load .
>
> I've read through various threads on this list where the trade of
> 'speed for space'. Indeed, the performance I'm seeing for each run() of the
> engine is excellent, but the memory usage is not feasible.
>
> I've read about the alternative of using 1 rules engine with
> session-specific facts, but it is too late for me to explore that option
> (plus, the saturation issue and need to cleanup the session-specific
> facts worry me).
>
> I'm looking for any suggestions to cut down the memory footprint.
> Even pointing me to threads on this mailing list I might have missed would
> be appreciated.
>
> Thanks,
> Michael Lucero
>
>
>
> ---------------------------------------------------------------------
> 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]
> ---------------------------------------------------------------------
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
