Hello Oliver, Oliver Zeigermann <[EMAIL PROTECTED]> writes:
> - tests need to be run > - ports to other major databases. I can do Oracle, but will need help > with others I will try it on Postgres. > > 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. I am not really surprised, that a SQL store is not faster than a file store, when single nodes are accessed. The file stores keep all information about a node in one place, while the database has to search it from different tables. However I hope the SQL store to be much faster, if you search over many nodes. I found, that access control has much impact on performance, since slide has to visit all parent nodes. Without caching enabled for the security store, slide is unusable. Which acces police did you use? Performance for the slidestore.reference.JDBCDescriptorsStore did depend very much on the indices I created in the database. Its documented in the wiki.I did not yet look into the schema for J2EE, but maybe there is some potential for speeding up propfind. Its not always obvious, for which columns the indices are created automatically. How large was the file you PUT on the server? 70 seconds is really slow. I remember vague, that I had quite good transfer rates, when I experimented with the JDBCContentStore. Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
