How to test standard web server architecture(IIS) platform RRS feed

  • Question

  • User1519063011 posted
    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p>We have created Web farm environment with standard MS platform such as Webserver(IIS) and App Server(IIS/.NET). we are trying to perform various test on standard architecture to ensure Webserver ready for Application hosting.<o:p></o:p>What  kind of different  standard testing should we perform on MS infrastructure from Webserver standpoint.<o:p></o:p><o:p> </o:p>One would be failover testing on IIS with web farm environment. Please share any tools/test area for IIS and .NET<o:p></o:p>


    Tuesday, July 12, 2011 5:14 PM

All replies

  • User1073881637 posted

    This depends on the application that will be running on top of IIS.  For actual load testing Here is some options.  Visual studio has a test edition to generate load. 

    WAST (retired by MS)

    Apache Benchmark
    http://httpd.apache.org/docs/2.0/programs/ab.html<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>




    Tuesday, July 12, 2011 5:45 PM
  • User-2064283741 posted
    As Steve linked to this thread I am going to brain dump general thoughts on testing here. There are many types of test and I am going to summarize some here. Not much to add to the tools apart from what I would class as the market leader load tool is Loadrunner (http://www8.hp.com/us/en/software/software-product.html?compURI=tcm:245-935779&pageTitle=loadrunner-software) but the process and procedures is equally important here.

    1) Failover - test matrix

    Failover testing for this use a test matrix as follows. A test matrix will show all teh combinations of what could happen with the recording of the outcome. Simple really but I see so few people even doing it.

    Say you have 2 servers and you wanted to test load balancing

    Server 1 State    Server 2 State     Expected Outcome                                Actual Outcome
    Up                Up                 Traffic going to both servers
    Stopped           Up                 Traffic to Server 2 only - x seconds downtime
    Up                Up                 Traffic returns to both servers
    Up                Stopped            Traffic to Server 1 only - x seconds downtime
    Up                Up                 Traffic returns to both servers   
    Stopped           Stopped            No traffic to any servers
    Up                Up                 Traffic returns to both servers    

    This can be for anything db flips, DR tests, etc All areas of th architecture


    2) Load Testing

    Load testing is for placing a server under a sustained and typical load (working out what is a typical load/user behavior and/or baseline is a whole other question)  and them monitoring the performance on the server. Noting the response times for the users and any performance counter. The ones in http://pal.codeplex.com/ as useful here and cover most of the bases.

    Take note of these counters and use them as a baseline stats for future comparisons.

    3) Stress Testing

    Stress testing is similar to load testing but the purpose of this is to send too much load to the site in order to break it - to see what happens and what components/services/servers/areas of the site fail first. Then you can know the amount of load/users that break the site (or becomes so unreasonable response time you it can class as a fail. The business can define these times e.g. 10 seconds is unacceptable) and give reassurances that that is what the system architecture can support.

    Note what fails first and the users it supports and you will know if it is fit for propose and if you need to upgrade any areas, the is more important in multiple tiered environments to know where the weak point tiers are. Once you have this with a proper test matrix of failover you can built a complete picture of your environment.

    Be careful in any stress/load scenario that your infrastructure network, proxies, etc can handle the excessive load you are sending out from client/test machines. Many places have proxy limits for users and have to be understood to make sense of the tests. Some of the bottlenecks could be when the traffic is still in your internal network.

    Also in any load or stress testing I go on as an actual user in a browser from another machine to see what is happening and monitor the timings myself with firebug addon for Firefox, fiddler, etc. That way I have more confidence that the timings/ user experience is all ok. Automated tools are great but it is useful to see what is happening on the ground at the time.

    4)  Penetration testing (Pen Testing, Security Testing)

    Slightly out of scope for this post but also an important test is a pen test. Basically this is to try and hack the website.

    Security is normally one thing that gets overlooked.

    There are various automated security tools or my preferred method is to hire a pen testing consultant that will ethically hack your site and tell you the areas you need to improve. Security is becoming bigger news now-a-days and not just the mainstay for financial setups.

    Wednesday, July 13, 2011 7:22 AM
  • User1519063011 posted

    Thanks Ravastar and Steve. Its good starting point.


    Wednesday, July 13, 2011 3:20 PM