Cómo medir la velocidad de ejecución de un programa en Linux

Medir cuánto tarda en ejecutarse un programa en Linux puede parecer una tarea sencilla, pero hacerlo bien marca la diferencia entre un sistema que vuela y otro que va arrastrándose. Cuando empiezas a automatizar tareas con scripts, a desarrollar aplicaciones o a administrar servidores, el tiempo deja de ser una cifra abstracta y se convierte en un dato clave para tomar decisiones técnicas.

En el día a día, no solo nos interesa saber si algo “es rápido” o “es lento”. Necesitamos métricas concretas: segundos, milisegundos y, si el valor es muy grande, expresarlo en formato HH:MM:SS para entenderlo mejor. A partir de ahí podemos comparar soluciones, detectar cuellos de botella, vigilar la evolución del rendimiento y, en general, tener controlado cómo se comportan nuestros programas y servicios.

Por qué te interesa medir el tiempo de ejecución en Linux

Cuando trabajas con Linux, ya sea en un portátil personal o en un servidor en producción, conocer el tiempo de ejecución de tus scripts y programas es una herramienta brutal para mejorar su rendimiento. No es solo curiosidad: se traduce en menos recursos consumidos, respuestas más rápidas y una experiencia más fluida para los usuarios.

Una de las primeras razones para medir tiempos es la optimización del rendimiento: si no sabes cuánto tarda algo, es imposible saber si lo has mejorado o empeorado. Al registrar la duración de tus scripts de copia de seguridad, de procesamiento de datos o de despliegue, puedes identificar qué partes son más lentas y centrar ahí tus esfuerzos de optimización.

También es clave para la comparación de soluciones: en programación casi siempre hay varias maneras de resolver el mismo problema. Puedes implementar un algoritmo en Bash, Python o C, o probar distintas consultas a una base de datos; si mides los tiempos de cada alternativa, podrás elegir la que realmente sea más eficiente en tu entorno concreto.

Otro punto interesante es el monitoreo del rendimiento a lo largo del tiempo: un script que hoy va rápido puede degradarse tras varios cambios. Si mides su duración regularmente, podrás detectar cuándo se empieza a alargar más de la cuenta y relacionarlo con modificaciones en el código, cambios en librerías o en la carga del sistema.

Medir el tiempo de ejecución también ayuda a establecer expectativas realistas: tanto para ti como para tu equipo o tus usuarios. Si sabes que un proceso de importación tarda alrededor de 20 minutos, no prometerás que estará listo “en un segundo”. Además, esta información es oro para planificar cuándo lanzar tareas pesadas y para dimensionar correctamente los recursos del sistema.

Por último, la medición te permite identificar problemas de escalabilidad: un script que va bien con pocos datos puede volverse dramáticamente lento cuando crece la carga. Midiendo su duración con distintos tamaños de entrada o en diferentes máquinas, es más sencillo ver si necesita paralelización, caché, mejor I/O o incluso un rediseño completo.

Medir el tiempo de ejecución con el comando time

En Linux, la forma más directa de medir cuánto tarda un programa o script en ejecutarse es el comando time, una herramienta sencilla pero potentísima para obtener métricas de ejecución. Lo mejor es que no necesitas modificar tu programa: simplemente lo invocas precedido de esta orden.

El uso más básico consiste en anteponer la palabra time al comando que quieras medir. Por ejemplo, si quieres saber cuánto tarda en listarse un directorio muy cargado, bastaría con algo tan simple como escribir en la terminal el comando con time delante y esperar la salida con las estadísticas.

Cuando finaliza la ejecución, time muestra tres tiempos principales que conviene entender bien. El primero es el “real”, que representa el tiempo total transcurrido desde que se lanzó el comando hasta que terminó, tal y como lo percibes tú como usuario.

Además del tiempo real, la salida incluye los valores “user” y “sys”, que ofrecen información detallada sobre cómo se ha utilizado la CPU durante la ejecución del programa. “user” indica el tiempo que el procesador ha estado corriendo código de tu programa en modo usuario, y “sys” refleja el tiempo empleado por el kernel realizando llamadas al sistema en nombre de ese proceso.

Esta separación es muy útil porque permite distinguir si un programa está gastando tiempo en puro cálculo o en operaciones de sistema como disco y red. Por ejemplo, un proceso con mucho “sys” puede estar limitado por I/O o por un uso intensivo de llamadas al sistema, mientras que uno con mucho “user” suele ser más CPU-dependiente.

