Hi, >Let me guess, you're storing all nodes under the same parent node? See >the second question in http://wiki.apache.org/jackrabbit/Performance.
Not really, but it wasn't as good as it could be, I had 2 nodes with nearly 9000 child nodes. So I've changed my test, creating a separate subnode each 100 nodes (topnode/subnode/childnode). This helped a little bit. I've stored 26000 nodes and the performance is now relatively stable at 6-7 nodes per second (currently it takes 16 seconds to store 100 nodes). Kindly regards, Robert -----Ursprüngliche Nachricht----- Von: Jukka Zitting [mailto:[email protected]] Gesendet: Donnerstag, 16. September 2010 13:20 An: [email protected] Betreff: Re: my managers are against jackrabbit Hi, On Thu, Sep 16, 2010 at 2:12 PM, Seidel. Robert <[email protected]> wrote: > It starts quite well, but after storing a couple of nodes (10.000 or so), the > speed > drastically decreases. Let me guess, you're storing all nodes under the same parent node? See the second question in http://wiki.apache.org/jackrabbit/Performance. >>> o If the database crashes, then everything is lost - you have to recover >>> from >>> database backup and store the work of the day again > >> You can use clustering for high availability. > > But it doesn't help, if the central database crashes, that all nodes are using > (bundled database persistence manager). The central database should also be clustered. > I've tested using only one random ASCII String with 5 characters and about 10 > other > properties per node with exactly the same values (some small strings) and the > index > (repository and workspace together) was about 50 MB for 20000 nodes. That's about 2-3kB per node, which seems reasonable especially if they are versionable (i.e. the version history is also indexed). BR, Jukka Zitting
