nov 13 2012

¿Qué cliente de FTP usas?

tatai

Esta pregunta me ha hecho hoy Mr. Client*. Reconozco que no ha sido el primero pero supongo que tampoco será el último.

Mi primera respuesta es que mi religión me lo impide. Ya no recuerdo la última vez que usé FTP por cuenta propia. En caso de necesitar FTP siempre usaré SFTP y, si tengo acceso shell, SCP. No hay nada mejor que una consola y, si es posible, una sesión SSH.

Pero realmente no quería hablar de FTP, sino de clientes para estos servicios. No tengo nada en contra de ellos y si los usas me parece muy bien, pero voy a explicar porque tiendo a no usarlos si es que puedo cambiarlos por comandos en la consola o por acciones que pueda controlar directamente con el teclado. ¿Raro? ¿Arcaico? ¿Friki? Ni mucho menos, eficiente.

Y si el simple hecho de mover las manos entre el teclado y el ratón hace que seas más lento, podemos incluir el hecho de que para la mayoría de las acciones que tengas que hacer bastaría con repetir la misma acción (subir un fichero, copiar una carpeta, borrar un fichero, etc).

Ahí van un par de las preguntas más frecuentes:

“¿Y tienes que estar todo el rato conectándote? ¿Y la contraseña?”

Para esta pregunta, la solución está en este post en el que explica como crear un par de claves que te permita acceder al servidor de forma sencilla y segura.

La respuesta es sí, pero es que conectarme al servidor es una cosa muy sencilla. Además, para configuraciones habituales o que requieran de muchos parámetros, siempre podemos “Tunear” un poco nuestro ssh ;)

 “¿Y cuando tienes que subir varios ficheros?”

El tema se pone interesante. Depende del caso, desde el más sencillo usando wildcards:

scp *.log host:/var/log

O algo más complicado:

scp {script,config}.php host:/var/www

O siempre está la opción de hacernos un mini-script que suba varios ficheros, aunque recordemos que siempre que podamos hacerlo en la misma conexión, ganaremos tiempo.

“Vale, ¿y cuando tienes que subir muchos ficheros? ¿Y carpetas?”

Para las carpetas, nada como la opción -r que permite subir ficheros de forma recursiva, incluyendo directorios.

Cuando tienes que subir muchos ficheros, automatización con un script o incluso usar un tar.gz, subir y descomprimir. Si realmente tienes que trabajar con cambios en muchos ficheros en distintos sitios, la mejor opción sería rsync lanzado manualmente (hasta el momento, no me he encontrado con este caso, pero bueno, será por opciones).

O puedo asegurar que si os gusta la velocidad, lo primero es aprender a no usar el ratón (que no quiere decir que no lo uséis) y luego, a automatizar los trabajos repetitivos. Conseguiréis ser más rápidos, eficientes y, como no, aprenderéis más cosas.

Que no se me enfade nadie, cada uno es libre de usar las herramientas como quiera. Sólo he dado mi propuesta que, además, vale tanto para Linux, Windows o Mac.


*: cariñosamente para el post de hoy ;)


oct 21 2009

Trabajando con eficiencia

tatai

Muchas veces considero que es una obsesión, pero de lo que estoy seguro es que muchas más veces gano tiempo pensando un poco y haciendo las cosas mejor y más rápidas.

El caso que voy a presentar ahora es lo que yo considero “la forma más rápida de descargarnos un dump de una base de datos”. Añadamos como condición que tenemos que usar un protocolo cifrado, en este caso, SSL. Para cualquier de los dos ejemplos que voy a presentar, contamos que tenemos autentificación en el servidor remoto (ahora que sabemos cómo hacerlo).

Empecemos por el final. Cómo se nos ocurriría hacerlo directamente. Básicamente los pasos serían estos:

# Nos conectamos al servidor
ssh user@server.com
# Realizamos el dump de la base de datos
mysqldump -u mysqluser -p mysqldb > dump.sql
# Comprimimos los datos para reducir el tamaño de los datos a trasferir
gzip dump.sql
# Volvemos a nuestro ordenador
exit
# Copiamos el fichero a nuestro ordenador
scp user@server.com:dump.sql.gz .

He hecho una prueba con una base de datos pequeña. Si únicamente contabilizamos el tiempo en realizar cada uno de estos comandos y los sumamos (es decir, no tenemos en cuenta ni el ssh inicial ni los tiempos entre comandos, incluído si nos vamos a tomar un café mientras hace el volcado o lo comprime), salen los siguientes tiempos:

  • mysqldump: 2.2 segundos
  • gzip: 0.5 segundos
  • scp: 12.2 segundos
  • total método 1: 14.9 segundos

Veamos ahora otra forma. ¿Y cómo es? Pues bien sencilla… ¿y si te digo que puedes agrupar todos los comandos en únicamente uno?

¿Cómo? Pues aprovechando que se pueden ejecutar comandos de forma remota con el comando ssh y que lo que devuelva ese comando, se retorna mediante la consola estándar (stdin). Además, teniendo en cuenta que también podemos llamar a gzip en línea mediante una tubería (denominada en inglés pipe, representada por la barra vertical: |). Si unimos todo esto, nuestro comando queda (ejecutado directamente desde nuestra máquina):

ssh user@server.com "mysqldump -u mysqluser -p mysqldb | gzip" > dump.sql.gz

Si medimos el tiempo que le cuesta a este comando obtenemos para el método 2: 12.0 segundos

La diferencia puede parecer muy pequeña vista así, pero estamos hablando que es casi un 20% más rápido. Si este proceso (con el primer método) hubiese durado 4 horas (sí, os aseguro que se puede dar el caso), en algo más de 3 horas lo habríais terminado. Estos datos son muy variables, hay que tener en cuenta muchas cosas, pero que hagáis las pruebas que hagáis, en igualdad de condiciones, este nuevo método es mucho más rápido.

Y os aseguro que si hacéis la prueba con un proceso largo, en el que tendríais que esperar que terminase cada paso para iniciar el siguiente comando, ganaréis mucho tiempo sobre todo entre comando y comando.

La próxima vez que os toque algo como esto, usad este método y tomaros el café (o la comida) que os podréis tomar gracias a no tener que esperar, a mi salud.

Pensad un poco, esto es sólo un ejemplo, ¡hay muchas más opciones!