Métodos

Viernes de Robots

2007-04-20T14:27:21Z

Todos los viernes, a partir de hoy, voy a publicar algo sobre robots.

En agosto de 2005 publiqué una nota sobre los robots auto replicantes de la Universidad de Cornell, en ese tiempo no había YouTube, ahor puedo dejarles el video que mostraba ese trabajo:

Un hack simple en CSS

2006-02-22T14:21:10Z

Este hack es bastante simple, resulta que Internet Explorer 6 no respeta el atributo min-height para un elemento div.

Una solución, que asegura interoperabilidad, y no quebrar el soporte de los estándares es usar el atributo _height.
_height es ignorado por todos los browsers, y para IE es equivalente a height.

Un hack para tener un div de una altura mínima de 100 px sería:


Aca va mi texto

Cómo medir el desempeño de aplicacions ASP.NET

2005-11-30T23:42:49Z

La literatura disponible nos sugiere que para analizar el desempeño de las aplicaciones ASP.NET debemos medir al menos los siguientes parámetros dentro del Performance Monitor:

Performance object	Performance counter
ASP.NET	Application Restarts
ASP.NET	Requests Queued
ASP.NET	Worker Process Restarts
ASP.NET Applications	Errors Total
ASP.NET Applications	Requests/Sec
Processor	% CPU Utilization

Fuente: Help de Microsoft.Net SDK 1.1, sección:

Ms-help://MS.NETFrameworkSDKv1.1/cpguidenf/html/cpconperformancecountersforaspnet.htm

Application Restarts: indica cuantas veces una aplicación ASP.NET se re inicializa, lo ideal es que este parámetro sea 0 (cero), pues una aplicación sin problemas no debe presentar re inicios, salvo cuando se hagan updates o se instalen nuevas versiones de alguna componente.

Request Queued : Cuantos requerimientos se encuentran encolados esperando una respuesta. Cuando este número empieza a crecer linealmente con respecto a la carga de cliente conectados, entonces el servidor web ha alcanzado el límite de requerimientos concurrentes que puede procesar. El máximo por omisión es de 5.000. Este parámetros se puede cambiar en el archivo Machine.config.

Worker Process Restarts: El número de veces que un proceso trabajando ha sido re iniciado en el servidor. Este número aumenta cuando se producen caidas inesperadas de algún proceso. Este parámetro no debe aumentar bruscamente, de hacerlo debe investigarse las causas de inmediato.

Errors Total: Es el número total de errores que ocurren durante la ejecución de requerimientos http. Incluye errores en el parser, errores de compilación, errores durante el procesamiento y errores de ejecución. Este valor debe ser revisado atentamente.

Requests/Sec: Es la cantidad de request por Segundo atendidos por el servidor web. Este valor representa el throughput real de las aplicaciones en el servidor web. Bajo carga constante este valor debe mantenerse dentro de ciertos rangos.

% CPU Utilization: es el porcentaje de utilización de la CPU, a mayor utilización de la CPU mayor será la contención de las aplicaciones.

]]> Parámetros más finos

Los parámetros descritos anteriormente son relevantes para monitorear aplicaciones, pero cuando se han detectado problemas entonces es bueno fijarse en estos otros parámetros:

Performance object		Performance counter
ASP.NET Applications		Pipeline Instance Count
.NET CLR Exceptions		# of Exceps Thrown
System		Context Switches/sec

Pipeline Instance Count: Es el número de instancias de pipelines para la instancia de ASP.NET indicada. Dado que un thread sólo puede correr en 1 pipeline, es mejor que este valor se mantenga bajo, pues este indica el número de request que están siendo atendidos por la aplicación.

# of Excepts Thrown:: Es la cantidad de excepciones generadas. Este valor se puede complementar con el parámetro que indica la cantidad de excepciones por segundo.

# Context Switches/sec: Este parámetro mide la tasa a la cual ocurren cambios de contextos de los threads entre todas las CPUs. Un valor muy alto de este parámetro implica una gran contención debido a locks o muchos cambios entre modo kernel o user en cada thread.

Recomendaciones de Microsoft

El documento ASP.NET Performance Monitoring, and When to Alert Administrators, disponible en línea en la siguiente dirección: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/monitor_perf.asp, nos indica en que fijarse y cómo tomar algunas medidas para evitar el colapso de las aplicaciones. También nos permite encontrar indicadores de que puede estar fallando en nuestras aplicaciones.

El artículo contiene enlaces a varios utilitarios, como snap.exe, que es una herramienta para recolectar datos para medir el desempeño de las aplicaciones.

Otro utilitario disponible es httpClient.exe que permite medir el TTLB (Time to last byte), un parámetro importante para medir la contención y la latencia de las aplicaciones.

Qqq.exe es una aplicación en modo comando de linea que permite stressar aplicaciones.

ErrorHandler.dll, es una dll que permite registrar en la bitácora de eventos (log) las excepciones no manejadas.

Todos estos utilitarios están con códigos fuente, por lo que pueden ser modificados para necesidades específicas.

También en el artículo se describe como con una modificación en el archivo global.asax, podemos registrar en el log la mayoría de las excepciones no manejadas.

Otras aplicaciones de depuración que también se mencionan en este artículo son sos.dll, winddbg.exe y cdbg.exe que permiten depurar en un servidor de producción, pudiendo incluso observarse el proceso de recolección de basura. O estudiar el contenido del heap del GC. El uso de estas aplicaciones es importante en este caso para poder detectar cuales son los objetos que llenan el heap y que obligan a realizar tanto garbage collection, como se pudo observar.

Web Services u Object Remoting

2005-10-20T02:14:11Z

