Smalltalk › Instantiations

Profiling a Server

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

jtuchel

Profiling a Server

Hi,

I wonder what people do to keep statistics about the CPU usage of an SST/Seaside server at runtime.

What I am after is a way to collect data on how much load a server can handle and be able to find out how much load is too much.

My first idea was to log response times, but of course Seaside requests are very different. Some need to read lots of data from the DB and some just render a simple warning dialog. So an average response time and a hit list of shortest/longest is an indication, but doesn't really tell me much about what is really going on. There are many influencing factors that might be outside of the Smalltalk image.

Luckily, so far our server can handle our customer base quite easily. But we hope for growth and need to act before lag times make our service uncomfortable to use.

So one thing we need to do is log CPU usage on the O/S level, just to be sure the machine is powerful enough and upgrade soon enough once we approach a limit. That is something independent of Smalltalk.

But the other things is we need to find out when it's time to add more Smalltalk images and extend our load balancing to distribute load over several images/vm's.

Any experiences? Any tips/recommendations on what we could do?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.

Richard Sargent

Re: Profiling a Server

Administrator

>> log CPU usage on the O/S level, just to be sure the machine is powerful enough ...

From what I remember of queuing theory, 70% is the "magic" number. (Actually, it is probably 70.71% - the sin() or cos() of 45 degrees.) Once you pass that threshold, performance degrades rapidly. So, track your overall CPU load as you propose. Average and peak numbers are important, but you should have weighted values, too. e.g. a peak of 90% is not a problem if it last 1 second and occurs once a day, but longer lasting or more frequently occurring indicates potential troubles.

>> log response times, but of course Seaside requests are very different

It should be possible to characterize requests by function and record the times for different functions requested, then track the changes in those numbers over time.

On Friday, December 13, 2013 1:55:38 AM UTC-8, [hidden email] wrote:

Hi,

I wonder what people do to keep statistics about the CPU usage of an SST/Seaside server at runtime.
What I am after is a way to collect data on how much load a server can handle and be able to find out how much load is too much.

My first idea was to log response times, but of course Seaside requests are very different. Some need to read lots of data from the DB and some just render a simple warning dialog. So an average response time and a hit list of shortest/longest is an indication, but doesn't really tell me much about what is really going on. There are many influencing factors that might be outside of the Smalltalk image.

Luckily, so far our server can handle our customer base quite easily. But we hope for growth and need to act before lag times make our service uncomfortable to use.

So one thing we need to do is log CPU usage on the O/S level, just to be sure the machine is powerful enough and upgrade soon enough once we approach a limit. That is something independent of Smalltalk.

But the other things is we need to find out when it's time to add more Smalltalk images and extend our load balancing to distribute load over several images/vm's.

Any experiences? Any tips/recommendations on what we could do?

Joachim