Archive for the ‘Optimization’ Category

Using php5-memcached to store sessions on distributed servers

This article is an extension of the previous article about storing sessions in Memcached with PHP.

Using Memcached for sessions storage is generally a matter of speed (storing them in memory is faster than on disk) and of scalability (using a Memcached server allows you to have several web servers serving the same PHP application in a seamless way).

In the previous article, we mentioned (3 years ago) that the php5-memcached extension did not seem to manage the storage of sessions quite well, or at least that the configuration of such setup was not well documented. This time, we’ve been able to do it with php5-memcached. This time also, we’re talking about distributing Memcached on several servers. Typically, in a cloud environment with several web servers and no dedicated memcached server, or a need for some kind of fail-over solution for the memcached server. We’re setting this up on 3 Ubuntu 14.04 servers in 64bit that act as load-balanced web servers behind a load balancer managed by Nginx. If you use another distribution or operating system, you might need to adapt the commands we’re showing here.

Installing Memcached + PHP

So the few commands you need to launch first are to install the required software, on the 3 web servers (you can either do that on one of them then replicate the image if you are using Cloud instances, or you can install simultaneously on your 3 web servers using ClusterSSH, for example, with the cssh server1 server2 server3 command) :

sudo apt-get install memcached php5-memcached
sudo service apache2 restart

The second command is to make sure Apache understands the php5-memcached extension is there.

In order to enable the connection to Memcached from the different load-balanced servers, we need to change the Memcached configuration to listen on the external IP address. Check the IP address with /sbin/ifconfig. The Memcached configuration file is located in /etc/memcached.conf. Locate the “-l” option and change “” for your external IP, then save and close the file. Note that this might introduce a security flaw, where you are possibly opening the connection to your Memcached server to the outside world. You can prevent that using a firewall (iptables is a big classic, available on Ubuntu)

Next, restart the Memcached daemon:

sudo service memcached restart

Now you have a Memcached server running on each of your web servers, accessible from the other web servers. To test this, connect to any of your web servers and try a telnet connection on the default Memcached port: 11211, like so:

user@server1$ telnet ip-server2 11211

To get out of there, just type “quit” and Enter.

OK, so now we have 3 Memcached servers, we only need to wrap up configuring PHP to use these Memcached servers to store sessions.

Configuring PHP to use Memcached as session storage

This is done by editing your Apache VirtualHost files (on each web server) and adding (before the closing </VirtualHost> tag) the following PHP settings:

 php_admin_value session.save_handler memcached
 php_admin_value session.save_path "ip-server1:11211,ip-server2:11211,ip-server3:11211"

Now reload your web server:

 sudo service apache2 reload

You should now be able to connect to your web application using the distributed Memcached server as a session storage (you usually don’t need to change anything in your application itself, but some might exceptionally define their own session storage policy).

The dangers of using a distributed Memcached server

Apart from the possible open access to your Memcached server previously mentioned, which is particularly security-related, you have to take another danger, mostly high-availability related, into account.

When using a distributed Memcached server configuration, it is important to understand that it works as sharded spaces configuration. That is, it doesn’t store the same sessions over on the various available Memcached server. It only stores each single session in one single server. The decision of where it will store the session is out of the context of this article, but it means that, if you have 300 users with active sessions on your system at any one time, and one of your web servers goes down, you still have 2 web servers and 2 Memcached servers, but ultimately around 100 users will loose their session (that was stored on the web server that went down).

Worst: the PHP configuration will not understand this, and still try to send sessions to the server that was considered to hold these 100 sessions, making it impossible for the users to login again until the corresponding Memcached server is back up (unless you change the configuration in your PHP configuration).

This is why you have to consider 2 things, and why this article is just one step in the right direction:

  • you should configure the Memcached servers from inside your application for the sessions management (as such, you should have a save_handler defined inside it and check for the availability of each server *before* you store the session in it)
  • if your sessions are critical, you should always have some kind of data persistence mechanism, whereby (for example), you store the session in the database once every ten times it is modified

We hope this was of some use to you in understanding how to use Memcached for sessions storage in PHP. Please don’t hesitate to leave questions or comments below.

Intercontinental fiber channel cables

Ever wondered where internet (and general telecommunications) cables were laid out in the ocean?
This map, available on Level3 website, could help you out.

Map of fiber cables worldwide

This could help you out understanding, for example, how much delay you can expect between Peru and Brazil (see the missing cable, there?) :-p

