[lug] Suggestions for Burn-In testing

[George Sexton]

Thanks for the suggestion. I guess I should have thought of that. I think
I'll use Jmeter from a couple of stations. It has a lot of statistical
gather capabilities and I can create a test plan.

George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  

> -----Original Message-----
> From: lug-bounces at lug.boulder.co.us 
> [mailto:lug-bounces at lug.boulder.co.us] On Behalf Of Zan Lynx
> Sent: Thursday, July 07, 2005 2:21 PM
> To: Boulder (Colorado) Linux Users Group -- General Mailing List
> Subject: Re: [lug] Suggestions for Burn-In testing
> 
> On Thu, 2005-07-07 at 12:48 -0600, George Sexton wrote:
> > I'm in the process of configuring a new server that will 
> run SUSE Linux 9.3
> > (already got it installed).
> > 
> > I've run Memtest86 on it, but I was thinking about some 
> sort of software
> > that could do some disk write loading, and misc. stability 
> tests. I'd like
> > to be pretty confident the box is going to be stable before 
> I spend the time
> > doing the final configuration, and actually put it in production.
> > 
> > Does anyone have any suggestions on what I could use?
> > 
> > The box will be hosting our calendar software for 50 
> customers (initially),
> > and hopefully up to 200 before it maxes out.
> 
> For the very best burn-in testing for any server, run scripts 
> that test
> the service itself.  That way you can know it will stay up, 
> and you can
> use the same scripts to adjust load and look for bottlenecks.
> Any Web application can be tested by writing some scripts to 
> do it.  I'm
> used to using Perl LWP and HTML::Forms.  There's also Mechanize.
> 
> I would bet your calendar software is a Web application.  You 
> could use
> Ethereal to sniff the network traffic while you did a typical calendar
> session, then suck out all the HTTP GET/POSTS and write a 
> Perl script to
> do the same things.
> 
> Use the script to record delay time for actions.  Figure out how many
> requests per second each app user will be making on average 
> and how much
> delay the users are likely to accept.  Then you can know how 
> many users
> your server will support.
> -- 
> Zan Lynx <zlynx at acm.org>
>