jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Girard <wade.gir...@comcast.net>
Subject Re: newb performance question
Date Fri, 06 Jun 2008 14:50:10 GMT
Here is what I am doing/seeing.

As I said before, a brand new install of Jetty, no other third party  
stuff, just what comes with Jetty 6.1.10. I install Jackrabbit 1.4 web  
app and the jcr-1.0 jar file. I start jetty, I go to http://host:8080/jackrabbit-webapp-1.4/

  and select the button to create a new repository.

Next I edit the repository.xml file and add the definition for the  
file data store.

Then I hop on another computer and start cadaver in a terminal, I open  
a connection to http://host:8080/jackrabbit-webapp-1.4/ repository/ 
default, log in using a username and password, then create a "column"  
using cadaver, mkcol views, then I cd into that "column" and "put" a  
bunch of xml files, the output from cadaver looks like:
...
Uploading ComMQSoftwareWASDurableSubscriptionStats.xml to `/jackrabbit- 
webapp-1.4/repository/default/views/ 
ComMQSoftwareWASDurableSubscriptionStats.xml':
Progress: [=============================>] 100.0% of 133087 bytes  
succeeded.
Uploading ComMQSoftwareWASDCSStatsSummary.xml to `/jackrabbit- 
webapp-1.4/repository/default/views/ 
ComMQSoftwareWASDCSStatsSummary.xml':
Progress: [=============================>] 100.0% of 163705 bytes  
succeeded.
Uploading ComMQSoftwareWASDCSStats.xml to `/jackrabbit-webapp-1.4/ 
repository/default/views/ComMQSoftwareWASDCSStats.xml':
Progress: [=============================>] 100.0% of 164067 bytes  
succeeded.
Uploading ComMQSoftwareWASConnectionFactory.xml to `/jackrabbit- 
webapp-1.4/repository/default/views/ 
ComMQSoftwareWASConnectionFactory.xml':
Progress: [=============================>] 100.0% of 161661 bytes  
succeeded.
....
Note that the Progress indicator jumps to 100% very quickly, but does  
not return with "succeeded" until 1 to several seconds have passed.  
The time it takes to upload each file varies, I assume based on file  
size.

The log output from jetty when uploading these files looks like:
...
06.06.2008 09:32:11 *INFO * IndexMerger: merged 1000 documents in 110  
ms into _cdr. (IndexMerger.java, line 304)
06.06.2008 09:32:16 *INFO * IndexMerger: merged 924 documents in 110  
ms into _cel. (IndexMerger.java, line 304)
06.06.2008 09:32:16 *INFO * IndexMerger: merged 1000 documents in 125  
ms into _cem. (IndexMerger.java, line 304)
06.06.2008 09:32:16 *INFO * IndexMerger: merged 1000 documents in 125  
ms into _cen. (IndexMerger.java, line 304)
06.06.2008 09:32:30 *INFO * IndexMerger: merged 890 documents in 110  
ms into _ch1. (IndexMerger.java, line 304)
06.06.2008 09:32:30 *INFO * IndexMerger: merged 1000 documents in 125  
ms into _ch2. (IndexMerger.java, line 304)
06.06.2008 09:32:30 *INFO * IndexMerger: merged 1000 documents in 110  
ms into _ch3. (IndexMerger.java, line 304)
....
I do not see output like this in the log files when I am putting/ 
getting jpg, png, or other file types that I have been using other  
than xml.

I get similar results when I "get" these same files from the  
repository, also using cadaver.

I have also observed that the file sizes of these files is larger  
after I "get" them using cadaver. So I assume that jackrabbit is  
mucking with them somehow.

If all I need to do to get consistent behavior is to tell jackrabbit  
to treat all files as binary, then it would be nice to have that as an  
option in the repository.xml file. Is this possible?

Thanks,
Wade

On Jun 6, 2008, at 9:22 AM, Marcel Reutegger wrote:

> Wade Girard wrote:
>> It is still slow, now the messages that I am seeing in the log are
>> *INFO * IndexMerger: merged xxx documents in yyy ms into _aka.  
>> (IndexMerger.java, line 304)
>> Where xxx is a number, usually 1000 and yyy is a number between 100  
>> and 2700
>
> the IndexMerger runs in a background thread and does not have an  
> immediate effect on the performance you see when you call JCR API  
> methods.
>
> regards
> marcel

Wade Girard
wade.girard@gmail.com






Mime
View raw message