El mejor valor para max_connections en MySQL

January 13, 2014 Leave a comment

Según el artículo, no hay un “mejor valor”, y mucho depende de la aplicación detrás, pero dicen que en máquinas con ~16GB de RAM, puede estar alrededor de 1000 sin mucho problema.

Para más, ya habría que empezar a pensar en un thread_pool.

Ver el artículo original para mayores detalles, y el artículo anterior en este blog para saber como cambiar este valor en vivo (a parte de cambiarlo en la configuración para que quede más allá de un reboot).

On PHP and cache slams and solutions

December 16, 2013 Leave a comment

While reading about Doctrine’s cache mechanism (which applies to other stuff than database queries, by the way), my eye was caught by a little message at the end (last section) about cache slams.

I have used cache mechanisms extensively over the last few years, but (maybe luckily) never happened to witness a “cache slam”.
There’s a link to a blog (by an unnamed author) that explains that.

To make it short, you can have race conditions in APC (and probably in other caching mechanisms in PHP) when you assign a specific time for expiry of cache data, and a user gets to that expiry time at the same time (or very very very closely) as other users. This provokes a chain reaction (a little bit like an atomic bomb, but not with the same effect – unless some crazy military scientist binds a high-traffic website to the initiation process of an atomic bomb) which makes your website eat all memory and freeze (or something like that).

In reply to me mentioning it on Twitter, @PierreJoye (from the PHP development team) kindly pointed me to APCu, which is a user-land caching mechanism (or so to speak an APC without the opcode, and simplified).

Apparently, this one doesn’t have the cache slam issue (although I haven’t checked it myself, I have faith in Pierre here) and it’s already in PECL (still in beta though), so if you want to try it out on Debian/Ubuntu, you will probably be able to sort it out with a simple:

sudo apt-get install php5-dev php5-pear make
sudo pecl install APCu

(and then configure your PHP to include it).

Don’t forget that it is a PECL library, meaning it’s most likely you’ll have to recompile your PHP to enable it, but PECL should handle that just fine (in our case it’s a bit more complicated if we want to avoid asking our users – of Chamilo, that is – for more dependencies).

Anyway, just so you know, there are people like that who like to make the world a better place for us, PHP developers, so that we can make the world a better place developing professional-grade, super-efficient free software in PHP! Don’t miss out on contributing to that!

PHP’s @ hurts performance

September 25, 2013 2 comments

Did you know…?

As a “take away” information taken from this post (by famous PHP core developer @nikita_ppv), it appears like the @ sign in PHP (used to “hide” errors, as the “error-suppression operator” it is) also disables the “compiled variables” optimization (OpCode caching).

Experimentando con Digital Ocean… primeras impresiones

September 23, 2013 4 comments

El equipo de BeezNest estuvo experimentando con el servicio de alquiler de máquinas virtuales de Digital Ocean estos 2 últimos meses, y en el espíritu del compartir, aquí les damos nuestras primeras impresiones.


Ante todo, hablemos de costos. Se pueden obtener máquinas virtuales con disco SSD a partir de $5/mes. Esto es todo incluido, pagado desde PayPal o por tarjeta de crédito. Es más, existen algunos vouchers que permiten aprovechar de promociones de $10 “para probar”.

Con una máquina virtual (llamada “droplet” en este caso) de $5/mes, que es de 512MB de memoria y 20GB de disco duro, no se hace mucho, pero es suficiente, por ejemplo, para montar un pequeño sitio web Drupal o unas instalaciones de Chamilo LMS, de momento que el uso no sea masivo.

Lo que consideramos muy bueno es la accesibilidad para unas máquinas de entrada. Como que el costo no deja realmente lugar para pensar. Además, si solo lo usa dos semanas, pagará la mitad. Se descuenta por hora. Pero ojo, hay que apagarla, sacar una imagen de backup (snapshot) y borrar la máquina para que deje de descontar…


En términos de accesibilidad (y no estamos hablando de discapacidades, sino de facilidad de acceso al servicio), el servicio es impresionante de claridad: los costos aumentan en una proporción casi igual a los recursos: $10/mes para 30GB de disco SSD, 1 core y 1GB de RAM, $20/mes para 40GB, 2 cores y 2GB de RAM, etc. La lista de costos indica hasta máquinas de 24 cores y 96GB de RAM (pero claro, ahí sale costoso, a $960/mes, pero se puede tomar por horas a $1.429/h).

