Una de las pruebas mas importantes a realizar es la de stress, puesto que esto nos ayudara a comprender como se comportara nuestra aplicación web, cuando posea cierta cantidad de usuarios concurrentes visitandola. Por otra parte, dicha prueba nos permitirá conocer si nuestra aplicación se encuentra preparada, en el caso que reciba un ataque de tipo DOS (Denial Of Service), puesto que estos ataques son los mas comunes, y consisten en sobre cargar un web site con una gran cantidad de conexiones concurrentes.

Para realizar estas pruebas existen grandes cantidades de software, de los cuales voy a hacer referencia a uno antiguo, pero que me resulto muy util a la hora de utilizarlo, el nombre del programa es Microsoft Web Application Stress o también conocido como WAS.

Poseemos diversas maneras de configurar el software, la primera es la posibilidad de grabar una especie de macro para establecer un conjunto de acciones que deseamos que repita una cierta cantidad de veces,  o por otro lado simplemente introducir la url e indicarle que ingrese paralelamente las cantidades de veces que queremos testear.

Particularmente yo opto por la segunda opción, donde generalmente introduzco la url del website que deseo testear y tal vez alguna página interna como se muestra a continuación:

Por último solo resta configurar en la sección de “Settings” la cantidad de concurrent connections (en el ejemplo especifique 100) que deseamos testear y el tiempo (en mi caso durante 1 minuto) que durará nuestra prueba:

Una vez finalizados los pasos anteriores estamos en condiciones de hacer clic en ejecutar, y nuestra prueba de stress se encontrará corriendo durante el tiempo que hemos indicado en la sección settings.

Es importante destacar que para comprobar la carga que esta recibiendo nuestra aplicación se pueden configurar diversos contadores en nuestro servidor de testing (herramientas de las cuales hablare en un futuro post) para poder visualizar las conexiones concurrentes que posee y como reacciona el hardware a medida que dichos contadores incrementan.

Para finalizar el post dejo el link para descargar el Microsoft Web Application Stress desde mi storage, puesto que es muy dificil conseguirlo.

Con tan solo registrarse en Amazon EC2 y completar los datos de tu tarjeta de crédito accederás a la posibilidad de obtener distintas caracteristicas de servidores, o instancias como ellos le llaman, como detallo a continuación:

Standard Instances (para la mayoría de las aplicaciones webs)

• Small Instance (Default): 1.7 GB of memory, 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit), 160 GB of instance storage, 32-bit platform.
• Large Instance: 7.5 GB of memory, 4 EC2 Compute Units (2 virtual cores with 2 EC2 Compute Units each), 850 GB of instance storage, 64-bit platform.
• Extra Large Instance: 15 GB of memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform.

High-CPU Instances (mayor capacidad de microprocesador que ram, utilizada para aplicaciones intensivas)

