Posts Tagged ‘Articles’

Stress testing by end users

Posted on April 23rd 2012 by Joel Deutscher

Performance testing is an expensive exercise. It takes specialist skills and a significant amount of planning and understanding of the application in order to replicate the hundreds or thousands of users you are expecting. Another option of course is to let your end users do the performance testing for you. Take the announcement from Blizzard below for Diablo III.

Diablo3

Beginning this Friday everyone is invited to log in and help us put the game and servers through their paces in this three day stress test as we march toward the game’s release.

It is really viable to get your end users to stress test your application?
Continue Reading…

Handling an overloaded site

Posted on March 1st 2011 by Joel Deutscher

Yesterday, Bankwest Online Banking (BOB) was having some serious performance issues. The site was painfully slow to use. After a few hours, I tried logging in again and was presented with the following message before I was allowed to logon.

Just before you log on...

I think this kind of information really helps set expectations for the customers, and I liked the tone of this message as opposed to some others.

Bankwest is lucky that it doesn’t have the media pull of its big brother, or cousins. For the rest of us, it’s a shame that it didn’t get more attention, we then might have seen a reason pushed out in the press release.

Fortunately for me, after braving the “Proceed to Logon” button, the site was back to full speed.

Fix Slow VuGen Replay?

Posted on October 8th 2010 by Joel Deutscher

StopwatchQuick tip: If you find VuGen is running slowly, it’s probably because you have the parameters data file open.

How much slower you ask? On a longer script I saw run-time drop from 415.8620 seconds to 50.2816 seconds

The good news is, closing the parameters file provides an instant boost of speed.

Are pilots taking performance testing off the critical path?

Posted on June 25th 2010 by Joel Deutscher

A trend I am seeing in solution delivery these days is piloting. With piloting, New functionality can be slowly ramped up in production, or more importantly, ramped down when problems occur.

This detaches performance testing from specific release dates. Essentially the application is regression tested with all new functionality disabled, reducing the amount of testing required to go live. New functionality can be switched on after adequate testing.

As testing has always been the accordion in the SDLC band, making a lot of noise as it’s time line is squashed, this is probably a good thing.

Personally, I am a fan of this style of development. I have seen too many organizations push ahead with releases regardless of testing coverage. This approach allows project managers, vendors and stakeholders to achieve their launch dates without the front page horrors.

Performance Testing LDAP – Basics

Posted on February 5th 2010 by Joel Deutscher

LDAPA while back, I took some time to familariase myself with the Lightweight Directory Access Protocol (LDAP) from a performance testing standpoint. The following post is the outcome of that investigation and can provide a technical starting point for performance testing LDAP . It is not designed as a definitive reference and I implore you to submit corrections and improvements in the comments.

This post discusses several methods for testing the LDAP protocol using LoadRunner, one using JMeter, and a final using a PHP harness.

Continue Reading…