DONE (with substantial support of my collegue Daniel Florey) - ordering of ACEs work now / was harder than I thought :( - at most one open statement per connection now - combined time consuming queries into one - made all statements prepared (also for performance) - removed "myRevisionDescriptor"-hack - some cleaning, resulting class is only half the size of original version
TODO
- many oddities including permissions occasionally mixed up (still in spite of ACE fix)
- confusion about branches and versions
- Some sort of "deadlocks" occur on delete and insert when having an isolation level higher than read committed. These can hardly be "real" deadlocks as I only have one thread running :( Any hints?
- tests need to be run
- ports to other major databases. I can do Oracle, but will need help with others
To my complete DISMAY performance measurements showed no significant difference to the "untuned" version. *Sigh*
Because this version is cleaned and at least does *not run slower* and some deadlocking spots have already been removed, I proposed to continue on this track.
Comments?
Oliver
Oliver Zeigermann wrote:
MS SQLServer works now too. Forgot to configure JDBC url with SelectMethod=cursor for multiple statements per connection.
Your url might look something like:
jdbc:microsoft:sqlserver://moe:1433;DatabaseName=Slide;SelectMethod=cursor
SQLServer running on a 700MHz P3, 512 MB RAM
PUT ~ 70 - 90 secs (!)
PROPFIND ~ 17 secs
READ ~ 12 - 20 secs
DELETE ~ 35 - 45 secs
Oliver Zeigermann wrote:
Got the initial version running now. Had to change minor stuff only. Have no SQLServer installation so tested it on Sybase as this only meant very little changes in schema and query. Manual tests look good, need to run the testsuite and especially the concurrent tests...
Fixes on ACE still missing...
First impression on performance as compared to the file store. I tested a large file tree with a PUT, PROPFIND and READ (after a restart to clear caches) and DELETE. My machine is a 1.4GHz P4 with 512 MB RAM, DB machine is a 2x800MHz P3 with 1 GB RAM.
Results are to be considered very rough and preliminary, but there was no load on the DB machine and network seemed to be almost clear as well.
Astonishing results anyway! Why is propfind on the DB (isn't more or less "SELECT * from props" or so) so slow? Why is delete so slow?
I think some tunneling of requests directly to stores supporting complex actions would be a very good idea. Will discuss this in a different thread later...
Any other experice?
----------------------------------------- J2EE store, compression ON
PUT ~ 55 secs
PROPFIND ~ 30-35 secs
READ ~ 30 secs
DELETE ~ 45 secs
----------------------------------------- TX file store
PUT ~ 45 secs
PROPFIND ~ 12 secs
READ ~ 10 secs
DELETE ~ 35 secs
--------------------------------------------------------------------- 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]
