Re: sample perf info

[Oliver Zeigermann]

The problem used to be that all children information was stored with 
each newly added, not only the newly added. Thus each store operation is 
linear to the size of existing children. So, me saying it is quadratic 
was a bit misleading as adding a single child is only linear in 
complexity. When you store a bunch of children the overall complexity is 
thus quadratic instead of linear (I guess).

The core patch made it to 2.1, but the MySQL store implementation has 
been scheduled for 2.2...

Oliver
Warwick Burrows schrieb:
What was the nature of this patch? And did you say 2.2? Or did you actually
mean 2.1?
Thanks,
Warwick


-----Original Message-----
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 04, 2004 5:13 PM
To: Slide Users Mailing List
Subject: Re: sample perf info

I know with the default store implementations performance for storing 
children is quadratic to their number. In 2.2 Tara has 
donated a patch 
for this, however, this has only been ported for MySQL, yet. Ports to 
other DBs should be very easy, so volunteers step forward :)

Oliver
P.S.: You custom stores may well be linear to the number of 
children or 
even constant...

Darren Hartford schrieb:

Hey all,
Just sharing some information from testing on a p4 
2.8ghz/512ram/win2000/java1.4.2_04 test box with all files 
locally on 

the harddrive.
Using the 2.1M1 binary file defaults for TxFileStore and 
TxXMLFileDescriptors and using Slide's WebDAV client API/libs to 
connect to localhost Slide server:

*injecting 1,000 2kb files average 1/2 second per file (default DAV 
properties only, no new props).

*Doing an exact search (SearchMethod) for a specific file (by 
'displayname' field) when there was only 1,000 records took 
on average 

3 seconds.
*injecting 10,000 2kb files average 1/2 second per file 
(default DAV 

properties only, no new props). Stopped at 7,581 files with 
'out-of-memory' errors.

*Doing an exact search (SearchMethod) for a specific file (by 
'displayname' field) when there was 7,581 records took 104 
seconds the 

first time (and peaked the memory up around 120MB - changed the 
min/max memory previously to 128/512 after injection was failing), 
consecutive searches took 37-38 seconds per search.

*Trying to enable the default Lucene indexer via domain.xml 
broke the 

server startup (I'll be playing with that later).
This is definately not an indication on how Slide will run in 
production, but gives a base from which to measure how 
configuration 

changes can improve performance (and get an idea of what 
newbies like 

me should expect without making any changes).
-D

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]