On 13 Nov 2003, at 14:19, Martin Holz wrote:
Hello Oliver,
Oliver Zeigermann <[EMAIL PROTECTED]> writes:
- tests need to be run - ports to other major databases. I can do Oracle, but will need help with others
I will try it on Postgres.
To my complete DISMAY performance measurements showed no significant difference to the "untuned" version. *Sigh*
Because this version is cleaned and at least does *not run slower* and some deadlocking spots have already been removed, I proposed to continue on this track.
I am not really surprised, that a SQL store is not faster than a file store, when single nodes are accessed. The file stores keep all information about a node in one place, while the database has to search it from different tables. However I hope the SQL store to be much faster, if you search over many nodes.
yep.
I found, that access control has much impact on performance, since slide has to visit all parent nodes. Without caching enabled for the security store, slide is unusable. Which acces police did you use?
I turned ACL off because I still don't get how slide works in that realm, but I do agree with Martin that without memory caching of those properties, slide would just sink dead.
BTW, did you guys ever considered the use of a lazy pattern for updates? a-la messaging file system?
Basically, you have a memory store that saves in a log file (sort of an equivalent of a messaging file system) some events. the log file is already open and buffered by the OS and the events are small, so this shouldn't be a proble, then in background with a lower priority, a thread 'feeds' the database for backup.
The database is therefore used only as a storage system and as the DASL engine... not used for regular node by node operations (which don't require complex SQL queries anyway and could be handled by simple in-memory object operations)
WDYT?
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
