Re: slooow DB access at the deployment site (was: relationship count without fetching)
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 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 (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/cw%40i4innovation.de
>
> This email sent to c...@i4innovation.de
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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
SOLVED: slooow DB access at the deployment site (was: relationship count without fetching)
Oh, forget it.
It was the most obvious of possible reasons: they forgot to set up a DB index.
Oh, sigh.
Anyway, thanks for all the help!
OC
On 29. 2. 2016, at 18:30, OC 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 (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz
>
> This email sent to o...@ocs.cz
___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
slooow DB access at the deployment site (was: relationship count without fetching)
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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
