Ir al contenido principal

Desacoplamiento. Pruebas de desempeño.

Una de las claves de una arquitectura exitosa es el desacoplamiento que reina entre sus capas. Desde otra perspectiva: cuan flexible es nuestra aplicación a los cambios que impone el entorno. Un cambio imprevisto en las condiciones de negocio, o de plataforma, puede hacer que todo nuestro desarrollo sea obsoleto, si este no fue planificado correctamente.

El acceso a los datos puede venir bien, para dar un ejemplo de ello. De menor a mayor desacoplamiento:

Escribir un select directamente en el código nos obliga a volver a los fuentes ante un cambio simple en el "como" obtener o filtrar, los datos de una tabla. Podríamos dejar de lado esa practica y utilizar procedimientos almacenados (stored procedure). Conseguiríamos un poco mas de flexibilidad, pero seguimos lejos del desacoplamiento del que hablamos. Bien, saltemos un par de casilleros, y digamos que en el código llamamos a métodos estáticos de una clase helper, para realizar nuestra consulta, sin conocer siquiera el motor de datos utilizado. ¿Conforme? De ninguna manera. Tiramos otra vez, y dejamos atrás varios casilleros mas, y decimos que tenemos: Una capa de datos independiente de la capa de negocio a la que le solicitamos cierto dato, sin necesidad de conocer donde residen los mismos, ni como los obtiene. Esta capa puede implementar lo necesario para obtener, indistintamente, la información de un XML, de un MySQL, PostgreeSQL, Oracle, SQL 2000, SQL 2005, un archivo de texto, un Excel, de un WebServices, etc. Podemos decir ahora: estamos desacoplados de la fuente de datos.

Mas alla del ejemplo introductorio, no hay dudas de los beneficios de estar desacoplados. Pero me preguntaba ¿A que costo?¿Cual es la diferencia de desempeño que tienen ciertos desacoples?¿Es conveniente dejar de lado estas buenas practicas para ganar desempeño?. Acercándonos a una implementación dada, podríamos tener nuestro servicio, en el mismo assembly como hasta en la otra punta del planeta. WCF (Windows Communication Fundation) nos posibilita abstraernos del como accedemos/transmitimos los datos al momento de codificar, con solo configurar algunas cosillas, por lo que nos daría la flexibilidad necesaria.

Ubiquemos todo esto en un ejemplo practico. Tenemos un sitio web de alta concurrencia en el que estamos pensando en una arquitectura basada en servicios, y tenemos dos modelos de como implementarlo:

1) Un servidor que tenga el sitio web publico, y los servicios hosteados en si mismo.
2) Tener dos granjas de servidores, una web y otra de servicios.

La primera, nos permite escalar perfectamente, pero... si nuestras reglas de negocio son lo suficientemente complicadas y hacen que su procesamiento ocupe, y de gran manera, el CPU del servidor, ¿Que pasaría?
Digamos que tenemos 5 servidores, web y servicios en cada uno. Esta cantidad es suficiente para atender todos los request web de los usuarios, pero al ser nuestra capa de servicio "muy pesada" hace que el server este al 100%, y afecte a los web, y por lo tanto a los usuarios. Escalamos horizontalmente, y agregamos 5 servidores mas para distribuir la carga y lograr que el procesamiento de los servicios no llegue a afectar a la parte web. Todo funciona correctamente, pero ...
Como nuestra arquitectura no facilita el desacople, podríamos bajar el numero de servidores web a tres o cuatro, y los servicios ubicarlos en otra granja, con 5 servidores dedicados exclusivamente a esta tarea. Es cierto que tenemos mas puntos de falla, y otras contras, pero no es ese el terreno que vamos a pisar.

Entonces, mediante algunas pruebas de código vamos a buscar diferencias de desempeño en como y desde donde se invoca a un servicio.
Intentaremos responder si es conveniente o no plantear una arquitectura flexible, desde el principio, que nos permita mover la capa de servicio a otra granja, sin que esto implique "gastar" CPU inncesearia mientras tengamos todo en cada servidor.
De paso vamos a probar diferentes maneras de invocar un metodo, y sacar estadisticas de ello.