• High-CPU Medium Instance: 1.7 GB of memory, 5 EC2 Compute Units (2 virtual cores with 2.5 EC2 Compute Units each), 350 GB of instance storage, 32-bit platform.
• High-CPU Extra Large Instance: 7 GB of memory, 20 EC2 Compute Units (8 virtual cores with 2.5 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform.

Pero sin duda lo que me resulto más interesante de éste servicio es la manera de cobrar que poseen, un verdadero cobro On-Demand. El servicio o mejor dicho cada servidor se cobra por hora total o parcial en el cual esta encendido, esto nos permite una gran flexibilidad a la hora de levantar nuevos servicios o de desechar servidores en caso de instalaciones de software fallidas.

Los precios de los servidores virtuales varían dependiendo la instancia elegida para levantar o lanzar como ellos le llaman. Los siguientes precios son de servidores windows (con su correspondiente licencia) y ubicados en Estados Unidos:

Standard Instances

• Small Instance (Default): u$s 0.125 por hora.
• Large Instance: u$s 0.50 por hora.
• Extra Large Instance: u$s 1.00 por hora.

High-CPU Instances

• High-CPU Medium Instance: u$s 0.30 por hora.
• High-CPU Extra Large Instance: u$s1.20 por hora.

Y por último, Amazon se encarga de darnos ancho de banda On-Demand también, el cual posee el siguiente precio:

Data Transfer In

• All data transfer: u$s 0.10 per GB

Data Transfer Out

• First 10 TB per Month $0.17 per GB
• Next 40 TB per Month $0.13 per GB
• Next 100TB per Month $0.11 per GB
• Over 150 TB per Month $0.10 per GB

Una vez que nos decidimos a probar este excelente servicio, luego del registro, tan solo tenemos que bajar un plugin que ellos han desarrollado para firefox, llamado Elasticfox con el cual, luego de agregar nuestra cuenta de e-mail, y los diferentes indentificadores o keys que nos solicita, podremos comenzar a levantar servidores y desde allí mismo nos dará un acceso directo para la conexión por escritorio remoto.

Actualmente me encuentro manejando un proyecto en el cual poseemos una infraestructura dentro de Amazon de más de 10 servidores, y nos resulto muy util y flexible para la administración de los mismos, así como también en casos de disaster recovery, puesto que hemos podido levantar nuevos servidores con la misma configuración en tiempos record desde 7 minutos.

Para finalizar el post solo me queda comentar que en tiempos de aplicaciones llamadas software as a services o aplicaciones webs que necesitan una gran flexibilidad a la hora de escalar, Amazon es la mejor solución sin ningún tipo de duda, y aún mas conociendo los tiempos que requiere solicitar en ocasiones un servidor a un data center, o los costos por tener un servidor desconectado.

Obviamente existen muchos servicios más que ofrece Amazon, e igual de importantes que el EC2, como son el de Storage, Load Balancing, y otros, pero los mismos quedaran para futuros posts.

Para resolver dicho problema, luego de varias consultas e investigaciones, logre conseguir 10 importantes items a tener en cuenta a la hora de pensar en el diseño de la base de datos, de un sistema que es accedido por miles y miles de usuarios al mismo tiempo.

Cabe resaltar que me encuentro hablando de un sistema totalmente dinamico, el cual por cada acceso necesita consultar si o si a nuestra base de datos, sin necesidad de poseer paginas estaticas. Los siguientes items no son los únicos, pero a mi entender son bastante importantes:

1.- Sin Tablas Temporales: No se debe utilizar tablas temporales en stored procedures, las famosas #tmps nos hacen consumir bastantes recursos de memoria, en reemplazo de las mismas, se utilizan los data type table. Su uso es bastante similar, ej:

DECLARE @tmp TABLE(Id int, UserName varchar(128))
INSERT INTO @tmp(Id, UserName)
VALUES(1, ‘dave’)

2.- FullText en varios discos: Para las búsquedas es muy común utilizar contains, los cuales buscan dentro de los FullText creados para ciertos campos de una tabla. Cuando se posee más de un FullText, es recomendable tener un disco para cada uno de ellos, puesto que los mismos ejercen mucha presión en el disco, de esta manera dividimos la presión separandola en discos distintos.

3.- Sin Like’s: Es importante reemplazar todos nuestros queries en los cuales utilicemos el famoso ‘like’, ya que el mismo consume mucho procesamiento para ser ejecutado, en reemplazo, se puede utilizar el Contains.

4.- LOCK de tablas: En cada consulta o SELECT las tablas necesitan ser lockeadas, para devolver ciertas información solicitada para los queries, esto es completamente innecesario el 99% de las ocasiones, y genera un problema muy grande en nuestra base, ya que al ser consultada por miles de transacciones, las mismas comienzan a dar time out. La solución es incluir la siguiente sitaxis luego de cada select que deseemos realizar:

SELECT Id, UserName FROM WebUser WITH (NOLOCK) WHERE Id=@ParamId

5.- Leer y Escribir: Para tener preparado el sistema para escalar de manera masiva, es importante tener en cuenta realizar dos diferentes conecciones a la base, una para leer información y otra para escribir en tablas. La velocidad es la misma, ya que las conecciones se ejecutan de manera paralela, y en un futuro (inmediato tal vez), se podra utilizar un servidor de sql para escribir y x servidores a los cuales se replicara, y estos seran a los que consultaremos la información desde los web servers.

6.- Redundar información: En ciertas ocasiones se necesita realizar una acción que puede requerir varios recursos del sistema, es necesario analizar CUANDO es conveniente hacerla. Por ejemplo, saber cuantas relaciones hijas posee un detarminado registro, para éste caso analicemos cuantas veces se insertaran mas relaciones hijas o cuantas veces se consultaran la totalidad de las mismas. En la mayoria de los casos de uso, seguramente se encontraran con que las consultas son mas solicitadas que las escrituras, para ello se pueden hacer tablas de history, donde la información de los counts se pueda guardar, la misma puede ser guardada mendiante un trigger en la tabla que se desee contar, y de esta manera actualizar el history en cada insert, update o delete. Otra posibilidad es hacer correr un job cada x tiempo y que actualice la tabla history.
Es posible tambien tener las tablas con todos los registros en otra base de datos, y que ésta se encargue de replicar la información en los servidores de consulta.

7.- Evitar los Count(*): Esta consulta muchas veces hace que nuestros queries posean mayor tiempo en su ejecución, una posibilidad de evitarlo, es realizando tablas donde guardemos los contadores, y actualicemos los campos con incrementos o decrementos en los registros. Reconozco que en ciertos casos, genera problemas utilizar éste metodo, es por ello, que debemos analizar muy bien, cuando es necesario utilizar los COUNT.

8.- Index: Antes de realizar un indice, debemos analizar por cuales campos realizamos las consultas a ciertas tablas, una vez que obtuvimos dicha información, debemos generar diferentes indices en las tablas, en los cuales seleccionaremos los campos por los cuales realizamos los filtros en las consultas, o sea en nuestro WHERE.

9.- IS NULL: Para realizar consultas sobre un null en un campo, no se debe realizar mendiante una igualdad, en cambio se debe realizar mediante un “IS”, como muestra el siguiente ejemplo:

SELECT Id, UserName FROM WebUser WITH (NOLOCK) WHERE Name IS NULL

10.- WARNING CON LOS LOWER: Otro gran error es realizarle un LOWER a un campo de una tabla, para realizar comparaciones mediante igualdades. Si desde el comienzo sabemos que ésta acción será necesaria en un futuro, entonces, deberiamos insertar los registros con minúsculas. A continuación un ejemplo erroneo:

SELECT Id, UserName FROM WebUser WHERE LOWER(Name)=LOWER(@ParamName)

Si se cumplen los anteriores 10 items la presión sobre el servidor en el cual se encuentre la base de datos, será increiblemente menor.

Cada vez que esto ocurre es un gran problema tener que poner la página de “Estamos realizando mantenimiento.” puesto que habria que levantar otro web site, y poner que cada uno de los errores apunte a la misma página.

Afortunadamente con .Net disponemos de la posibilidad de tan solo poner un archivo llamado “app_offline.htm” en el directorio raiz de nuestro web site, y cada vez que se realice una petición a alguna página interna, .Net detectará la existencia de éste archivo y mostrara su contenido, en cada solicitud que se realice.

Una vez finalizado el update o solucionado el problema, con solo eliminar dicho arhivo, ya volveremos a obtener las paginas que solicitemos.

Muchas veces el tiempo de carga de una página se encuentra comprometido, por la cantidad de información que es necesaria joinear desde la base de datos. En éste post propongo una nueva manera de traer y mostrar información, muy parecida a como actua php.

Solo es necesario obtener todos los registros a mostrar desde la base de datos mediante un DataAdapter y luego mediante un Fill, llenamos de DataTables un DataSet. De ésta manera, podremos obtener un XmlDataDocument y comenzar a utilizar la clase XslTransform.

Para realizar una transformación, solo se necesitan un XmlDataDocument y un archivo Xsl (recomendado en file system), y con ambos componentes obtendremos un html como resultado.

El return nos llega como tipo string y a éste mismo lo podremos situar en cualquier posición de nuestro aspx. A continuación un breve ejemplo de cómo realizar una trasformación:

   StringBuilder StringControl = new StringBuilder();
   XslTransform XslTran = new XslTransform();
   string XslPath = Server.MapPath(“Myfile.xsl”);
   MyObject data = new MyObject();
   data.Load();

   XslTran.Load(XslPath);
   XslTran.Transform(data.XmlDataDocument, null,
   new StringWriter(StringControl), null);

   ltContent.Text = StringControl.ToString(); //aquí llega cargado con el html

Para cerrar el post quiero comentar que ésta clase se encuentra obseleta en la versión 2.0 de .net, de todas maneras se puede seguir utilizando, pero en la nueva clase que se llama XslCompiledTransform encontre mas desventajas que en la clase XslTransform.

Y por último, quiero aclarar que dicha optimización es recomedable aplicar en escenarios de front end, o sea de consulta de datos, ya que en un back end, muchas veces es necesario aplicar capaz de seguridad para obtener la información.

 www.myspace.com/User.aspx?UserName=david

El resultado proyectado a la visión del usuario será el mismo, pero lo que cambia es la facilidad de la url a la hora de recordarla.

Para poder integrar esta funcionalidad en un WebSite, primero hay que bajar el módulo de rewrite y saber algo de Regex, ya que todas las reglas que se crean allí, utilizan ésta sintaxis. Una vez bajada la dll y el ini, debemos configurar el WebSite, anteriormente creado, yendo a propiedades del mismo y a la solapa ISAPI Filters:

Una vez allí, clic en el botón “Add…” y en la caja que aparece, se debe ingresar la ruta en la cual se encuentra la dll anteriormente descargada. Para finalizar, se debe stopear y startear nuevamente el Application Pool asiganado a ese WebSite.

Como último paso para lograr el rewrite que posee MySpace, debemos agregar las siguientes linea en el archivo mod_rewrite.ini:

RewriteRule (.*\.aspx$) /$1
RewriteRule ^(\/\w+)$ /User.aspx?UserName=$1

La primer linea se utiliza para que en nuestro directorio raíz reconozca todos los archivos, cuya extensión es .aspx y no les haga un rewrite, y la segunda línea nos permite enviarle al archivo User.aspx, como parametro, lo que el navegante haya escrito luego del dominio y la barra (ojo que el parametro llega con la barra incluida).

Si tenemos carpetas dentro de nuestro site y no queremos que se reescriban, debemos agregar la siguiente línea en medio de las dos anteriores:

RewriteRule ^\/Images\/(.*) /Images/$1

En éste caso no redireccionará /Images a User.aspx, sino que seguira apuntando al mismo lugar, y asi podemos crear tantas excepciones como sean necesarias.

Es importante aclarar que cada vez que se realice un cambio al archivo mod_rewrite.ini, habra que reiniciar el application pool de ese website, para que las nuevas reglas sean cargadas.

Para ello solo debemos agregar el using de System.Net y podremos acceder a la clase llamada HttpWebRequest, para realizar peticiones web desde nuestro servidor, a continuación expongo un método a modo de ejemplo:

private string GetData()
{
        HttpWebRequest request =
        (HttpWebRequest)WebRequest.Create(“http://domain.com/file.xml”);

        request.MaximumAutomaticRedirections = 4;
        request.MaximumResponseHeadersLength = 4;
        request.Credentials = CredentialCache.DefaultCredentials;
        HttpWebResponse response =
        (HttpWebResponse)request.GetResponse();

        Stream receiveStream = response.GetResponseStream();
        StreamReader readStream =
        new StreamReader(receiveStream, Encoding.UTF8);

        string res = readStream.ReadToEnd();

        response.Close();
        readStream.Close();
        return res;

    }

Este método retorna un tipo de dato string donde viene cargado todo el html o xml que devuelve la consulta, es importante aclarar que si utilizamos una url que retorna un error (por ejemplo el 404, página no encontrada) ésta clase produce una exception que debremos cactchear.

Con tan solo registrar la assembly RessToolKit de la siguiente manera:

<%@ Register Assembly=”RssToolkit”
Namespace=”RssToolkit.Web.WebControls” TagPrefix=”rss” %>

Ya puedes comenzar a integrar un nuevo tag en el código de la página. Este webcontrol recibe como parametro un int llamado MaxItems, en el cual decides la cantidad de items a mostrar (si escribes 0 tomara todos) y otro parametro de tipo string llamado Url, donde se debe especificar el Uri del xml.

Por último debemos integrar un DataList donde el DataSourceID será el ID de nuestro webcontrol creado anteriormente, y con un simple Eval escribiremos el nombre del nodo que queremos llamar, como muestra el siguiente ejemplo:

<rss:rssdatasource id=”RssDataSource2″ runat=”server” maxitems=”3″ Url=”http://www.clarin.com/diario/hoy/um/sumariorss.xml“>
</rss:rssdatasource>
<asp:DataList ID=”BlogList2″ runat=”server” DataSourceID=”RssDataSource2″>
   <ItemTemplate>
      <asp:Panel ID=”panelHeader” runat=”server”
       Style=”width:400px; display: block; font-weight: bold;”>
         <%# Eval(“title”) %>
      </asp:Panel>
      <asp:Panel ID=”Panel1″ runat=”server”
      Style=”margin-top: 3px; width:400px;margin-bottom:10px; “>
         <%# Eval(“description”) %>
         <asp:HyperLink ID=”hlMore” runat=”server”
         NavigateUrl=’<%# Eval(“link”) %>’ Target=”_blank”
         Text=”leer más”></asp:HyperLink>
      </asp:Panel>
   </ItemTemplate>
</asp:DataList>

Para bajarte ésta dll lo puedes hacer desde CodePlex haciendo clic aquí donde también encontraran el código fuente.

El primer paso, para no tener que integrar un servidor de e-mails dedicado, necesitamos registrar nuestro dominio en google apps y solo crear un e-mail, el cual sera el administrador, ya que vamos a necesitar apuntar el *@sudominio.com al único e-mail verdaderamente existente. De ésta manera solo vamos a tener que chequear una dirección de e-mail y no tantas, como usuarios tenga el sistema.

El segundo paso es desarrollar una herramienta que nos chequee mediante pop3, si tenemos e-mails nuevos dentro de la cuenta en la cual recibe todos los correos. Para ello podemos utilizar varias existentes en el mercado, yo particularmente tuve muy buena experiencia con una llamada Mail.dll que es bastante simple de implementar. Una vez que obtenemos el attach de cada e-mail nuevo (siempre realizando todas las validaciones correspondientes de formato, peso, etc) lo que sigue es guardar éste adjunto en una carpeta temporal donde el nombre del archivo tendrá el siguiente formato:
{UserName}-{Password}@[{EmailId}][{AttachId}].jpg
De esta menera vamos a evitar cualquier tipo de repetición, porque hay que recordar que todos los archivos se guardarán en la misma carpeta temporal.

El tercer paso es el mas importante de todos, ya que tenemos que desarrollar otro proceso que chequee constantemente la carpeta temporal, preguntado si existen archivos para procesar o no. Para esto vamos a tomar los datos guardados en el filename, antes del arroba y realizamos un split con el ‘-’ para obtener UserName y Password separados. La idea es tener un stored procedure preparado para recibir estos dos datos y si la validación resulta OK ya guardar toda la info de esta foto y retornar la ruta en la cual sera publicada. En ocasiones ésta ruta necesita ser encriptada por algún algoritmo (en otro post publicaré como desarrollar un algoritmo para file system) es por ello que el stored retornará un output con la ruta en la cual el proceso debe guardar la foto. En caso que la validación de UserName y Password resulten false solo tendremos que eliminar el archivo de la carpeta temporal.

Con estos tres pasos tenemos un sistema de publicación de fotos en web ya analizado y testeado, es importante tener en cuenta aplicar constantes configurables para tiempos de espera, entre cada requests al pop3 y, para la búsqueda de nuevos archivos dentro de la carpeta temporal, asi como también el limite máximo de peso de una foto, ya que esto implicara un delay en la descarga sincronica.

A decir verdad WordPress tiene un gran problema si levanta el administrador en español, me costo mucho configurar mi dominio y finalmente me di cuenta que tenia que terminar pagando USD10 para poder utilizar uno propio. Pero no basto con apuntar los 3 DNS y pagar en PayPal (también tuve que registrar un usuario, con lo que odio hacer eso…) sino que luego de todo esto, el admin no me reconocia los 10 créditos que había comprado… un desastre total, tuve que cambiar el idioma de mi panel de control a ingles para poder agregar mi dominio, muy mal wordpress team.

Pero bueno, en el final del día pude levantar mi blog:

www.davidbalogh.com.ar

En este espacio en la web voy a publicar todas mis investigaciones e ideas en las cuales me encuentro trabajando. Todos mis post van a tratar sobre tecnología y sintaxis de programación, donde la mayoria de las veces hablare de Microsoft .Net.

El objetivo es dejar publicado de manera abierta toda la documentación que pueda llegar a generar.