Si quieres conservar el resultado de las mediciones, puedes redirigir la salida estándar y la de error para guardar tanto los datos del comando como las estadísticas de time. De ese modo podrás analizar después cómo cambian los tiempos entre diferentes versiones de tu script o en distintos servidores.

Medir tiempo de scripts Bash con time y otras técnicas

Cuando lo que te interesa es un script completo en Bash, el enfoque no cambia mucho: puedes lanzar tu script anteponiendo el comando time y obtendrás las métricas globales de su ejecución. Esto es perfecto para tener una visión general de cuánto tarda en completarse todo el flujo.

Además del uso externo de time, también puedes medir tramos concretos dentro del propio script utilizando variables de fecha y operaciones aritméticas. Por ejemplo, puedes capturar la hora de inicio y la de fin en segundos desde el epoch y restarlas para saber cuánto ha durado un bloque de código específico.

En muchos casos, el resultado de la resta será un número grande de segundos, y leer “7432” no es precisamente intuitivo, así que es muy práctico convertir esos segundos a un formato más humano tipo HH:MM:SS. Esto facilita mucho la interpretación, sobre todo en logs que se revisan de vez en cuando.

Para automatizar esa conversión, se puede apoyar la lógica del script en herramientas del sistema que formatean fechas y tiempos, o implementar una pequeña función que divida los segundos en horas, minutos y segundos. Este tipo de detalles marca la diferencia a la hora de entender registros de ejecución largos.

Si quieres algo todavía más cómodo, puedes crear un pequeño wrapper o script auxiliar que ejecute otro script, mida el tiempo y muestre una salida “bonita” con el tiempo total en varios formatos. Así reutilizas la herramienta en cualquier trabajo de automatización que hagas en tu sistema Linux.

Herramientas para medir actividad de disco y su impacto en el rendimiento

La velocidad de un programa no depende solo de la CPU: el rendimiento del disco influye muchísimo en el tiempo de ejecución de procesos intensivos en lectura y escritura. Linux dispone de varias herramientas de consola para vigilar qué está pasando con tus dispositivos de almacenamiento.

Una utilidad muy versátil es dstat, que permite obtener estadísticas en tiempo real de la actividad de disco, entre otras muchas métricas del sistema. Si solo quieres centrarte en las operaciones de entrada y salida a disco, puedes usar el parámetro adecuado para filtrar esa información y ver cómo cambian los valores cada segundo.

En la salida de dstat observarás columnas que muestran lecturas y escrituras, lo que te ayuda a ver si hay picos de I/O que puedan estar frenando tus programas. Al ser una herramienta interactiva, bastará con interrumpirla con la combinación de teclas apropiada cuando tengas datos suficientes para tu análisis.

Otra herramienta clásica es iostat, pensada para monitorizar la carga de los dispositivos de entrada y salida y comprobar durante cuánto tiempo están ocupados. Esto es ideal para saber si uno de tus discos está constantemente al 100% de uso, lo que se traducirá en tiempos de respuesta más altos para cualquier programa que acceda a él.

En sistemas con muchos dispositivos, como servidores con numerosos “loop devices”, puede ser interesante filtrar para que iostat solo muestre los discos físicos reales. Esto se consigue con los parámetros adecuados, reduciendo el ruido en la salida y centrando tu atención en lo que realmente importa.

En distribuciones como Ubuntu, iostat forma parte del paquete sysstat, por lo que tendrás que instalarlo antes de empezar a usarlo. Una vez disponible, puedes pedirle que genere informes cada cierto intervalo, lo cual es muy útil para correlacionar los tiempos de tus programas con el comportamiento de los discos mientras se ejecutan.

Si quieres ver qué procesos son los que están usando más intensivamente el disco en un momento dado, puedes recurrir a ver qué procesos están usando más disco, una especie de “top” centrado en operaciones de entrada y salida

Además, iotop te permite ajustar el intervalo de refresco con opciones como -d, para decidir cada cuántos segundos se actualiza la información. Ten en cuenta que para usarlo normalmente necesitarás permisos de superusuario o pertenecer a determinados grupos de administración.

