Re: How many is too many instances?
Re: How many is too many instances?
- Subject: Re: How many is too many instances?
- From: email@hidden
- Date: Sun, 29 Jan 2006 11:40:29 +0100
The short answer is "When performance degrades for a given load you
are running too many instances.". When performance degrades, depends
on your particular application & environment. But those are
universal characteristics of any performance problem. Hence the
suggestion about JavaPlaybackManager for simulating client load.
Such a tool could help you determine if your site is limited by CPU,
RAM, or bandwidth. (i.e., where is your bottleneck actually, and can
more instances help that at all?)
There are any number of tools you can use to simulate client load.
The key is to not let the test tool dictate the test. (i.e., don't
write a bash script that calls curl on the main page just because you
can and it is easy.) But then you would also want to not have too
many scripts resulting ins simple read-only actions, if the reality
is that many people will be writing. Even for the reading actions
you want variety, otherwise you'll be testing the caching of your DB.
Then there are problems with writes too, are you always writing the
same data (making indexes less effective for queries). Not to
mention the ever present problem of getting a second 'live site' for
testing. You can use 'the' live site at 'night' unless you have
customers around the world. And the problem with your site may have
nothing to do with the number of instances you are running. Testing
on your local developer machine is good enough when you are looking
for large improvements in generation time for a particular page, but
it isn't good for load testing. What makes a page fast on one
platform is likely to help on another. But I wouldn't bet on the
times being the same for both platforms, nor the improvements.
So if there isn't an answer to the question without load tests, and
(useful) load tests are almost impossible to write/carry out, what to
do? I think you have two thirds of it already. You don't want to
actually run 16 instances with the 4GB, cause you want some left over
for other activities. Basically you want to use so few instances
that your machine doesn't ever swap. For your example, that number
is much lower than 16. You're on track with the CPU bit. I would
wonder where your DB (that I assume you have) is running? If load is
a concern and you want to simplify things then running your DB on a
separate machine may be a good idea.
Aside from that you can simply monitor your statistics over the long
term and try different configurations. Eventually I bet you find the
number of instances has little effect on the overall performance.
That's the good news and another short answer.
Am 27.01.2006 um 23:05 schrieb Eric Stewart:
How do you know when you are running to many instances of a WO App on
a given server?
I understand that you obviously can't run more instances than you have
memory to work with. So if you have 4 GB of memory and your running WO
Apps consuming 256 MB per app, obviously you can't run more than
roughly 16 apps.
I realize that the number of processors is also going to play a role
in this. Just because you have enough memory to run 16 apps doesn't
mean that's your ceiling. If you have only two processors, then you
can at most simulateously handle 2 operations. In this case do you
just monitor your CPU usage and once you start approaching 50-75% CPU
utilization on a constant basis then you know you are running the max
number of instances you should be running.
What do you guys who deploy large applications with millions of
requests per day look for when determining exactly how many instances
to run on a given server.
Thank you for your time,
Eric Stewart
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:
40mac.com
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