Vugen: Gracefully Handle Various HTTP Return Codes

There may be times where you want to build in logic for how your Vuser reacts to the various types of HTTP status return codes received throughout a script. For example, as web servers get overloaded, they may start sending 503 return codes. If you wanted to try and resubmit and finish out the transaction, this might be a more graceful way to handle the occasional 503 than just giving up and killing the iteration immediately. Of course, as the load continues to increase, the 503′s will become more frequent and eventually you will need to give up. Giving it a few additional tries might better reflect users who are trying to resubmit their page rather than immediately abandoning the site. The code below is one way to loop a request up to 5 times and handle various HTTP return codes differently depending on what status code is being received.

Action()
 {
 // Declare integers
 
   int HTTP_rc, retry_count;
 
/*
 *  This section includes the page request statement.
 *  It switches on the
 *  "continue on error" functionality just for this step.
 */
 
for (retry_count = 0; retry_count < 5; retry_count++)
 {
   lr_start_transaction("Transaction_Name");
   lr_continue_on_error(1);
 
   web_url("Index.htm",
   "URL=http://webpage.server.co.uk/cgi-bin/gen001_serverselect.dll",
   "Resource=0",
   "RecContentType=text/html",
   "Referer=",
   "Snapshot=t1.inf",
   "Mode=HTML",
   LAST);
 
   lr_continue_on_error(0);
 
 // Capture the HTTP return code and store it
 
   HTTP_rc = web_get_int_property(HTTP_INFO_RETURN_CODE);
 
// Condition statement: If less than 400,
// end the transaction and carry on with rest of script
 
if (HTTP_rc < 400)
 {
 lr_end_transaction("Transaction_Name", LR_PASS);
 lr_log_message("Index page displayed after %i attempts",
     retry_count +1);
 break;
 }
 
/*
 * Condition statement: if equals 503 AND retry_count is less than 4,
 * wait for 5 seconds before logging a message
 * confirming that the page
 * is not available and logging what attempt it was on.
 * NOTE: HTTP 503 = Server is busy
 */
 
else if (HTTP_rc == 503 && retry_count < 4)
 {
 lr_end_transaction("Transaction_Name", LR_STOP);
 sleep(5000);
 lr_log_message("Index page not available,
     retrying attempt %i", retry_count +1);
 continue;
 }
 
/*
 * Condition statement: End Transaction. If HTTP error equals 503,
 * log a message confirming that the page is not available
 * and what HTTP error you received, i.e. 404 (Page not found)
 * The last line exits the current iteration and fails this iteration
 */
 
else
 {
 lr_end_transaction("Transaction_Name", LR_FAIL);
 if (HTTP_rc == 503)
 lr_log_message ("Index page not available, no retry attempts left");
 else
 lr_error_message("Index page failed, HTTP error %i received", \
     HTTP_rc);
 lr_exit(LR_EXIT_ITERATION_AND_CONTINUE, LR_FAIL);
 }
}

There may be other reasons you might want to do other logic based on the HTTP return code. Let me know what they might be in the comments section below.

What's Next?

Did you enjoy this article? Help spread the word by sharing:

Join the Northway Navigator Club today and get access to restricted content including our best tips and tricks. Membership is free! You will also receive free email updates by registering.

Engage in the conversation and leave a comment:

Scott Moore

About Scott Moore (153 articles)

With over 20 years of IT experience with various platforms and technologies, Scott has tested some of the largest applications and infrastructures in the world. He is a Certified Instructor and Certified Product Consultant in HP’s LoadRunner and Performance Center products. He currently holds HP certifications for ASE, ASC, and CI. A thought leader in the APM space, he speaks regularly at IT conferences and events



  • Alyski

    I wrote something similar to this for a report creation application.  We would get a 301 return every 10sec while the report was being generated and then a 200 once it was complete and ready for viewing.

  • Mark Tomlinson

    Nice code – it does simulate what a real human being would do when they receive a erroneous error code (“Dude, just hit F5 and try it again!”). This approach works well for low-level web_url() and web_custom_request() statements, but what about EXTRARES calls or Context-Sensitive calls (e.g. web_submit_form) that have individually parsed return codes?