Hace un tiempo publique en Netveloper un artículo sobre web services y object remoting. Puedes leer el artículo, pero también he decidido guardar una copia en este blog.

]]>
Conceptualmente Web Service y Remoting son lo mismo, objetos distribuidos. La diferencia principal es el protocolo.

En Remoting puedes usar protocolos no estándares. En Web Services usa SOAP, o RPC-XML, en genera estándares abiertos, sobre HTTP.

- Si quieres publicar a la web tus servicios, entonces debes usar Web Services, porque tus clientes pueden estar usando otro ambiente, como Java, PHP, etc, y lo que importa es la interoperabilidad.

- Si es para manejo interno, el remoting puede tener mejor performance si usas como otros protocolos, que usen TCP y manejen binarios, en vez de soap, de todas maneras remoting se puede hacer con soap pero es lo mismo que web services, si lo usas sobre IIS.

- Tu puedes tener remoting sin tener que instalarlos en el IIS. Eso puede tener ventajas también en el performance, pero tienes que preocuparte de blindarlo de todas las otras caracteristicas que te agrega IIS, como SSL, logging, seguridad, etc. En el fondo, es como que tuvieras que construir tu propio web server.
Por eso que se recomienda usar remoting en la intranet, donde normalmente la seguridad no es tan crítica porque se supone que todos los computadores son confiables (se supone).

- Probablemente, has visto mejor performance debido a la serialización. Los web services usan XMLSerializer, mientras que en remoting se usa SOAPFormatter o BinaryFormatter, que generan mensajes más comprimidos y se generan más rápido, además mandar un mensaje binario es más rápido que un XML, por ponerlo de algún modo. Además hay algunos detalles técnicos con respecto a la cantidad de conexiones que permite IIS sobre remoting, pero no creo que sea el caso.

¿Cómo decidir?

En Microsoft hay un artículo al respecto: ASP.NET Web Services or .NET Remoting: How to Choose

Otro artículo interesante está en Fuzzy Boundaries: Objects, Components, and Web Services.

En mi experiencia:

Si voy a interoperar con agentes externos, que no controlo, uso Web Services, porque es un estándar abierto.
Sólo uso object remoting en aplicaciones dentro de una intranet, porque muchas veces no puedes controlar los firewalls, routers, etc.
Sólo tiene sentido usar webservice u object remoting si los servicios van a ser usados entre máquinas distintas. Si no hay que usar objetos comunes y corrientes.
Object Remoting y Web services deben ser una interfaz a objetos de negocios internos, es decir, la lógica de negocios no debe estar en ellos, sino que en clases internas que se exponen usando estos mecanismos. Esto es conocido como el patrón Adapter o Wrapper, que sería más o menos como muestra la siguiente imagen:

Abusando de la notación UML, lo que la Figura muestra son algunas posibles configuraciones.

Tenemos:

Objeto de Negocio que implementa la lógica de negocios

Un WebService, que publica los servicios del objeto de negocios al mundo exterior.

Un Objeto Remoting que publica lo mismo para el mundo interior, usando object remoting.

Tenemos un cliente interno que podría usar web services o remoting.

Un cliente interno que usa directamente el objeto de negocios.

En este patrón usamos el web service y el remoting como un Wrapper, para publicar la funcionalidad, que la realiza el objeto de negocios, eso nos da flexibilidad, y re utilización de lógica.

Rompiendo las Reglas: : invocando métodos privado desde otra clase en C#

2005-10-19T23:09:44Z

Las reglas de la programación orientada al objeto (OOP) dicen que no se puede llamar a un método privado de una clase.

De modo que si se tiene la siguiente clase:

class MiClase
{
   private void MetodoPrivado()
   {
      System.Console.WriteLine("método privado invocado");
   }
}

No es posible llamar al método MetodoPrivado desde otra clase, incluso desde una clase derivada.

]]> Rompiendo las reglas

Pero en C# usando Reflection es posible saltar esta restricción, y llamar un método privado.

El siguiente código muestra cómo

using System;

using System.Reflection;

public class PrivateCaller
{

   static void Main()
   {

     PrivateClass a = new PrivateClass();

     BindingFlags eFlags = BindingFlags.Instance

                 | BindingFlags.Public

                 | BindingFlags.NonPublic;

     MethodInfo m;

     try
     {

        m = t.GetMethod("PrivateMethod", eFlags);

        if (m != null)
        {

          m.Invoke(objInstance, aobjParams);

        }

    }

    catch
    {
       throw;
    }
}
}

Por supuesto esto se puede evitar aplicando el atributo ReflectionPermission.

¿Para qué podría usarse esto?

Un uso interesante es cuando quieres hacer testing de clases, usando NUnit, por ejemplo, en ese caso puedes usar esto para probar métodos privados de una clase.

Otro uso es para invocar métodos de una clase a la cual no tienes acceso para modificarla.

7 Consejos para usar excepciones

2005-10-19T22:31:13Z

Aqui hay 7 consejos para el uso de excepciones en C#, pero creo que son también útiles para Java.

1) No utilice las excepciones para controlar el flujo de la aplicación.
2) Usar código de validación para evitar excepciones innecesarias.
3) Usar el bloque finally para asegurar la liberación de los recursos.
4) No atrape las excepciones que no va a manejar. .
5) Tenga en cuenta que relanzar excepciones (rethrowing) es costoso. Casi tan costoso como la excepción que se produjo.
6) Preservar toda la información de diagnóstico posible en los manejadores de excepciones. Esto es util para efectos de depurar.
7) Utilizar el Monitor de Performance para monitorear excepciones del CLR.

Gracias a Juan Daria Tempesta (Instructor DCE) por inspirar este artículo