Saturday, November 16, 2013

Performance testing on social network, location reporting

    Social networking has became wildly popular, thanks to omnipresent smart phones and apps.  Many interesting smartphone apps depend on user's locations to recommend restaurants or shops.  What does this have to do with performance testing?

    In order for servers to send recommendations, they need to know the current locations of the users.  As a result, the smartphone apps will need to periodically send location updates as users move around. It may not be very easy if your servers need to handle millions of smartphones that send updates periodically and run through some algorithms, query some databases to get the recommendations and send them back to users.  It's really important to have a good performance test on the infrastructure (web servers and their backends) before you open it up to the wide audience.

    How do  we do performance testing on this kind of social networking apps?  Simply emulating a lot of users and sending dummy location updates may not test the servers well enough.  To better test the system, in particular the algorithms,  we need to emulate a lot of users roaming around in a more realistic way and send location updates.

    Netgend platform not only can emulate a lot of users (50,000 on one system),  it can also emulate users flexibly and realistically.  We can implement this scenario with a csv file that represents a map.  As an example, based on the following little map,  our csv file will have
  • 9 intersections (numbered 1,2, ...9, left to right, top to down).  each one with its latitude and longitude.
  • segments of streets (hereby called streets) connecting these intersections.  For example, "1,2" means the street connecting intersections 1 and 2.  "1,4" means the street connecting intersections 1 and 4.  There are 12 streets here.

     Here is a quick look at the file.
 ....some lines skipped  
 ....some lines skipped  

     Now it's time to introduce our script to emulate those users who roam around and send location updates:
 function userInit() {  
 function VUSER() {  
      position = randPosition(); 
      //some steps to sign in, omitted here
      while (1) {  
           move(position, 30);   //move 30 feet
           p = getLoc(position);  
           http.POSTData = q|{"latitude": ${p[0]}, "longtitude": ${p[1]} }|;  
           action(http, "");
           sleep(10000);  //10 second

     In the above script,  we first create a (implicit) map object from the csv file by using the function "loadMap".   This is done only when the test starts.
     In the VUser script part (executed by each VUser), we start with a random position,  then we move 30 feet every 10 seconds and update our latitude and longitude.  For the curious minds,  here is what the two functions "randPosition()" and "move()" do.

  •  randPosition():  it will randomly pick an intersection and then find one of its neighbor intersections, these two intersections determine a (segment of ) street.  The user will move from the intersection initially picked and move to the neighbor intersection.   After that it will pick a random point on this segment of street and return it to user's "position" variable.
  • move(),  will move user's position by specified distance (in feet) and update its internal coordinates.  If user comes to an end of a segment, i.e. comes to an intersection,  it will use new intersection as the a starting point and randomly pick one of its neighbor intersections (but not to the intersection it comes from) and continues the moving. 
    There are a couple of ways to make it more realistic (hence more complex):  make each user move at different speeds;   make each user move toward a random destination etc.  All these cases can be supported on this test platform.

    Social networking is going to be hot, is your infrastructure ready? 


1 comment: