miércoles, 28 de agosto de 2019

Algoritmo de una peluquería

Alguna de las veces que voy por Córdoba, aprovecho para ir a la peluquería y cortarme el pelo. Siempre me sorprende la forma en la que se gestionan los turnos y hoy os quisiera contar algunas de las cosas que pienso mientras estoy en la peluquería.


Suelo ir los sábados, sé que abren a las 9 de la mañana y está cerca de casa, por lo que salgo siempre sobre las 8:50 y siempre llego sobre las 8:59 o incluso las 9:00. Pues en la gran mayoría de las veces, me encuentro con que hay 3 personas ya sentadas y con un peinado ya bastante adelantado y entre 2-3 personas esperando. Tiro de una doble comprobación mirando el papel que hay en la puerta con los horarios, pero sí, está bien, he llegado justo cuando abren en teoría.

Yo empiezo a pensar cómo se puede dar esa situación. Si fuesen procesos, a lo mejor lo que están haciendo es reservar un espacio en memoria o incluso si son procesos habituales (clientes habituales) puede que se guarden en caché para optimizar el rendimiento.

A veces lo pienso como si fuesen redes. A lo mejor es que al ser nodos frecuentes, cuando vienen un número N de veces, la peluquería se queda con sus direcciones MAC y realizan un filtrado de tal forma que reservan direcciones IP a esas MACs, de tal forma que ellos serían, por ejemplo:

192.168.1.2

Y yo

192.168.1.100

Pero eso es nada más entrar en la peluquería. Todo eso pasa por mi cabeza durante unos segundos, después recuerdo que tengo que seguir el protocolo habitual.

Tengo que coger un número. Ese será de ahora en adelante mi ID de cliente. Me siento. Empieza a contar mi KeepAlive y mi Timeout. Yo nunca lo rebaso aunque se agote, siempre lo voy aumentando. A veces con pensamientos como estos.

El algoritmo que utilizan es, en principio, evidente. Se establece un ID a cada cliente y la fórmula ha seguir será  un bucle for de una forma similar a:

for (i=0; i<=totalClients; i++)

No obstante, tampoco es del todo así, ya que hay veces que que una persona, aunque le toque, renuncia a su turno porque dice que a ella la peina o corta el pelo X peluquero o peluquera. Esto hace que,la gente que está esperando se dividan entre los y las trabajadoras.

Esto provoca que si hay 3 trabajadores, a lo mejor los clientes se dividen en:

Trabajador 1: cliente 1
Trabajador 2: cliente 2, cliente 4, cliente 5, cliente 7
Trabajador 3: cliente 3, cliente 6

Es el trabajador o trabajadora número 2 quien tiene una saturación mayor y en la que se pueden producir los cuellos de botella. Pero digo que "puede" porque no depende tanto del número de personas, sino de cuánto tiempo va a tardar en "procesar" a cada persona persona. Es decir, que aunque sea el trabajador 2 quien tenga que atender a más peticiones, puede que las peticiones que lleven más tiempo sean las del trabajador 3, por lo que puede que los cuellos de botella se originen ahí.

La solución parece simple, emplear un algoritmo que atienda primero a las peticiones cortas y así, al tardar poco cada trabajador o trabajadora, las personas esperarían menos y no se crearían cuellos de botella.

Esto es cierto, pero puede que tengamos una petición que requiera mucho tiempo procesarla (una petición larga) y que no paren de entrar peticiones cortas, por lo que se atenderían antes y la petición larga se quedaría en un estado zombie al no atenderse nunca.

La solución parece estar en, por ejemplo, cada 2 cortas, una larga; es decir, atender  2 peticiones cortas y la siguiente una larga. Imaginemos el siguiente caso:

Hay esperando 3 personas, 2 son peticiones cortas y una es larga. Es una situación ideal porque podrían pasar las 3 personas a la vez, 2 trabajadores gestionarían las peticiones cortas y el trabajador sobrante la larga.

Aún no han terminado y entra una petición corta y, al poco, una larga. Cuando termine alguna de las cortas, pasaría la corta y cuando termine la segunda corta, pasaría la larga.

Este algoritmo parece el ideal...si no fuese porque estaríamos olvidando que los clientes pueden, de nuevo, decir que quieren que su petición la atienda X. Esto podría llevar a que la corta y la larga que acaban de entrar, quieran que la atiendan la persona que ya está atendiendo una larga. Cuello de botella.

Algo que se puede hacer es atender a 2 peticiones a la vez. Imaginemos que la petición larga primera es un tinte, pues hay un momento en el que se tiene que esperar en el secador, ahí es donde se podría gestionar la petición corta que acaba de entrar. Pero aquí ya depende de la petición.

Pero es que pueden seguir entrando peticiones, que no se nos olvide y llegar al cuello de botella tan típico que vemos en las peluquerías. Cuellos de botella que provocan que algunos clientes, agoten su Timeout y se marchen.

Este artículo no es solamente una historia, es mostrar cómo no todo es parametrizable al 100%, no todo es automatizable. Como hemos visto, siempre que avanzábamos, surgían un pequeño problema, no uno muy grande. Un pequeño problema que ya lo complicaba todo.

Este artículo es un toque de atención a quienes creen que todo es automatizable al 100% e ignoran los matices. El desastre está garantizado.

¿Hackeamos el Mundo?


No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...

Entrada destacada

El server me sabe a poco.

Soy un fanático del Rock y de Debian . (Creo que voy a inventar Rockbian, que suena bien y todo xD) Llevaba tiempo queriendo unir estos 2 c...