La lista de costos está a un clic de la página principal del sitio, y permite ver el costo por mes y por hora.

La creación de una cuenta de usuario es sencilla (usuario y contraseña), y a partir del momento en que paga en PayPal (link “Billing” y después “Manage payments” en la interface del usuario registrado) o por tarjeta de crédito, se activa el botón de creación de imágenes. En 2 clics y 2 minutos de espera, ya tiene una máquina virtual corriendo.

Disponibilidad de imágenes predefinidas

La lista de imágenes disponibles es bastante extendida, con 9 versiones de Ubuntu (incluyendo una de Ubuntu 10.04 64bit que permite instalar facílmente un servidor de videoconferencia BigBlueButton), 4 versiones de CentOS, Debian, ArchLinux y Fedora, además de unas imágenes de aplicativos pre-instalados como WordPress o Redmine. En fin, hay para todos los gustos o casi, por lo menos en Linux.


La información comunicada por e-mail es corta y al punto para quien conoce un poco de gestión de servidores y conexiones por SSH. Después de crear una nueva imagen, el tiempo de espera para recibir el correo con los accesos es mínimo: alrededor de 1 minutos (hasta 5 minutos en un caso).


Si bien existe poca (si alguna) información en Español, la calidad y rapidez del soporte es buena. En 5 comunicaciones con ellos, el tiempo promedio de atención fue de 30 minutos (tuvimos mala suerte en un caso, al parecer, ya que la mayoría de la gente en el foro indica que dan respuesta en menos de 5 minutos, y a nosotros una vez demoró 4 horas). Existen unos temas todavía un poco obscuros, para el equipo de soporte también, como la gestión del volumen de transferencia hasta la fecha, que si bien indica un límite en las características de las imagenes, parece que todavía no está controlado.

Tampoco queda claro si, una vez que se contabilice, se podrá hacer “pooling” (es decir compartir el volumen de transferencia entre varias máquinas) y si el límite es proporcional a la cantidad de horas usadas, o si, de frente, nos dan la cantidad correspondiente a un mes de uso.


El redimensionamiento de las máquinas no se hace en caliente. Es necesario tomar un snapshot, apagar la máquina virtual y volver a crear una nueva máquina de mayor dimensión. Existe una funcionalidad de redimensionamiento (“Resize”) pero no funciona para aumentar la capacidad en disco, por lo que se recomienda proceder por el apagado y el remplazo del droplet.

