Chuck Hill wrote:
Hi Owen,
Comments in-line below.
On Jul 13, 2006, at 10:11 PM, Owen McKerrow wrote:
Hi All,
We are setting up an application of ours on a clients server,
they did some stress testing to see if they needed a bigger box
and discovered something strange.
Their comments ....
The webobjects versions have been stress tested further, we are
getting ok
results but far worse then I was hoping. RIS Public faired worse
the RIS
with it starting to get error with only 5 simultaneous users
making simple
request 5 seconds apart (running with 2 instances each with -
mx512M.
That is odd. Are you dispatching requests concurrently?
No, getting them to retest with it on.
That should make a considerable difference, unless the app is doing
a lot of EOF activity.
A major point of interest is that garbage collection does not
appear to be
active for these instances.
Check for I/O and DB usage. How long does the average request
take to process?
From the stats page :
Transactions 691
Active Session 0
Average transactions 5.031
Averegae idle 131.627
Five seconds on average is, IMHO, way too long.
Mine 2 :)
Either all of your actions are a little slow or some are very slow.
Sight unseen, my money is on the latter. Usually this is the result
of DB access,
either queries that are slow to evaluate due to missing indexes
DOH ! **Hits self in the head** Thats one thing I need to do when
there DBA gets back from holidays :) We moved the DB from OpenBase to
Oracle and we haven't been back an applied indexing yet : )
That would cause problems. :-)
or lots of single row queries due to a lack of batch faulting and
pre-fetching in the application.
I have fiddled with it today. At the beginning of the day it looked
like (Note this a request for a page that loads a displaygroup to
display every publication I have in the DB and the stats before are
for the first time it is accessed for the app ) :
09:45:42,150 DEBUG [WorkerThread0] (PublicationsList:48 <init>) -
Publication Constructor
09:45:43,188 DEBUG [WorkerThread0] (PublicationsList:149
updatePublicationListing) - Update Pubs
09:45:45,001 DEBUG [WorkerThread0] (PublicationsList:208
updatePublicationListing) - End Update Pubs.762 total Pubs
09:45:48,257 OFF [WorkerThread0] (Log.NSLogOut:1546 appendln) - Now
asleep
After my tweaks ( the biggest time saver here was changing to use
EOSharedEditingContext, as its a read only ap ) :
13:32:53,295 DEBUG [WorkerThread0] (PublicationsList:48 <init>) -
Publication Constructor
13:32:54,174 DEBUG [WorkerThread0] (PublicationsList:143
updatePublicationListing) - Update Pubs for Faculty of Education
13:32:54,920 DEBUG [WorkerThread0] (PublicationsList:196
updatePublicationListing) - End Update Pubs.762 total Pubs
13:32:58,467 OFF [WorkerThread0] (Log.NSLogOut:1546 appendln) - Now
asleep
So between the constructor ( line 1 ) and the time the Pubs have been
loaded (line 3) went from 2.8 seconds to 1.6 ( and will hopefully get
faster once I index **Hits self in the head again**)
But the biggest time is between the end of the
updatePublicationsList() and sleep(). I need to do some further
testing to see if Im grabbing more objects from the DB ( as you said
"lots of single row queries.") or its because of the actual page
itself. The site has a quotation style engine in it which basically
on the fly changes the way in which a publication is displayed. This
is what suspect is chewing up time. The other reason I think this may
be the case is the time between line 3 and line 4 doesn't change when
I come back to the page i.e. the EO's should be in memory, but the
time to "render" the page seems to be the same.
I think you have reached the correct conclusion there.
Are you a Project Wonder user?
Nope, always wonder, never plunged. It may be my pet project while Im
at WWDC this year.
That sounds like another T-Shirt idea for Mike Schrag: Have you
WONDERed? or Always WONDER!
How about,
WO Problems ? No WONDER : WONDER
cheers,
- shaun
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
