[lug] Suggestions for Burn-In testing
gsexton at mhsoftware.com
Thu Jul 7 14:50:00 MDT 2005
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.
MH Software, Inc.
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>
More information about the LUG