El remplazo del droplet mismo mantiene la dirección IP, aunque Digital Ocean no ofrece garantía sobre este punto (pero dicen que “en general” su sistema reserva esta IP por “un rato” para usted después de que el droplet haya sido eliminado. Muy importante entonces, para no tener que redefinir nombres de dominios y cosas así, solo apagar momentáneamente sus droplets y proceder uno por uno (no apagar 4 a la vez y después volver a crear imágenes en cualquier orden).

En nuestro caso, no tuvimos problemas de redimensionamiento, pero queda claro que si usan 25GB de disco y redimensionan a un droplet de 20GB de disco, van a enfrentarse con problemas…


El mayor problema que encontramos hasta la fecha fue la imposibilidad de redimensionar o distribuir a su gusto las particiones en el disco de las imágenes proveidas. Esto impide una serie de cosas, como el compartido de particiones entre varias máquinas (NFS, OCFS2, etc) y el uso de espacios de swap (en caso pase encima de la memoria autorizada).


Digital Ocean ofrce una API REST muy simple y bonita que permite crear nuevas imágenes a partir de un snapshot y un número de tipo de droplet, apagarlas, redimensionarlas, reiniciarlas, etc.

Como es REST, se puede probar hasta a partir de la ruta de un navegador.

También econtramos una librería PHP (de terceros) ya preparada para el uso de esta API, lo que reduce todavía los obstáculos para armar un sistema de gestión bien concreto con redimensionamiento adaptativo.

Esto siendo dicho, el panel de control todavía no ofrece opciones avanzadas para el redimensionamiento.

Calidad de las máquinas y servicios

Aunque no hayamos hecho benchmarking en los discos, como es de esperar para un disco SSD (que no presenta los mismos defectos que discos magneticos para el contexto de máquinas virtuales), el disco parece muy rápido.

También parecen tener mirrors de Debian y Ubuntu en su red, ya que la descarga de nuevos paquetes y las actualizaciones de estos dos sistemas es fulgurante (llegamos a 10MB/s para la instalación de BigBlueButton, que requiere más de 800MB de descarga).

Cuando se usan al extremo y se alcanza el límite de memoria, los servicios corriendo en la máquina se apagan, como es de esperar bajo Linux, por lo que es importante medir bien las primeras utilizaciones y dimensionar correctamente la máquina virtual.

Últimamente, y bajo presión popular al parecer, se agregó private networking dentro del segundo data center de Nueva York (y solo este). No hemos podido probarlo, pero entendemos que este permite generar menor latencia entre máquinas, en particular para el caso de replicación de bases de datos MySQL, por ejemplo.

Puede definir registros PTR a través de la interface.


En una (sola) oportunidad, quisimos acceder al panel de control un domingo en la mañana para redimensionar una máquina pero no se pudo, lo que nos generó bastante preocupación, pues no habíamos visto ninguna información correspondiente acerca de esta indisponibilidad. Todo el sitio de Digital Ocean siendo inaccesible, no pudimos verificar que estaba pasando, y solo teníamos una máquina virtual levantada, que no respondía. Por lo tanto, nos fue imposible determinar si esto había sido un caso excepcional o algo común. De lo observado desde este entonces (hace más de un mes ahora), no fue posible volver a observar este problema.


En esta etapa, todavía sigue siendo difícil entender exactamente el compromiso de Digital Ocean en términos de persistencia de los datos y de disponibilidad de la infraestructura, por lo que preferimos no usarlo para sistemas críticos. La dificultad de compartir particiones rinde imposible o por lo menos impráctico la elaboración de clusters totalmente redundantes. Esperamos encontrar una solución acerca de esto pronto.

Por lo general, estamos impresionados por la calidad del servicio ofrecido por Digital Ocean, en comparación con su costo, y recomendamos a todos los desarrolladores web trantando de comprobar la validez de nuevos sistemas de usar sus máquinas virtuales. Son muy prácticas y eficientes. Solo no se olviden de apagarlas y destruir el droplet después de haber tomado un snapshot para no seguir pagando mientras no las usan. Los montos pueden subir rápidamente, pero creemos que definitivamente representa un ahorro considerable en consideración del tiempo que se podría dedicar normalmente a la configuración de todas estas máquinas virtuales en un ambiente propio.

Nginx + CDN + GoogleBot or how to avoid many useless Googlebot hits

If you’re like me and you’ve developed a CDN distribution for your website’s content (while waiting for SPDY to be widely adopted and available in mainstream distributions), you might have noted that the Googlebot is frequently scanning your CDNs, and this might have made your website a bit overloaded.

After all, the goal of the CDNs are (several but in my case only) to elegantly distribute contents across subdomains so your browser will load the page resources faster (otherwise it gets blocked by the HTTP limit or any higher limit set by your browser of simultaneous content download).

Hell, in my case, this is the number of page scans per day originating from the Googlebot on only one of my CDN-enabled sites (I think there are like 5 different subdomains). And these are only the IPs that requested the site the most:


As you can see, it sums up to about 13,000 requests in just 24h. On the main site (the www. prefixed one), I still get 10,000 requests per day from the Googlebot.

So if you want to avoid that, fixing it in Apache is out of the scope here, but you could easily do it with a RewriteCond line.
Doing it in Nginx should be relatively easy if you have different virtual host files for your main site and the CDN (which is recommended as they generally have different caching behaviour, etc). Find the top “location” block in your Nginx configuration. In my case, it looks like this:

        location / {
                index  index.php index.html index.htm;
                try_files $uri $uri/ @rewrite;

Change it to the following (chang by the name of your site):

        location / {
                index  index.php index.html index.htm;
                # Avoid Googlebot in here
                if ($http_user_agent ~ Googlebot) {
                    return 301$request_uri;
                try_files $uri $uri/ @rewrite;

Reload your Nginx configuration and… done.

To test it, use the User Agent Switcher extension for Firefox. Beware that your browser generally uses DNS caching, so if you have already loaded the page, you will probably have to restart your browser (or maybe use a new browser instance with firefox –no-remote and install the extension in that one *before* loading the page).

Once the extension is installed, choose one of the Googlebot user agents in Tools -> Default User Agent -> Spider – Search, then load your cdn page: you should get redirected to the www page straight away.

%d bloggers like this: