Tema: performance
-
Perfilado continuo en producción: perfiles de muestreo siempre activos y qué preguntas responden
El perfilado continuo toma perfiles de CPU y memoria de forma sistemática a lo largo del tiempo y los almacena como series etiquetadas, de modo que un equipo puede preguntar qué función consumió más CPU en toda la flota ayer o qué cambió entre dos versiones; los perfiladores por muestreo lo hacen lo bastante barato como para dejarlo activo permanentemente, y endpoints de runtime como /debug/pprof/ de Go o agentes eBPF suministran los perfiles.
-
Resumir el tiempo en llamadas al sistema con strace -c, su sobrecarga y perf trace como alternativa
strace -c cuenta tiempo, llamadas y errores por cada llamada al sistema en lugar de imprimir todas; el propio manual de strace advierte de que un proceso trazado se ejecuta más despacio que uno sin trazar. perf trace, descrito como una herramienta inspirada en strace y basada en perf_events en lugar de ptrace, es la alternativa más sencilla cuando esa sobrecarga importa.
-
Comparar el rendimiento de un cambio: calentamiento, repeticiones, varianza y qué reportar
Una comparación de tiempos solo es un resultado si sobrevive al ruido: fijar la carga de trabajo, descartar las ejecuciones de calentamiento, intercalar muchas repeticiones de cada variante, elegir el estadístico antes de mirar los datos, y reportar la dispersión y el entorno junto a cada número. Una diferencia menor que la dispersión entre ejecuciones no es un hallazgo.
-
Primer vistazo al rendimiento de Solaris: prstat, vmstat, mpstat, iostat y zpool iostat
prstat -a/-Z, vmstat, mpstat, iostat -xnz y zpool iostat son cinco comandos de solo lectura que cubren la mayoría de las preguntas de un primer análisis de rendimiento en Solaris 11.4, con detalle de zonas y de latencia de disco que las herramientas de nombre similar en Linux presentan de otro modo.
-
El método USE para localizar cuellos de botella de rendimiento
Para cada recurso (CPU, memoria, discos, red, bloqueos) comprobar utilización, saturación y errores; el método USE es una lista de verificación que localiza los cuellos de botella con rapidez, sin empezar por conjeturas en la capa de aplicación.
-
Compresión de respuestas: dónde aplicarla y qué excluir
Comprimir las respuestas de texto (HTML, JSON, Markdown) en el proxy o en la aplicación, omitir el contenido ya comprimido y el de streaming, mantener los ETags coherentes entre codificaciones, y establecer Vary: Accept-Encoding.
-
¿Qué proporción del contexto de un agente es salida de herramientas en ejecuciones reales, y su recorte cambia el éxito de la tarea?
Pregunta abierta: la especificación de MCP dice que los clientes deberían validar los resultados de las herramientas antes de pasarlos al modelo, pero deja la cantidad a criterio del cliente; en las ejecuciones de agentes registradas, ¿qué proporción de los tokens corresponde a salida de herramientas en lugar de a instrucciones o razonamiento, y truncar, resumir o filtrar la salida de herramientas cambia el éxito de la tarea, el costo y la latencia?
-
Imágenes responsivas con srcset, sizes y picture
srcset con descriptores de ancho junto con un atributo sizes permite que el navegador elija el archivo de imagen más pequeño que llena el espacio disponible según el viewport y la densidad de píxeles actuales; los descriptores x sirven imágenes de tamaño fijo a varias densidades; picture con elementos source gestiona la dirección de arte y el respaldo de formato. Conviene mantener siempre width y height para que el diseño no se desplace mientras carga la imagen.
-
Muestreo de contadores de rendimiento de Windows Server con Get-Counter y exportación a CSV
Get-Counter muestrea rutas de contadores con nombre a un intervalo elegido, de forma continua o con un número fijo de muestras; Export-Counter (solo en Windows PowerShell 5.1) conserva todos los campos en el formato nativo BLG, y relog convierte después una captura a CSV incluso sin el comando Export-Counter original.
-
Generar, criticar, revisar: cuándo un bucle de autoverificación compensa su coste
Un bucle en el que el modelo critica y revisa su propia salida mejora los resultados cuando la crítica dispone de una señal externa (tests, un validador, una fuente) y de una rúbrica fija; sin ella, los resultados publicados muestran que puede degradar las respuestas, y cada ronda añade al menos dos llamadas cuya entrada crece con el borrador.
-
VACUUM, autovacuum y la hinchazón de las tablas
El control de concurrencia multiversión (MVCC) de PostgreSQL deja versiones de filas muertas tras las actualizaciones y las eliminaciones; VACUUM las recupera y mantiene las estadísticas y la protección contra el desbordamiento del identificador de transacción. El autovacuum debe permanecer activado y ajustarse para las tablas con mucha actividad.
-
Carga de fuentes web: font-display, preload, subconjuntos con unicode-range y alternativas ajustadas por métricas
Mostrar texto en el primer renderizado y cargar la fuente de marca sin saltos de maquetación: crear subconjuntos de las tipografías con unicode-range para descargar solo los sistemas de escritura usados, elegir font-display según el papel (optional para el cuerpo de texto, swap para los títulos), precargar con crossorigin los archivos del primer renderizado y declarar una fuente alternativa con size-adjust y las anulaciones de ascent/descent para que las líneas se ajusten igual antes y después del intercambio.
-
Las compilaciones de módulos ES con efectos secundarios declarados reducen más los paquetes del consumidor que las compilaciones CommonJS
Hipótesis: para una biblioteca de muchas funciones independientes, un consumidor que importa unas pocas obtiene un paquete más pequeño cuando la biblioteca distribuye módulos ES con una declaración sideEffects que cuando distribuye CommonJS, porque el tree shaking depende de la estructura estática de import/export; se propone una comparación basada en fixtures.
-
Cuándo ayuda asyncio y cuándo no
asyncio ejecuta muchas tareas limitadas por E/S en un solo hilo suspendiéndose en los puntos await; no acelera el código limitado por CPU, y las llamadas bloqueantes dentro de las corrutinas paralizan todo el bucle.
-
Web Vitals: qué miden LCP, INP y CLS
Core Web Vitals son tres métricas de campo: Largest Contentful Paint (tiempo de renderizado del elemento visible más grande, objetivo 2.5 s), Interaction to Next Paint (latencia de la interacción más larga, objetivo 200 ms) y Cumulative Layout Shift (movimiento inesperado, objetivo 0.1), cada una evaluada en el percentil 75 de las cargas de página.
-
¿Cuándo sigue mereciendo la pena el enrutamiento en el cliente ahora que los navegadores ofrecen bfcache, prerenderizado y transiciones de vista entre documentos?
Pregunta abierta: los enrutadores en página se adoptaron para evitar las cargas completas de página, a costa de servir un shell, gestionar los 404, restaurar el desplazamiento y el foco, y un paquete que debe llegar primero; la caché de retroceso/avance, la API Speculation Rules y las transiciones de vista entre documentos abordan ahora las motivaciones originales en los sitios de varias páginas. ¿Para qué sitios y qué patrones de interacción sigue ganando de forma mensurable un enrutador en página?
-
Encontrar una fuga de memoria con instantáneas de tracemalloc
Iniciar el rastreo pronto con PYTHONTRACEMALLOC o tracemalloc.start(nframe), tomar una instantánea después del calentamiento y otra tras N iteraciones, filtrar el ruido de las importaciones, y leer compare_to(..., 'lineno') para encontrar las líneas cuyo tamaño crece proporcionalmente a N; cambiar a la agrupación 'traceback' para ver quién las llama.
-
Diagnóstico de rendimiento desde la Terminal de macOS: top, vm_stat, memory_pressure, fs_usage y powermetrics
macOS incluye herramientas de origen BSD y otras específicas de Apple que se solapan con lo que top/vmstat/iostat/strace hacen en Linux, pero con otros nombres, unidades y requisitos de privilegios: top -o cpu, vm_stat, memory_pressure, iostat, fs_usage, powermetrics y sample <pid>.
-
CPU y E/S por proceso con pidstat y /proc/<pid>/io: cómo encontrar la causa de la espera de E/S
pidstat informa de CPU, memoria y E/S de disco por tarea sin tener que filtrar un nombre en top; leer /proc/<pid>/io directamente permite distinguir la E/S lógica (rchar/wchar, que incluye la cache) de read_bytes/write_bytes, los bytes físicos que realmente llegan al dispositivo.
-
Elegir entre hilos, procesos y asyncio para una carga de trabajo en Python
Clasificar primero la ruta crítica: la espera de E/S se ajusta a asyncio (muchas conexiones, bibliotecas asíncronas) o a un pool de hilos (pocas llamadas bloqueantes); el trabajo de CPU en Python puro necesita procesos o una compilación sin GIL (free-threaded); el código nativo que libera el GIL puede usar hilos. Acotar cada pool, elegir explícitamente el método de arranque de los procesos y escribir la ruta de apagado.
Legible por máquina: JSON