From: Adam R. <ada...@de...> - 2007-08-02 09:31:47
|
Wolfgang, This could potentially be the same issue that I reported and spent some time trying to devise a patch for??? The problem I had with performance time when querying across many collections was with loading the collection configuration for each collection under query, or if the collection has no configuration then reloading the parents collection configuration multiple times. Also this is combined with the case that caching of collection configuration has been disabled as I think you described that there was a possible synchronisation issue. Anyways, if this is the case, I am happy to provide you with my patch that improves query time somewhat, but only looks at one of the issues I think, when perhaps it should be expanded to address both. Thanks Adam. On Wed, 2007-08-01 at 19:36 +0200, Wolfgang Meier wrote: > Hi, > > > That on my previous db (one collection) return in about 2-3 seconds), but > > After partitioning responds in 100-120 seconds. > > I still don't understand why it gets that much slower with "only" 100 > collections. You just send one query on the top-level collection and > not one query on every collection? > > Well, if your test data is not confidential and can be zipped to < > 50MB, send me a backup of it and a bunch of queries and I can have a > look at it. > > Wolfgang > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Exist-open mailing list > Exi...@li... > https://lists.sourceforge.net/lists/listinfo/exist-open -- Adam Retter Principal Developer Devon Portal Project Room 310 County Hall Topsham Road Exeter EX2 4QD t: 01392 38 3683 f: 01392 38 2966 e: ada...@de... w: www.devonline.gov.uk |