You are viewing a plain text version of this content. The canonical link for it is here.
Posted to slide-dev@jakarta.apache.org by Jean-Philippe Courson <co...@noos.fr> on 2002/10/01 15:29:49 UTC
Re: Speed problems with DeltaV
Hi Peter,
I am facing speed problems during PUT too but my benchs are a lot
worst than yours.
My setup : FileContentStore and modified JDBCDescriptor to remove dummy
sql request done to test connection validity.
Test Server is a Linux PIII 600 with 256M and PostgreSQL on the same
machine.
On the client side, I used WebFolders that comes with IE5.5.
DeltaV parameters are the same than yours (auto-version-control = true,
auto-version = checkout-checkin).
I tried to copy 100 docs of size each about 300 bytes to the /files
folder for several times.
Here is my results :
First copy : 80 seconds
Second copy : 35 minutes 45 seconds !!!
After that I stopped
What can we do to solve this problem ?
Are you currently changing DAV:checkout-set to a non-computed property ?
Is there a way to help you ?
Best regards
Jp
Nevermann, Dr., Peter a écrit:
> Hi Mike,
>
> thanks for testing the DeltaV impl and for reporting this.
>
> The DASL impl in the Slide kernel is the so called "generic" impl which
> allows stores to be unaware of any querying stuff (e.g. the FileStore). The
> algorithm consists in retrieving the descs for each resource and check the
> conditions. We are aware of its performance flaws.
>
> A DB-backed store like the JdbcStore can be made DASL-aware (How? We will
> let you know very soon through this mailing list). This makes SEARCH much
> faster as we have experienced with our Tamino-based store impl.
>
> WRT propertyHelper.computeCheckoutSet(), the DeltaV spec states that
> DAV:checkout-set is a computed property of a VR. We are now thinking about
> making it a protected, non-computed property, i.e. each VR stores its
> checkout-set which then must be maintained on each CHECKOUT, CHECKIN,
> UNCHECKOUT, DELETE and MOVE request.
>
> BTW:
> - what kind of store are you using?
> - with how many docs are you testing?
>
> In order to reproduce the problem, I took XMLFileDescriptorsStore and
> FileContentStore, set the parameters:
> auto-version-control = true,
> auto-version = checkout-checkin,
> and copied 100 docs of size each about 10k to the /files folder for several
> times. So, each time the files are copied they are checked-out and
> checked-in and computeCheckoutSet() is invoked 100 times (which of course
> becomes slower the more resources are in the namespace).
>
> The copy of the 100 docs took for the 1st to 8th times:
> 40 s, 55 s, 60 s, 65 s, 75 s, 85 s, 95 s, 105 s. The time for each PUT
> varied between 500 ms at the begining and 1000 ms at the end.
>
> Regards,
> Peter
>
>
>>-----Original Message-----
>>From: Michael Smith [mailto:msmith@xn.com.au]
>>Sent: Monday, September 23, 2002 07:57
>>To: slide-dev@jakarta.apache.org
>>Subject: Speed problems with DeltaV
>>
>>
>>Hi all,
>>
>>I've been experimenting lately with the DeltaV implementation now in
>>slide. Overall, it's pretty good, but after adding a few
>>documents to my
>>test repository, a PUT (to a version-controlled resource) is now slow.
>>Really, really, really slow. Typically (my test documents are
>>a few tens
>>of kB, and I'm doing this over a fast local network), a PUT takes 1-3
>>minutes.
>>
>>I've traced this to the call to propertyHelper.computeCheckoutSet() in
>>VersioningHelper.getCheckoutPreconditionViolation() This method takes
>>the vast majority of the total time for the PUT (the rest is on the
>>order of 1 second).
>>
>>Apparently, this uses the DASL implementation internally (to
>>figure out
>>whether this VR is a checked-out version of some VCR? It's
>>not entirely
>>clear). However, the default DASL implementation is
>>sufficiently slow as
>>to be completely unusable (and really, using DASL for
>>versioning doesn't
>>make much sense - at least to me).
>>
>>So, my questions: Why is this implemented this way, and how
>>could it be
>>changed to make it usable? I'm happy to do the work if some
>>guidance can
>>be provided, but I don't really understand the design of the
>>deltaV code
>>well enough to tackle it by myself.
>>
>>Mike
>>
>>--
>>To unsubscribe, e-mail:
>
> <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
No more speed problems with DeltaV (Was: Speed problems with DeltaV)
Posted by Jean-Philippe Courson <ju...@apache.org>.
Hi,
I commited yesterday modifications to make DAV:checkout-set property
protected rather than computed by the use of search.
Here is my new benchs :
Before : 1m20s, 35m, ?, ?, ?, ?, ?, ?
After : 1m20s, 2m20s, 2m30s, 2m55s, 3m20s, 4m, 4m15s, 5m
Much better ;-)
Jp
> Hi Peter,
>
> I am facing speed problems during PUT too but my benchs are a lot
> worst than yours.
>
> My setup : FileContentStore and modified JDBCDescriptor to remove dummy
> sql request done to test connection validity.
>
> Test Server is a Linux PIII 600 with 256M and PostgreSQL on the same
> machine.
> On the client side, I used WebFolders that comes with IE5.5.
>
> DeltaV parameters are the same than yours (auto-version-control = true,
> auto-version = checkout-checkin).
>
> I tried to copy 100 docs of size each about 300 bytes to the /files
> folder for several times.
>
> Here is my results :
>
> First copy : 80 seconds
> Second copy : 35 minutes 45 seconds !!!
> After that I stopped
>
> What can we do to solve this problem ?
>
> Are you currently changing DAV:checkout-set to a non-computed property ?
>
> Is there a way to help you ?
>
> Best regards
>
> Jp
>
>
> Nevermann, Dr., Peter a écrit:
>
>> Hi Mike,
>>
>> thanks for testing the DeltaV impl and for reporting this.
>> The DASL impl in the Slide kernel is the so called "generic" impl which
>> allows stores to be unaware of any querying stuff (e.g. the
>> FileStore). The
>> algorithm consists in retrieving the descs for each resource and check
>> the
>> conditions. We are aware of its performance flaws.
>> A DB-backed store like the JdbcStore can be made DASL-aware (How? We will
>> let you know very soon through this mailing list). This makes SEARCH much
>> faster as we have experienced with our Tamino-based store impl.
>>
>> WRT propertyHelper.computeCheckoutSet(), the DeltaV spec states that
>> DAV:checkout-set is a computed property of a VR. We are now thinking
>> about
>> making it a protected, non-computed property, i.e. each VR stores its
>> checkout-set which then must be maintained on each CHECKOUT, CHECKIN,
>> UNCHECKOUT, DELETE and MOVE request.
>>
>> BTW:
>> - what kind of store are you using?
>> - with how many docs are you testing?
>>
>> In order to reproduce the problem, I took XMLFileDescriptorsStore and
>> FileContentStore, set the parameters:
>> auto-version-control = true,
>> auto-version = checkout-checkin, and copied 100 docs of size each
>> about 10k to the /files folder for several
>> times. So, each time the files are copied they are checked-out and
>> checked-in and computeCheckoutSet() is invoked 100 times (which of course
>> becomes slower the more resources are in the namespace).
>> The copy of the 100 docs took for the 1st to 8th times:
>> 40 s, 55 s, 60 s, 65 s, 75 s, 85 s, 95 s, 105 s. The time for each PUT
>> varied between 500 ms at the begining and 1000 ms at the end.
>>
>> Regards,
>> Peter
>>
>>
>>> -----Original Message-----
>>> From: Michael Smith [mailto:msmith@xn.com.au]
>>> Sent: Monday, September 23, 2002 07:57
>>> To: slide-dev@jakarta.apache.org
>>> Subject: Speed problems with DeltaV
>>>
>>>
>>> Hi all,
>>>
>>> I've been experimenting lately with the DeltaV implementation now in
>>> slide. Overall, it's pretty good, but after adding a few documents to my
>>> test repository, a PUT (to a version-controlled resource) is now slow.
>>> Really, really, really slow. Typically (my test documents are a few tens
>>> of kB, and I'm doing this over a fast local network), a PUT takes 1-3
>>> minutes.
>>>
>>> I've traced this to the call to propertyHelper.computeCheckoutSet() in
>>> VersioningHelper.getCheckoutPreconditionViolation() This method takes
>>> the vast majority of the total time for the PUT (the rest is on the
>>> order of 1 second).
>>>
>>> Apparently, this uses the DASL implementation internally (to figure out
>>> whether this VR is a checked-out version of some VCR? It's not entirely
>>> clear). However, the default DASL implementation is sufficiently slow as
>>> to be completely unusable (and really, using DASL for versioning doesn't
>>> make much sense - at least to me).
>>> So, my questions: Why is this implemented this way, and how could it be
>>> changed to make it usable? I'm happy to do the work if some guidance can
>>> be provided, but I don't really understand the design of the deltaV code
>>> well enough to tackle it by myself.
>>>
>>> Mike
>>>
>>> --
>>> To unsubscribe, e-mail:
>>
>>
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>>
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>