| 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.