Excellent Work!!! Richie
-----Urspr�ngliche Nachricht----- Von: Jean-Philippe Courson [mailto:jumal@;apache.org] Gesendet: Freitag, 18. Oktober 2002 10:37 An: Slide Developers Mailing List Betreff: No more speed problems with DeltaV (Was: Speed problems with DeltaV) 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: [EMAIL PROTECTED] >>> 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: >> >> >> <mailto:slide-dev-unsubscribe@;jakarta.apache.org> >> For additional commands, e-mail: >> <mailto:slide-dev-help@;jakarta.apache.org> >> >> -- >> To unsubscribe, e-mail: >> <mailto:slide-dev-unsubscribe@;jakarta.apache.org> >> For additional commands, e-mail: >> <mailto:slide-dev-help@;jakarta.apache.org> >> >> >> > > > > > -- > To unsubscribe, e-mail: <mailto:slide-dev-unsubscribe@;jakarta.apache.org> > For additional commands, e-mail: <mailto:slide-dev-help@;jakarta.apache.org> > > > -- To unsubscribe, e-mail: <mailto:slide-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:slide-dev-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:slide-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:slide-dev-help@;jakarta.apache.org>
