Re: Performance - the big problem
Re: Performance - the big problem
- Subject: Re: Performance - the big problem
- From: Sacha Michel Mallais <email@hidden>
- Date: Sun, 29 Oct 2006 13:57:10 -0800
On Oct 29, 2006, at 1:25 PM, Baiss Eric Magnusson wrote:
I have a long-standing problem with my main WO site <http://
www.Track-Your-Finances.com>, when I ask for a lot of records, say
(400-2000) and upwards.
This is a WO-Frontbase-MacOSXS site.
Something gets hung and I don't know what it is.
From Activity Monitor I see no sign of CPU saturation, there's
significant memory available, lots of disk space, and the Network
traffic is down to near zero.
Here's what TOP, from Monitor shows me, at a moment when a page hung:
Processes: 73 total, 2 running, 71 sleeping... 452
threads 12:44:46
Load Avg: 0.07, 0.08, 0.03 CPU usage: 3.6% user, 6.4% sys,
90.0% idle
SharedLibs: num = 178, resident = 41.1M code, 4.97M data, 8.90M
LinkEdit
MemRegions: num = 8642, resident = 375M + 9.73M private, 74.2M
shared
PhysMem: 101M wired, 117M active, 454M inactive, 672M used,
351M free
VM: 6.27G + 114M 123714(0) pageins, 0(0) pageouts
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD
RSIZE VSIZE
24214 FrontBase 0.0% 0:07.42 7 55 57 5.25M 2.09M
6.53M 41.7M
24158 FrontBase 0.0% 0:31.16 7 57 62 6.45M 2.09M
7.86M 43.6M
18249 AppleSpell 0.0% 0:00.08 1 32 31 416K 1.82M
2.64M 37.2M
17943 java 0.0% 12:04.51 28 386 200 35.1M 17.0M
43.6M 367M
12575 java 0.0% 2:13.77 27 388 199 34.6M 17.0M
43.4M 367M
11098 lookupd 0.0% 0:48.43 4 38 44 512K 1000K
1.26M 29.6M
10403 java 0.0% 12:38.92 27 345 195 24.5M 17.0M
32.9M 367M
...
This looks like you've asked it to sample for X seconds (top -s
<time>), but didn't give top enough time to do the sample. The clue
is the %CPU all 0.0%. Nevertheless, the other numbers are useful.
Definitely seems like you have enough RAM.
From my old embedded programming & real-time simulation days, it
appears to be like a port conflict where the system just hangs for
a very long period of time, say ten minutes.
This is my last big hurdle before I'm ready for a significant
launch...
Do you notice an increase in disk activity? Does the same query take
the same length of time if you run it twice in a row?
Have you narrowed down all possibilities so that you're sure the
delay comes between querying FB and getting a response back?
It might be the communication between FB and the app (they're on the
same machine, so no network activity will show up). The 2000 rows:
what's the average length of a row? I would expect a slowdown
returning only 100 rows -- if those rows were 10GB blobs...
sacha
_______________________________________________
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