Otro comando menos conocido pero tremendamente útil es ioping, que se centra no tanto en el volumen de I/O sino en la latencia del disco. Es decir, mide cuánto tarda el almacenamiento en responder a solicitudes, algo básico para detectar problemas de hardware o de configuración que incrementen la demora en accesos puntuales.

Para tener una visión global del sistema puedes apoyarte en atop, una herramienta avanzada que amplía lo que ofrece el clásico top. Entre otros muchos datos, atop muestra información relativa al rendimiento de los discos, permitiéndote ver si el cuello de botella de tus programas está en el almacenamiento, en la CPU, en la memoria o en la red.

Si te interesa centrarte únicamente en la parte de discos, puedes combinar atop con tuberías y filtros para dejar solo la información relacionada con el subsistema de I/O. De este modo, tendrás una vista específica del comportamiento del almacenamiento sin distraerte con el resto de métricas.

Medir tiempos de respuesta web desde la línea de comandos

Cuando lo que quieres medir es la “velocidad” de un programa que actúa como servicio web, la película cambia un poco: aquí el dato clave suele ser el tiempo de respuesta del sitio o API. Linux también te ofrece herramientas para esto, y una de las más potentes y flexibles es curl.

El comando curl es un auténtico todoterreno para transferir datos utilizando protocolos como HTTP, HTTPS, FTP o FILE. Normalmente se usa para descargar ficheros o inspeccionar cabeceras HTTP, pero esconde una funcionalidad muy interesante para medir diversos tiempos parciales de una petición.

Con la opción adecuada, curl permite imprimir tras la operación una serie de variables relacionadas con los tiempos de resolución de nombres, conexión y transferencia. Esto significa que puedes lanzar una petición a una URL y obtener, en segundos, cuánto ha tardado cada fase del proceso.

Si, por ejemplo, quieres comprobar el comportamiento de un sitio HTTP, puedes invocar curl en modo silencioso, decirle qué datos de tiempo imprimir y desechar el contenido de la respuesta redirigiéndolo a /dev/null. Así te quedas únicamente con las métricas de rendimiento, que es lo que interesa en este contexto.

Entre las variables que puedes mostrar está time_namelookup, que indica el tiempo que se ha tardado desde el inicio de la operación hasta completar la resolución DNS del nombre. Si este valor es alto, puede que el cuello de botella esté en la resolución de nombres, no en el servidor web en sí.

Otra métrica relevante es time_connect, que mide cuánto tarda en establecerse la conexión TCP con el servidor o con el proxy. Un aumento en este valor puede apuntar a problemas de red, de saturación en el servidor o incluso a firewalls que introducen retardo.

La variable time_pretransfer refleja el tiempo desde el inicio hasta el momento justo en que la transferencia de datos está a punto de comenzar. Incluye, por tanto, la resolución de nombres, la conexión y la negociación previa a la transmisión del contenido.

También es clave fijarse en time_starttransfer, que indica el tiempo desde el inicio de la operación hasta que el primer byte de la respuesta está listo para ser enviado. Esta métrica suele asociarse con el tiempo que tarda el servidor en procesar la petición y generar una respuesta inicial.

Por último, tienes time_total, que marca el tiempo total que ha durado toda la operación completa, desde el primer paso hasta que ha terminado la transferencia. Este suele ser el dato que se usa como referencia general de “tiempo de carga” o “tiempo de respuesta” de un sitio web.

Si el formato que quieres imprimir con curl es muy largo o complejo, puedes guardarlo en un archivo de texto y decirle a curl que lo lea desde ahí con la opción adecuada. Esto hace mucho más cómoda la reutilización del mismo patrón de salida para distintas pruebas y diferentes URLs.

En ese archivo puedes agrupar todas las variables de tiempo que te interesen, con etiquetas legibles, de forma que cada ejecución de curl te devuelva un pequeño informe de tiempos para la URL analizada. Así podrás comparar rápidamente distintos servidores, rutas o configuraciones de tu aplicación.

Medir tiempos en sitios HTTPS y aspectos a considerar

En el caso de sitios web servidos por HTTPS, hay algunos pasos extra en el proceso de comunicación que también es interesante medir. Curl incorpora variables adicionales para tener en cuenta el tiempo dedicado a la negociación SSL/TLS y a posibles redirecciones.

Una de estas variables es time_appconnect, que mide el tiempo invertido desde el inicio de la operación hasta que se completa la conexión o el intercambio SSL con el servidor remoto. Si tienes un valor alto aquí, puede que el problema esté en la configuración TLS, en certificados o en la propia capa de cifrado.

