viernes, 2 de noviembre de 2012

Correr Netcat en segundo plano y redirigir la salida a un archivo

Hace unos días me enfrenté con un problema que me dió verdaderos dolores de cabeza. Resulta que necesitaba escribir un socket TCP para conectarme a un servidor que envía información a todos los clientes que se conectan a el. Este cliente TCP debía estar siempre conectado y recibiendo información del Servidor. Yo por su parte debía redirigir la salida de dicho socket a un archivo para que después otro programa leyera dicho archivo y lo procesara. Para hacer el trabajo más ligero, decidí probar con telnet, pero se me presentaron algunos inconvenientes, así que decidí utilizar netcat.

Sentí una gran alegría al ver que netcat trabajaba muy bien. El problema era que tenía que mantener mí sesión SSH abierta para que mí socket siguiera funcionando, cosa que supuse era sencilla con el uso de nohup. Pero que sorpresa me llevé al ver que nohup no lograba poner a mí socket en segundo plano. Me la pase googleando y probando alternativas todo el día hasta que después de toda una jornada laboral de trabajo encontré la solución que es bastante sencilla:

Lo único que se debe hacer para correr netcat en segundo plano es añadir la opción -d, que le indica a netcat que no lea de la salida estándar (el teclado). Mí comando para correr netcat en segundo plano quedó como sigue:

nohup nc -d <IP Servidor> <Puerto Remoto> & >> archivo.log

Es importante señalar que esta solución funciona en un Ubuntu 11.10, no lo he probado en otras distribuciones de Linux ni en otras versiones de Ubuntu, pero me imagino que no debe haber mucha variación. Espero este texto sea de utilidad, ya que existe poca información acerca de como resolver este problema y la información que existe se encunetra en inglés.

sábado, 4 de agosto de 2012

Importancia del uso de índices en una Base de Datos MYSQL

Un día me encontraba tratando de resolver un problema de lentitud de un programa. El programa ejecutaba consultas a una tabla y después sobre la misma tabla actualizaba un campo para indicar los registros que ya habían sido procesados.

Al comenzar a debuggear el programa revisé el performance del servidor donde este programa se ejecutaba, revisé casi línea por línea el programa y me dí cuenta para mí sorpresa que el problema se encontraba en la consulta que actualizaba los registros ya procesados. Cada sentencia UPDATE tomaba aproximadamente 20 segundos en ejecutarse, demasiado tiempo para procesar información de una tabla que recibe al rededor de 700 registros por minuto.

Buscando información en foros, manuales y blogs y después de probar varias posibles soluciones, me dí cuenta que el problema se resolvía indexando el campo por el cual se actualizan los registros. La tabla en cuestión es InnoDB y el campo por el cual se realiza el UPDATE es de tipo entero, sin embargo este campo no estaba indexado y al indexarlo me dí cuenta que el UPDATE tomaba menos de 1 segundo en ejecutarse. De esta forma se resolvió mí problema.

Con esta información me dí cuenta que en tablas grandes que son InnoDB, los UPDATES sobre campos de tipo entero (INT) son muy rápidos.

Bienvenida

Este blog está realizado con la finalidad de contribuir con la comunidad de Internet y proveer de tips y consejos de mí experiencia laboral. Espero sea de utilida.