Hi OC, I once had a deployment machine with FrontBase on which – I don't remember why anymore – the indices of the tables where not set. The database was working but it was very very slow. After generating the indices and setting the index mode to "preserve time" the speed was back as expected.
So maybe you take a look, if your indices are set up correctly. (In FrontBaseManager go to "Schema Objects" -> $USER -> "Tables" -> $TABLENAME -> click "OPEN DEFINITION"-button -> "Index") C.U.CW -- The three great virtues of a programmer are Laziness, Impatience and Hubris. (Randal Schwartz) > On 29.02.2016, at 18:30, OC <[email protected]> wrote: > > Well I have implemented count using objectCountForToManyRelationship, and > found it is MUCH worse than before at the deployment site (whilst it runs > like a charm for me at my testing machine). > > After lots of testing it seems the real bottleneck is the database query > itself. Lately, I have implemented this kind of count-of > > === > // my ERXEnterpriseObject subclass, a superclass of all my EOs > static ocs_count_n=0,ocs_count_time=0 > def ocs_count_of(String key) { > def relationship=valueForKey(key) > boolean fault=EOFaultHandler.isFault(relationship) > if (!fault) return relationship.count() > > ocs_count_n++ > def time=System.currentTimeMillis() > def n=ERXEOControlUtilities.objectCountForToManyRelationship(this,key) > time=System.currentTimeMillis()-time > ocs_count_time+=time > println "COUNTOF: $ocs_count_n: $time, average > ${(int)(ocs_count_time/ocs_count_n)} ms" > return n?:0 > } > === > > Now, testing on my development machine (2.53 GHz i5, 8 GB RAM) I am getting > logs like > > COUNTOF: 18: 18, average 17 ms > COUNTOF: 19: 14, average 17 ms > COUNTOF: 20: 15, average 17 ms > COUNTOF: 21: 14, average 17 ms > > On the deployment machine though (2.26 GHz QuadCore Xeon, 24 GB RAM) the logs > are sort of different > > COUNTOF: 18: 1911, average 1789 ms > COUNTOF: 19: 1905, average 1795 ms > COUNTOF: 20: 1883, average 1799 ms > COUNTOF: 21: 1883, average 1803 ms > > which sort of explains why the page generation is terribly slow. > > I would be grateful for an advice to find and fix the cause of this slow DB > access; any idea? > > Both the machines run Groovy 2.3.8 / WebObjects 5.4.3 > > The deployment machine runs Java 1.6.0_65 / Mac OS X 10.6.8 / FrontBase > 5.2.1g-64 bit (server on localhost, along with all the WO applications). > > My test machine runs Java 1.7.0_13 / Mac OS X 10.8.5 / FrontBase 7.2.18 64 > bit (localhost server, too); might anything of this cause the vast > difference? Does not seem to me, but of course, I might be overlooking > something of importance. > > Thanks a lot, > OC > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/cw%40i4innovation.de > > This email sent to [email protected]
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
