| Siguiente: Trabajos relacionados Superior: Mejorando NFS Anterior: Detalles de implementación |
Al realizar estas modificaciones del kernel de Linux, aprendimos toda una serie de lecciones que hicieron el desarrollo interesante independientemente de los resultados obtenidos.
La primera cosa que nos sorprendió, fue la diferencia entre TCP y UDP. Aunque es algo conocido que UDP es más rápido que TCP, nos dimos cuenta al comenzar la medida que las diferencias eran realmente notables. Finalmente usamos UDP, pues tal y como está construido NFS y las RPCs, no necesitamos de los mecanismos de control de TCP y la diferencia de velocidad es asombrosa.
La segunda cuestión a la que nos enfrentamos al tomar medidas, fue la importancia, en cuanto al retardo que originan, de los cambios de dominio entre espacio de usuario y espacio de kernel. Este retardo, es el que originó la creación de la llamada al sistema sendfile original. En algunos casos (en que hay muchos cambios de dominio) puede llegar a ser comparable al del retardo de una llamada a través de la red.
Nos dimos cuenta de que algo estábamos haciendo mal cuando no teníamos el bucle que tiene la llamada sendfile original, que tiene como fin extender la copia a count bytes, (count es el último parámetro de la llamada al sistema). El bucle se encontraba en espacio de usuario y realizábamos muchos cambios de dominio, tantos, que ganábamos mucho menos de lo que esperábamos en el caso a dos.
Una lección que recibimos también fundamental, fue la importancia de las cachés y del readahead. Basta con mirar las medidas para darse cuenta que son realmente fundamentales para el rendimiento, hasta el punto que en el caso de tres ordenadores llegan a hacer read/write, con el fichero atravesando la red dos veces (en teoría), tan rápidos como copy en el que el fichero sólo atraviesa una vez la red.
Nada más terminar la codificación y comenzar las pruebas del sistema, la operación de copy se bloqueaba sin ninguna explicación. Era debido al interbloqueo que se explicó en la sección 4.3. Como ya se ha mencionado antes, este problema fue especialmente largo de resolver, por la dificultad de su localización. En realidad era un problema de diseño que apareció en la fase de depuración. Los interbloqueos son problemas especialmente difíciles de localizar si no se tienen en mente desde un primer momento. Cuando el hilo de ejecución pasa de unas máquinas a otras, hay que tener mucho cuidado.
Otra cuestión interesante ha sido el uso extensivo que hemos hecho de la entrada en /proc. No podríamos haberlo logrado, o al menos no en un tiempo razonable sin el uso de este sistema de acceso a las variables del kernel en tiempo de ejecución. Fue importantísimo para la depuración y absolutamente fundamental a la hora de hacer las medidas.