Stress & load web tests
7:51 | Author: Unknown

Posteé un primer artículo en el el blog de Southworks. Siguiendo la costumbre de este blog, la idea es postear aquí en castellano por lo que voy a intentar traducirme. Puede considerarse cross-posting.

Primeras semanas

Van pasando mis primeras semanas en Southworks, tuve diferentes desafios. Uno de ellos fue estresar un WorkerRole service localmente y en WindowsAzure.
Un WorkerRole es un rol para desarrollos generales y puede realizar procesamiento background para un web role. Una vez deployado localmente obtenemos una URL a nuestro servicio WCF.
Trabajando con esta arquitectura necesitamos estresar los request a este servicio para verificar distintos comportamientos de Windows Azure. El principal objetivo de el stress test es descubrir la recuperabilidad de el servicio o el server testeado.

Stress test usando Pylot

Existe una multiplicidad de herramientas caras para estresar web services. Decidimos utilizar una muy buena solución open source realizada en Python llamada Pylot.

 

Instalando Pylot

Pylot es un script Pyhton y utiliza librerias wxPython para la interfaz gráfica, NumPy and MatPlotLib para reportes y gráficos.

 

Usando Pylot

Usar la GUI de Pylot es elemental. Debemos crear un xml con los casos de prueba.

 

   1: <case>    




   2:      <url>http://www.goldb.org/foo</url>




   3:     <verify>Copyright.*Corey Goldberg</verify>




   4:     <verify_negative>Error</verify_negative>




   5: <case>






Visual Studio 2010 Stress tests



Más allá de la solución de Pylot, en algunos casos necesitamos una pequeña aplicación para solucionar temas particulares. StressService es un servicio realizado en c#. Podemos estresar nuestro server con este simple contrato.



Utilizaremos el Load Test de Visual Studio 2010 para crear el stress test. Para hacer esto crearemos un unit test que realice la acción que queremos estresar.





   1: [ServiceContract]




   2: public interface IStresserService




   3: {




   4:         [OperationContract]




   5:         int SimpleRequest(string url);




   6:  




   7:         [OperationContract]




   8:         List<int> Stress(int workers, string url);




   9: }






Implementación del contrato.





   1: public class StresserService : IStresserService




   2: {




   3:     public int SimpleRequest(string url)




   4:     {




   5:         if (string.IsNullOrEmpty(url))




   6:             throw new ArgumentOutOfRangeException("url");




   7:         HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);




   8:         HttpWebResponse response;




   9:         try




  10:         {




  11:             response = (HttpWebResponse)request.GetResponse();




  12:         }




  13:         catch (WebException e)




  14:         {




  15:             return (int)((HttpWebResponse)e.Response).StatusCode;




  16:         }




  17:         return (int)response.StatusCode;




  18:     }




  19:  




  20:     public List<int> Stress(int workers, string url)




  21:     {




  22:         var results = new List<int>();




  23:         Parallel.For(0, workers, t =>




  24:         {




  25:             results.Add(SimpleRequest(url));




  26:  




  27:         });




  28:         Thread.Sleep(10000);




  29:         return results;




  30:     }




  31: }






 





   1: [TestMethod]




   2: public void ItShouldCreateNStressers()




   3: {




   4:     IStresserService service = new StresserService();




   5:     var results = service.Stress(100, @"http://localhost/");




   6:  




   7:     Assert.AreEqual(100, results.Count());




   8: }






Creamos el Load Test para estresar utilizando muchos usuarios durante un tiempo T.



 



imageimage



Próximos pasos: escalar la solución.



Podemos escalar la solución comenzando nuevos servicios en otras máquinas y sincronizando los diferentes workers creando un manager.



 



image



Requerimientos desde diferentes dominios



La solución está estresando desde el mismo dominio. Podemos tener diferentes problemas (por ej. D.O.S.) que se pueden sobrellevar utilizando otros servicios como  Gomez

El examen 70-519 es parte del camino para la MCPD (Microsoft Ceritified Professional Developer). Al ser un examen nuevo no existen aun materiales programáticos para prepararlo. Encontraremos material en el examen 70-562 TS: Microsoft .Net Fameqork 3.5 Asp.Net development, (hay que tener en cuenta que este examen era relacionado al framework 3.5 y se utilizaba la version 2008 del VIsual Studio, mientras que el que voy a preparar utiliza el framework 4 y la version 2010 del Visual Studio)

Por ser un examen beta tengo chance para rendirlo hasta el 30 de abril, pero lo schedulee (valga el anglicismo) para el 20 de abril. Con lo que empecemos.

Guia

