[Topaz-dev] Mulgara Performance Woes
Andrae Muys
andrae at netymon.com
Sat Mar 1 04:05:20 PST 2008
On 01/03/2008, at 7:49 AM, Russell Uman wrote:
>> This is why having a large acceptCount is better. In fact, you may
> want to cut down the number of threads to, say, 10, and just make >
> the
> acceptCount very large (2000?). If a client drops the connection
> before
> it's been accepted, then no Session is allocated and it > won't get
> the
> write-lock and then wait for it to time-out.
>
> yes. we've been discussion ways to get long running pub-app
> sessions to
> timeout WITHOUT opening and orphaning a mulgara session. some way for
> the pub-app to check how long it's been running when it's woken up and
> before it opens a session.
>
> if mulgara is single-threaded, why have 10 maxThreads? why not 1 or 2?
> (i'm sure it's a bad idea, i just don't know why :)
Mulgara is definitely not single-threaded. Every insert/delete/query/
setAutocommit/etc call is handled by a separate thread; Jotm, which
is used internally to manage transactions, runs several; several are
spawned for every update operation to handle the IO; and of course
the JVM runs several threads for its own mysterious purposes.
Mulgara places only two restrictions on concurrent access. First the
Session object is non-reentrant, so if you want to perform multiple
operations in parallel you have to use a separate session for each
operation. Second only one session at a time can be accessing the
'current' (ie. uncommitted) phase, and this is enforced via the write-
lock --- as many sessions as you like can access the 'committed'
phase, but that phase is strictly read-only.
To be perfectly honest 10 threads seems rather small, I would expect
3-4 for the JVM; 3-4 for JOTM; ~10 for the block-buffer and object-
pool; and 1 thread per active concurrent Session.
Now I'm about to go black for a couple of days while I make my way to
your fair city - maybe we'll get a chance to talk about this stuff
when I get there.
Ciao.
Andrae
--
Andrae Muys
andrae at netymon.com
Senior RDF/SemanticWeb Consultant
Netymon Pty Ltd
More information about the Topaz-Dev
mailing list