La contradicción de las aplicaciones ultra parametrizables y customizables

Estas  últimas semanas han estado un poco aburridas. No se han presentado problemas de aplicaciones pero seguramente se presentarán… tarde o temprano. Sin embargo, a falta de problemas que se presentan, nos encargamos de buscarlos, o más bien dicho, de forzarlos.


Una de las últimas actividades realizadas corresponde a la revisión de una aplicación que será liberada pronto. Esta revisión consistió en generar pruebas de carga para diferentes casos de uso y analizar los resultados.

Actividad realizada

Grabamos los scripts con [ACT], los modificamos con [fiddler] y los ejecutamos con [ACT].

Resultados

Los resultados fueron sorprendentes, y no lo que se esperaba. La aplicación no lograba procesar más de 0,5 requerimientos por segundo, consumiendo el 70% de la CPU con un sólo usuario conectado.

Análisis detallado

La aplicación analizada pertenece a la fauna de aplicaciones que han sido concebidas con la idea de ser totalmente customizables y parametrizables. Particularmente no estoy en contra de las aplicaciones parametrizables, y más aún, el no permitir que se adapten a ciertas variables es una limitación, y producirá en el cortísimo plazo problemas de mantención.

¿Cuál es la arquitectura utilizada?

La aplicación está montada sobre un framework desarrollado por un tercero.
Nota aparte: ¿Se han fijado que ahora todo el mundo hace frameworks?, ¿y a casi cualquier cosa desarrollada le llaman framework? Bueno, volvamos a la aplicación.


Esta es una aplicación web desarrollada en .net montada con este framework. No puedo decir que es una aplicación ASP.NET ya que apenas utiliza ASP.NET.

¿Por qué no usa ASP.NET?

Cada página no tiene controles asp.net; ninguno. Así de simple. Incluso las páginas generadas no tienen viewstate, prueba de lo anterior.

¿Cómo es esto posible?

Las páginas son generadas desde una definición existente en algún archivo XML (400 kilobytes), el cual, en algún lugar indica con cierto criterio, donde buscar los controles que deben pintarse en la página, los que están definidos en una tabla en una base de datos de SQL Server.


Debido a lo anterior, no es de extrañarse que para pintar una página, recurra muchas veces al servidor de datos. Para complicar aún más el escenario, cada ítem de la página es un ítem en la base de datos. Todo esto para poder definir paramétricamente las páginas. Notar al final las contradicciones de este modelo.


Más aún, la lectura desde el servidor SQL es procesada en largas funciones y ciclos, los cuales, para más males, concatenan string en algunos casos. El resultado de esta gran concatenación es, como alguno de ustedes podrá adivinar/suponer, XML.


Luego, este XML es transformado en conjunto con un XSL que define la salida de la página. Recordar que el requerimiento era que la aplicación fuese mantenible fácilmente, algo que ya no se cumple.


Ok, después de todo este trabajo, la página está pintada.

¿Qué pasa si hago clic sobre algún botón?

Cómo no existen los controles de servidor, no existe un evento asociado al botón, y la página se procesa como se hacía en ASP, es decir, con request.form[] y sus amigos.


Lo bueno al menos es que como todo esto lo maneja este framework, es él el encargado de procesar el evento y llamar a las funciones de negocio asociadas.


Las funciones de negocio se definen en un XML, de varios cientos de kilobytes. En este archivo, utilizando información súper rígida, se define la ruta física del assembly, además del tipo y la función que se llamará. No es necesario definir los parámetros de entrada, porque se usa un único parámetro de tipo string, que en el fondo, es un XML.


Si en las funciones de negocio se requiere llamar a un procedimiento almacenados (SP), hay que hacerlo a través del framework. Obviamente hay que construir un XML con la información del SP y los parámetros. Sin embargo, en el XML no se escribe el nombre del SP sino que un pseudo-nombre asociado a una pseudo-base de datos. Entonces, el framework internamente se encarga de ir a buscar a otro XML, y que tiene como nombre el mismo valor de la pseudo-base de datos, la definición real del SP.

Contradicciones vitales

El sistema fue concebido así para poder ser fácilmente adaptable sin necesidad de mayores cambios en el código. La contradicción está en que el único que es capaz de hacer algún cambio en la aplicación es alguien que domine todos los elementos mencionados hasta ahora.


Es interesante que no se esté utilizando el GAC. ¿Será porque los assemblies cambian mucho en el tiempo y existe un costo administrativo de firmarlos e incluirlos en el GAC? Si cambian mucho en el tiempo, ¿Cuál era el problema de hacer una aplicación más rígida, o dicho de otra forma, una aplicación normal utilizando controles ASP.NET y librerías de clases?

Otra información

¿Si se preguntan cuántas veces baja a la base de datos para pintar una página especifica?
Más de 400


Saludos,
Patrick

6 thoughts on “La contradicción de las aplicaciones ultra parametrizables y customizables”

  1. yyy…es muy difícil, porque en este caso, lo que se tendía que haber hecho es botar todo y comenzar de nuevo. Es difícil hacer reingeniería con algo así. El problema es muy de fondo.

    Otra opción que se usa bastante en algunas empresas es “arreglar” estos problemas agregando más hardware. Para mí, esa es una pésima solución (aunque te puede salvar por un rato),  pero entras en un ciclo donde irremediablemente, tarde o temprano, deberás arreglar la aplicación.

    Conozco un caso donde “arreglaron” con hardware hasta que llegaron a 30 máquinas. Hicieron una gran reingeniería (tarde, pero al fin), y lograron hacer funcionar todo con sólo 4 maquinas. Al menos espero que ellos hayan aprendido la lección.

    Saludos,

    Kent

  2. Bueno, esta especie se encuentra en abundancia en nuestra fauna chilena, pero lo más simpático de todo es cuando te obligan a usarla, incluso dando uno las razones de por que no se debería usa (perdida de años luz de la forma de desarrollo), pues bien la culpa nunca es del chancho si no del que le da el afrecho.

    Tengo claro cual es tu cliente, ya que nació de esa zona esta gran creatividad. Y si necesitas ayuda para poder arreglar el entuerto también puedo aportar con unos lineamientos.

    Me ha tocado sufrir por la chispas de genialidades de algunos….

    Saludos,

  3. Darz,

    Muchas gracias por no dar nombres de clientes. Efectivamente es una fauna que se ha poblado por todo sud América y que tiene poco peligro de extinción. Si por mi trabajo me tocase volar fuera de Sud América podría decir si se ha repartido por todo el mundo.

    Si me puedes mandar tu contacto para tenerlo en caso de ser necesario, te lo agradecería. No es necesario lo posees aquí. Puedes mandarme un contacto (http://msmvps.com/blogs/pmackay/contact.aspx) con tus datos.

    Saludos,
    Kent

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>