Las pruebas se realizaran en una aplicacion de consola y consistirán en invocar un servicio simple de suma durante 1 segundo, y así contar las invocaciones logradas. Se tomaran diez muestras por método, repitiendo la operación 3 veces. En total 30 muestras. Publicaremos los fuentes de cada método, y luego tomaremos las muestras todas juntas.

Métodos
  1. Todo en un mismo assembly, e invocando directamente un metodo estatico.
  2. Invocando mediante delegate
  3. Invocando mediante delegate anónimo.
  4. El servicio de suma en otro assemblie, y referenciado.
  5. El servicio de suma en otro assemblie, pero invocando mediante reflection.
  6. XML Web Services
  7. WCF con varias maneras de hacer binding.


Los resultados:








































NormalDelegateDel.AnonimoDesde DLLReflectionXML WSWCF - netTCP
Minimo50.620.76846.581.62643.328.32057.276.655160.719120392
Promedio66.758.23750.330.93647.165.26363.196.265178.338130450
Maximo70.725.23655.898.83151.218.40769.487.090189.588141474


Y las concluciones:

... !!!

Comentarios

Entradas más populares de este blog

[links] Links para descargas de Visual Studio 2008 SP1, Framework .NET 3.5, su SP1 y Sql Server Express 2008

En el proceso de modernizacion de los entornos de desarrollo que comunmente uso para trabajar, acumule estos links de descargas, que paso a compartir para ahorarle la busqueda a algun colega:

Microsoft .NET Framework 3.5 [web] 197.12 MB

Requerimientos:Windows Server 2003Windows Server 2008Windows VistaWindows XP256 MB de RAM500 MB de espacio disponible en disco



Microsoft .NET Framework 3.5 Service Pack 1 [web] 231.5 MB

Requerimientos:Windows Server 2003Windows Server 2008Windows VistaWindows XP256 MB de RAM500 MB de espacio disponible en disco



Windows Installer 4.5 Redistributable - Español [Windows Server 2003] [web] 3.2 MB

Requerimientos:Windows Server 2003 Service Pack 1Windows Server 2008Windows VistaWindows XP Service Pack 2



Microsoft Visual Studio 2008 Service Pack 1 (iso) [web] 913.79 MB

Requerimientos:Windows Server 2003Windows Server 2008Windows VistaWindows XP1024 MB de RAM



Microsoft SQL Server 2008 Express [web] 99.2 MB

Requerimientos:Windows Server 2003 Service Pack 2Windows Server …

Pruebas de desempeño - XML Webservices

En esta oportunidad, el desacoplamiento al que llegamos nos permite traspasar las barreras de la organizacion. Nuestro servicio de suma, ahora lo proporciona un Werbservices. Por lo tanto, podria estar fuera nuestra bateria de servidores, y la aplicacion funcionaria igual. Por lo menos en resultado, no en prestaciones.
Los cambios:

Agregamos en Web services al proyecto, con este codigo en el ASMX.



using System;
using System.Web;
using System.Collections;
using System.Web.Services;
using System.Web.Services.Protocols;

[WebService(Namespace = "http://tempuri.org/")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
publicclass Servicio : System.Web.Services.WebService
{

public Servicio(){}

[WebMethod]
publiclong sumar(long n)
{
return ++n;
}

}

Incluimos la referencia WEB a nuestro WS, y estos cambios en la aplicacion.



using System;
using System.Collections.Generic;
using System.Configuration; // Agregar referencia System.Configuration 2.0
using System.IO;
using System.Text;
using System.Th…

Editando DTS de MS SQL 2000 en SQL Server 2005

Con MS-SQL 2005 y su consola de administración Microsoft SQL Server Management Studio, nuestros DTS, que tan bien funcionaban en MS-SQL 2000 y su consola, perdieron un poco de terreno.

Por diferentes razones, hasta que no llego una necesidad real de crear o editar DTS en SQL Management Studio, utilizábamos el cliente del SQL 2000 para ello. Bien, llego esa necesidad y vamos a instalar lo necesario para que con SQLMS pueda editarlos. Lo necesario, por ahora es solo esto:

Descargar este archivo para su versión en español o este para la versión en ingles.

La instalación, incluso con el Management Studio abierto y la lista de DTS visibles, es simple:
Doble click en el archivo descargado, un par se siguientes y un finalizar.