On 16.03.2015 01:50, Bert Huijben wrote:
>> -----Original Message-----
>> From: Marc Strapetz [mailto:marc.strapetz_at_syntevo.com]
>> Once the log responds, a bunch of revisions are reported, so it seems
>> that there is some kind of caching of log records.
>>
>> I've tested with latest 1.9.x sources on Windows but have seen the same
>> behavior with javahl-1.8-extensions branch on Linux, too.
>
> I can only find a server side buffering... But this might explain what you see.
>
>
> Our server reports use an apr feature that buffers +- 8 KByte data before sending out the first data.
>
>
> In this specific JavaHL case you ask for just the revision numbers. (Unlike the C api, JavaHL's session.getLog() appears to handle a null list of revision properties as no revision properties. Not the standard set!)
>
> I think every revision would (encoded in our Xml protocol) cost about 70 bytes, so there would fit at least 100 revisions in that buffer.
That's it! I now ran my previous example as it was (3 times) and it took
average 19s until the first revision was reported.
With discoverPath set to true, time until first response dropped to
average 7s.
With discoverPath set back to false, but revisionProperties set to
"svn:log", time until first response is 1.5s - 2s -- so timings like the
command line client!
Regarding your patch, it could make sense to stop doubling
next_forced_flush at a certain limit (say 128), if the sent log records
are small, i.e. if discoverPath=false and revisionProperties = null .
-Marc
On 16.03.2015 01:50, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Marc Strapetz [mailto:marc.strapetz_at_syntevo.com]
>> Sent: vrijdag 13 maart 2015 20:34
>> To: dev_at_subversion.apache.org
>> Subject: 1.9.x JavaHL: long initial delay when performing a log
>>
>> I'm experiencing a strange initial delay when performing a log using JavaHL.
>>
>> svn log http://svn.apache.org/repos/asf/subversion/branches/1.8.x
>>
>> shows first results after 2-3 seconds, while following code snippet
>> takes at least 20 seconds (sometimes significantly more, might depend on
>> the server's load):
>>
>> ISVNRemote session =
>> factory.openRemoteSession("http://svn.apache.org/repos/asf");
>>
>> List<String> paths =
>> Collections.singletonList("subversion/branches/1.8.x");
>>
>> session.getLog(paths, Revision.SVN_INVALID_REVNUM, 0, 0, false,
>> false, false, null, new LogMessageCallback() {
>> public void singleMessage(Set<ChangePath> changedPaths,
>> long revision, Map<String, byte[]> revprops, boolean hasChildren) {
>> System.out.println("DATA");
>> }
>> });
>>
>> Once the log responds, a bunch of revisions are reported, so it seems
>> that there is some kind of caching of log records.
>>
>> I've tested with latest 1.9.x sources on Windows but have seen the same
>> behavior with javahl-1.8-extensions branch on Linux, too.
>
> I can only find a server side buffering... But this might explain what you see.
>
>
> Our server reports use an apr feature that buffers +- 8 KByte data before sending out the first data.
>
>
> In this specific JavaHL case you ask for just the revision numbers. (Unlike the C api, JavaHL's session.getLog() appears to handle a null list of revision properties as no revision properties. Not the standard set!)
>
> I think every revision would (encoded in our Xml protocol) cost about 70 bytes, so there would fit at least 100 revisions in that buffer.
>
>
> For each of these revisions the apr repository has to handle a security check for every changed path... And many branch revisions involve more than a few paths.
>
>
> This looks like an extremely worst case for this operation. The first 100 revisions would have to be fully processed before you get the first result.
>
>
>
> I think a patch like the one attached should fix most of the usecases without affecting server performance too much... But it has to be applied at the server.
> (I'm trying to create a testcase to see how much this helps)
>
> Bert
>
Received on 2015-03-16 12:00:34 CET