Designing the Application Architecture (19%)
  • Plan the division of application logic.

    This objective may include but is not limited to: choosing between client-side and server side processing, planning separation of concern, (for example, partitioning functionality between controllers and evaluating business and data service consumption), planning for long-running processes (for example, synchronous vs. asynchronous)
  • Analyze requirements and recommend a system topology.
    This objective may include but is not limited to: designing interaction between applications, mapping logical design to physical implementation, validating nonfunctional requirements and cross-cutting concerns (for example, communications, operations management, and security), evaluating baseline needs (for example, scale and quality of service)
  • Choose appropriate client-side technologies.
    This objective may include but is not limited to: JavaScript, ASP.NET AJAX, jQuery, Microsoft Silverlight
  • Choose appropriate server-side technologies.
    This objective may include but is not limited to: user controls, server controls, partials, custom HtmlHelper extensions, Web parts, inheriting controls, dynamic data controls
  • Design state management.
    This objective may include but is not limited to: designing an application for the proper use of application state, session state, and request state (for example, ViewState, ControlState, Cache object, cookies, and client-side persistence)
Designing the User Experience (17%)
  • Design the site structure.
    This objective may include but is not limited to: designing application segmentation for manageability and security (for example, using areas, shared views, master pages, and nested master pages), appropriate use of style sheets, client-side scripting, themes, client ID generation, rendering element modes, routing engine
  • Plan for cross-browser and/or form factors.
    This objective may include but is not limited to: evaluating the impact on client side behaviors, themes, bandwidth, style sheets (including application design - task based or scaled rendering of existing page), when to apply Browsers file, structural approaches, user agents, different platforms (mobile vs. desktop)
  • Plan for globalization.
    This objective may include but is not limited to: designing to support local, regional, language, or cultural preferences, including UI vs. data localization (for example, implementing at database level or resource level), when to use CurrentCulture vs. CurrentUICulture, globalization rollout plan (for example, setting base default language, planning localization), handling Unicode data (for example, what fields to include, request encoding), right-to-left support, vertical text and non-Latin topographies, calendars, data formatting, sorting
Designing Data Strategies and Structures (18%)
  • Design data access.
    This objective may include but is not limited to: choosing data access technologies such as ADO.NETData Services, Entity Framework, Windows Communications Foundation (WCF), and ASP.NET Web Services
  • Design data presentation and interaction.
    This objective may include but is not limited to: pulling data from data layer and binding into views, pages, and controls, and pulling data back to data layer by using ModelBinders, data source controls, and HtmlHelper extensions, or programmatically
  • Plan for data validation.
    This objective may include but is not limited to: contextual validation vs. data integrity, where to validate data, synchronization between UI and data layer, data annotations
Designing Security Architecture and Implementation (17%)
  • Plan for operational security.
    This objective may include but is not limited to: approaches for process- and resource-level security, including local and remote resources, Code Access Security (CAS), including trust level, process identity, application pool, and identity tag
  • Design an authentication and authorization model.
    This objective may include but is not limited to: authentication providers, including WindowsForms, and custom user identity flowthrough (for example, trusted subsystem), role management, membership providers, URL authorization (for example, AuthorizationAttribute), file authorization, Authorization Manager (AzMan)
  • Plan for minimizing attack surfaces.
    This objective may include but is not limited to: input validation, throttling inputs, request filtering, where to use Secure Sockets Layer (SSL)
Preparing For and Investigating Application Issues (15%)
  • Choose a testing methodology.
    This objective may include but is not limited to: black box, white box, integration, regression, coverage, API testing, performance testing, security testing

    This objective does not include: load testing, Web testing, unit testing
  • Design an exception handling strategy.
    This objective may include but is not limited to: HandleError attribute in MVC, common error pages, post-error processing, global vs. page level
  • Recommend an approach to debugging.
    This objective may include but is not limited to: tools and approaches for a given scenario (for example, memory dumps, DebuggingAttributes, crashes vs. hangs, deadlocks, assembly binding), when to attach to process (Visual Studio Development Server vs. IIS vs. Internet Explorer), root cause analysis
    This objective does not include: basic breakpoints
  • Recommend an approach to performance issues.
    This objective may include but is not limited to: which instrumentation to watch or create (including performance counters and event tracing) to analyze performance issues, page and fragment caching
Designing a Deployment Strategy (14%)
  • Design a deployment process.
    This objective may include but is not limited to: Windows Installer (MSI) vs. xcopy vs. Web Deployment Tool, scaling, rolling deployments
  • Design configuration management.
    This objective may include but is not limited to: using the ConfigSource attribute (for example, connection strings), staging vs. production vs. development, topologies, machine.config vs. web.config, using IIS vs. Visual Studio Development Server during development, application pools, configuration inheritance
  • Plan for scalability and reliability.
    This objective may include but is not limited to: scaling up, scaling out, at physical level and at architectural level, impact of offloading technologies on load balancing, including state, synchronizing machine and encryption keys
  • Design a health monitoring strategy.
    This objective may include but is not limited to: when to monitor application or business-related events (e.g., on UI every time clicked or in business layer), determining a strategy for using ASP.NET Health Monitoring, throttling, filtering, delivery method

Materiales

Indispensable. Visual Studio 2010 profesional o superior. Se puede bajar el RC.

MSDN y seleccionar las opciones de .Net Framework 4

Material de Microsoft Learning no hay disponible aun.

Material bibliográfico Self-Pace Training Kit. Para el framework 3.5 (verificar las diferencias)

 

Diferencias entre los frameworks

En MSDN y en StackOverflow