Month: June 2015

What is code? It’s not magic, just work

Posted on by

It’s very likely that you already know about or even read the latest issue of Bloomberg, entirely dedicated to answer What is Code? — if you haven’t, you definitely should go read it.

The entire piece is informative and fun to read, and there’s probably something new for everyone reading it. My favourite highlight is:

Computing treats human language as an arbitrary set of symbols in sequences. It treats music, imagery and film that way, too.

It’s a good and healthy exercise to ponder what your computer is doing right now […]

Thinking this way will teach you two think about computers: one, there’s no magic no matter how much it looks like there is. There’s just work to make things look like magic. And two, its crazy in there.

Which reminded me something I said to a fresh group of designers on a HTML+CSS+Javascript crash course.

Arreglar errores 502 con nginx y PHP-FPM

Posted on by

Hace algún tiempo, un servidor comenzó a generar errores 502: Bad Gateway de manera aleatoria y no reproducible. O sea, en las condiciones ideales para convertirse en un quebradero de cabeza.

Este servidor funciona con nginx + PHP-FPM, pero luego de descartar las razones más usuales de problemas que se pueden encontrar en este tipo de configuraciones, los errores seguían ocurriendo. Lo peor es que el servicio no solamente se interrumpía, sino que no volvía a funcionar hasta reiniciar manualmente nginx.

Finalmente pude dar con la causa: al parecer, habían ciertos procesos de PHP que nunca terminaban adecuadamente. Si bien el valor de max_execution_time estaba correctamente configurado, en ciertas condiciones hay procesos que no terminan de ejecutarse correctamente. La solución, de parte de PHP:

; detener la ejecución que no obedecen a max_execution_timerequest_terminate_timeout = 30s

; loguear peticiones con tiempo de ejecución excesivo
slowlog = /var/log/php5-fpm/$pool.log.slow
request_slowlog_timeout = 30s

Luego, por parte de nginx también es recomendable establecer límites a la conexión que hace el servidor web con el servidor FastCGI (en este caso, PHP-FPM)

http {
    ...
    # fix para "upstream sent too big header"
    fastcgi_buffers 8 16k;
    fastcgi_buffer_size 32k;
    # timeout para conexiones entre nginx y fastcgi
    fastcgi_connect_timeout 30s;
    fastcgi_send_timeout 30s;
    fastcgi_read_timeout 30s;
    ...
}

Algunas notas:

  • Según la documentación de nginx, el valor fasctgi_connect_timeout no debiese exceder los 75 segundos
  • Para fastcgi_send_timeout y fastcgi_read_timeout, el tiempo máximo se mide entre dos operaciones de escritura/lectura simultáneas, respectivamente, y no considera el tiempo de transmisión de datos. Es decir, si tras el lapso de tiempo indicado el servidor FastCGI no recibe/envía ningún dato, se corta la conexión.

Un-breaking lighttpd’s broken mod_access

Posted on by

A client let us know that the server where her company’s site was hosted had an unusually high load.

After checking the access log for the web server, it was clear that the cause was repeated access attempts at a single URL, which was not essential to the site. So I though this should be easy, I’ll just block the request in the web server config. Unfortunately, they were using a very outdated version of lighttpd, so it wasn’t that easy.

It seems that older lighttpd builds had several bugs with mod_access, but the worst in our case was that instead of blocking the request and send a 403 Forbidden, it passed the request on to the 404 error handler, and this loaded the entire app enviroment.

So here’s what I did. The lighttpd config looked like this:

$HTTP["url"] =~ "^/foobar.php" {
    url.access-deny = ("")
    server.error-handler-404 = "/403.php"
}

… so request to foobar.php would be handled by 403.php. And then, 403.php:

<?php header('HTTP/1.0 403 Forbidden'); ?>
<h1>Forbidden</h1>

Very silly, but effective. Just because status codes matter.

Optimización AJAX 4: Caché permanente

Posted on by

En la parte final (por ahora) de esta serie sobre Optimización de respuestas AJAX vamos a revisar cómo utilizar técnicas de caché permanente, o lo que se debería denominar más correctamente caché-que-se-controla-desde-el-servidor — lo que complementa a la parte anterior sobre “caché volátil” o caché-que-se-controla-desde-el-cliente.

Continue reading “Optimización AJAX 4: Caché permanente”