Home     RSSRSS

Posts Tagged ‘Mobile Performance Testing’

Compression,Decompression,Mobile Performance and LoadRunner

February 4, 2013 by kiranbadi1991 | 2 Comments | Filed in Decompression, Development, LoadRunner, Performance Center, Performance Engineering, Scripting, SilkPerformer

Recently I inherited some of the  LR scripts from one of my colleagues,it was all about building the json calls for stressing the backend spring security framework which was first layer of entry into the mobile infrastructure.Those scripts were simple scripts  built using the custom request with json string as a body part.One of the things that really surprised me as part of this effort was that web custom request in itself was taking close to 100ms to 300ms to do decompression of the server response during load testing.

Okay first let me give you some background,servers were configured to send the response compressed in gzip format with content encoding header as gzip.The functionality under scope had SLA of 1 sec max and quite a few functionality in scope also had SLA that was less than 500ms.Quite a challenging SLA’s I would say.But again these functionality were supposed to be accessed over the mobile device,so probably less the response time better it is for users.

Most of the response coming from the server for all functionality was served as chunked bytes,so what it means is that server sends initially some bytes as response in compressed gzip format,LR decompresses  those bytes in 5 to 10ms and then again server sends next range of bytes as chunked gzip response and then again LR will spend close to 5 to 10ms to decompress those bytes and like wise the process continues till we have final set of bytes.All these process happens in the single connection and connection never closes with the server.In case if you do have some server response validation in place, then expect that it will add another 10ms to do that validation.

Now I have measured all these times in the single iteration of vugen,these times increase exponentially when we are running the Load Test in controller or PC and this overhead of decoding the gzip content becomes a quite an issue when response time SLA are in ms.

Here is how it looks when you see the behavior in LR Vugen with decompression on in the script.You can see that it takes 5ms to decode the 154 bytes of response.Now imagine the normal webpage will have size of 2mb of data gzipped,so you can see the impact of this decoding  when size of page increase specially when response is coming as chunked bytes with no fixed content length from the server.

pic1

 

I think HP LR team might also be aware of this behavior and probably that the reason as why they might have come up with function to disable this.Use Web set option with decode content flag turned off if you are running the scripts which do not require validation and has response time SLA’s in ms.The drawback of disabling this feature is that all your correlation and other checks for server response will fail since server response will show up as binary content like below.

pic3

 

I would suggest you to disable this feature if you can and do the response validation by using the other techniques like verifying server logs etc.By disabling this you will gain close to 15 to 20% reduction in response time reported by LR.

Is this expected behavior of LoadRunner ?, I think they have to do this,unless they decode the response, none of the other function like web reg save param or web reg find will work and these functions are core functions of LoadRunner.Probably the right way is that LR should not add these decompression timing in their transaction markers.These timing really pollute the results specially for web applications or probably they can increase the speed of this decompression library what they are using in LoadRunner.

Tags: , , , ,

Mobile Performance Testing- Requirements Gathering Process

November 30, 2011 by kiranbadi1991 | Comments Off on Mobile Performance Testing- Requirements Gathering Process | Filed in Performance Engineering, Process, Project Management

As per the research done by Morgan Stanley, mobile internet will soon be overtaking fixed internet and we can see and feel the same trend now given that smartphones and tablets sales are overtaking PC sales,so all these changes compels us to go with a market demand.

http://gigaom.com/2010/04/12/mary-meeker-mobile-internet-will-soon-overtake-fixed-internet/

http://www.pcmag.com/article2/0,2817,2379665,00.asp

So I thought let me share some of my thoughts based on my exposure to mobile world.I did poke around with WAP/Openwave emulator back in 2006/07 with both Silk Performer and LoadRunner.I do remember they have a protocol bundle for testing mobile traffic back then.I faintly remember it was more of an open source emulator support which these tools were supporting.Now the scenario is different, WAP is dead and now plain HTTP rules the mobile world.So we have some old rules which I believe still applies to mobile world and then there are also some rules which are totally new when we think in terms of Performance Engineering.

The strategy for designing for the mobile web site differs drastically compare to the desktop based web application given that applications works in the mobile context with limited amount of resources like screen size,network capacity,Hardware resources etc.The site needs to be lean in design and be accessible on the smallest mobile device with the exact functionality as offered on desktop based web applications.So the end to end strategy for testing mobile based application also differs compare to the desktop based web applications at times throwing unique challenges to the testing team.

It is also important to know and understand the capabilities of the various types of phones available in the market so that we have some idea as what is happening in the client side of the device.Some phones have Cursor based navigation, some phones have focus based navigations and some have touch and some multi touch based navigation.Low end devices normally have cursor or focus based navigation,so users using this focus or cursor based type of device will not normally prefer to have navigation depth of more than 3 links while browsing the site.The same user might browse a little longer in your site with either the tablet of smartphone.So it is fair to expect that page depth of the browsing in case of smartphones and tablets will be somewhat higher compare to Low end devices.This will help us in designing appropriate work load modelling for performance testing.

In this writing, I will try to summarize as what all things needs to be known and collected as part of requirement gathering for performance testing of the mobile web applications.

  • Know your site along with its business domain and benefits it brings to users who are using your site.
  • Know your users and how they use your application in mobile environment.
  • Know the type of mobile device or handset your users uses to access the application.
  • Know the network bandwidth your users uses in their device to access your application.
  • Know the carrier your user uses to access your application.
  • Know how long your users browses your site in the mobile space and collect the page depth of their browsing experiences.
  • Know the type of the mobile browser your users use to access your application in the mobile environment.
  • Know the user’s device’s screen size.
  • Do not trust the web server logs to design the scenario as user behavior is not the same as compare to desktop users.If your business grows ,users multiply exponentially compare to desktop users given that users will be using your site on the move.
  • There is very little or absolutely zero think time concept in Mobile space.Users are not going to wait to click the links unless they are verifying the some information before doing submit.

Sometimes it might happen that we do not have information on these points,in that I would suggest follow the mobile web standards and test taking those standards as your requirements.

Tags: ,