• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
SOLVED: slooow DB access at the deployment site (was: relationship count without fetching)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SOLVED: slooow DB access at the deployment site (was: relationship count without fetching)


  • Subject: SOLVED: slooow DB access at the deployment site (was: relationship count without fetching)
  • From: OC <email@hidden>
  • Date: Mon, 29 Feb 2016 19:22:46 +0100

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 <email@hidden> 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@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


References: 
 >relationship count without fetching (From: "ocs.cz" <email@hidden>)
 >Re: relationship count without fetching (From: Paul Hoadley <email@hidden>)
 >slooow DB access at the deployment site (was: relationship count without fetching) (From: OC <email@hidden>)

  • Prev by Date: slooow DB access at the deployment site (was: relationship count without fetching)
  • Previous by thread: slooow DB access at the deployment site (was: relationship count without fetching)
  • Index(es):
    • Date
    • Thread