Otra métrica útil es time_redirect, que agrupa el tiempo empleado en todos los pasos de redirección previos a la transacción final. Incluye búsquedas de nombre, conexiones y transferencias intermedias, de modo que ayuda a saber cuánto se está perdiendo en saltos 3XX antes de llegar al contenido definitivo.

Al igual que en HTTP, estas variables pueden incluirse en un archivo de formato y reutilizarse en las pruebas que hagas contra diferentes sitios HTTPS. De este modo, tendrás siempre un informe homogéneo que facilita la comparación de resultados entre servidores, dominios o entornos de prueba.

Conviene tener en cuenta que, por la propia naturaleza del cifrado, suele ser habitual que un sitio HTTPS tarde algo más en responder que el mismo sitio sirviendo HTTP puro. Si la diferencia es exagerada, entonces sí puede tener sentido revisar parámetros de TLS, tamaños de claves o configuraciones de servidor.

Un detalle importante es que los valores devueltos por curl pueden variar notablemente entre una ejecución y otra, incluso en condiciones aparentemente similares. Factores como la carga puntual del servidor, la congestión de red o la respuesta de DNS influyen en los tiempos de forma directa.

Por eso tiene sentido repetir las pruebas varias veces, en distintos momentos del día, y obtener promedios o rangos de valores. Tomar decisiones de optimización basándose en una única medición puntual puede llevar a conclusiones engañosas.

Si quieres profundizar aún más en las posibilidades de curl, siempre puedes consultar la página del manual mediante el comando correspondiente para ver todas las opciones disponibles. Ahí encontrarás muchas más variables de tiempo y trucos avanzados para pruebas de rendimiento web.

Comandos de red útiles para entender retrasos y pérdidas

La velocidad de un programa que se comunica por la red no solo depende del propio código: la calidad de la conexión y el estado de la red influyen de lleno en sus tiempos de ejecución. Linux ofrece varios comandos pensados para revisar esta parte.

Para empezar, tienes ss, una herramienta moderna para listar conexiones de red activas con bastante detalle. Ejecutándola con los parámetros adecuados puedes ver qué conexiones TCP están abiertas, qué procesos las usan y en qué estado se encuentran.

Si lo que te interesa es saber qué servicios están escuchando en puertos concretos, a la espera de conexiones entrantes, también puedes usar ss con otras combinaciones de opciones. De este modo, identificarás qué demonios podrían estar recibiendo tráfico y afectando al rendimiento general del servidor.

Para comprobar la pérdida de paquetes y la latencia básica hacia otro servidor, el clásico ping sigue siendo una herramienta imprescindible. Limitando el número de paquetes enviados con la opción adecuada, puedes obtener rápidamente una media de tiempo de ida y vuelta y un porcentaje de pérdida.

Si sospechas de problemas de enrutamiento, otra utilidad es traceroute, que muestra por qué saltos de red están pasando tus paquetes hasta llegar al destino. Verás una lista de routers intermedios y los tiempos de respuesta de cada uno, lo que ayuda a localizar dónde se introduce el retraso.

En distribuciones como CentOS o Ubuntu, puede que necesites instalar traceroute mediante el gestor de paquetes correspondiente antes de poder usarlo. Una vez instalado, bastará con indicar la dirección IP o el nombre de dominio del servidor de destino para ver el camino que siguen los paquetes.

Combinando estas herramientas de red con las mediciones de tiempo de programa y las estadísticas de disco, puedes construir una imagen bastante completa de dónde se está yendo el tiempo en tus procesos. Esto resulta fundamental cuando tienes aplicaciones distribuidas o servicios que dependen de recursos externos.

La realidad es que la línea de comandos en Linux funciona como una auténtica navaja suiza para diagnosticar y optimizar el rendimiento de tu sistema. Desde tiempos de ejecución de scripts hasta latencias de red o saturación de discos, todo puede medirse con las herramientas adecuadas.

Si haces un uso sistemático de estos comandos, documentas tus pruebas y vas registrando los resultados, te será mucho más sencillo detectar regresiones de rendimiento, encontrar cuellos de botella y tomar decisiones informadas sobre escalabilidad. Al final, medir bien es el primer paso para poder mejorar de verdad.