Linden Lab está avanzando en el proyecto de modificar la forma en que las texturas y los mesh son enviados desde Second Life a los visores de los usuarios. Esto redundará en una, proyectada, duplicación en la velocidad con la cual las texturas y los Mesh son recibidos por nuestro visor y, luego, mostrados en pantalla. Es evidente que aquí, estamos hablando de una mejora considerable en lo que es la carga del mundo virtual cuando nos conectamos y/o hacemos teleport a otras regiones.
Históricamente y hasta ahora, el proceso que permite transferir texturas y Mesh desde Second Life implica una sucesión de acontecimientos iniciados por nuestro visor al conectarse al mundo virtual y arribar a una región. Aquí, nuestro visor le «pide» al simulador de la región que le envíe el contenido en ella, cuando hablamos de texturas y mesh, el simulador solicita ese contenido a los servidores de assets y lo almacena en su propio caché, luego envía al visor solicitante un enlace creado al efecto para poder acceder a ese contenido en su caché, con ese enlace el visor accede al mismo y lo descarga para poder ser visualizado por el usuario. En caso que otro usuario solicite la misma información, ésta será envíada desde el caché del servidor, si aún existiera en el mismo, evitando repetir la consulta y descarga desde el servidor de assets, lo cual acelera el proceso.
Independientemente de la cantidad de pasos, los cuales no influyen tanto en el tiempo que pueda demandar recibir el contenido (ya que solo implican décimas de segundo a nivel servidores), uno de los cuellos de botella mas importantes es la carga del propio simulador: cantidad de texturas alojadas en la región, cantidad de objetos, cantidad de Mesh alojados, avatares conectados, etc. Lo cual, es evidente, conspira contra la velocidad de entrega de la información y contenido por la cantidad de peticiones simultáneas que puede estar recibiendo y atendiendo en un momento dado.
Para mejorar este proceso, como he dicho al principio, Linden Lab ha decidido atacar el problema a través del uso de una Red de Entrega de Contenidos (en inglés: Content Delivery Network – CDN). Esto es, una red de servidores que alojan copias de un contenido determinado (en este caso las texturas y los Mesh de Second Life) distribuidos por diversos sitios en el mundo y a los cuales se accede por proximidad geográfica para obtener la mayor velocidad de descarga posible. Un buen ejemplo serían los cachés de contenido de Youtube.
Ahora bien, en el caso de Second Life, si bien, la red CDN no va a estar distribuída globalmente, sino en los mismos sitios geográficos que todos los servidores de la empresa (Estados Unidos), igualmente se espera que al ser dedicados exclusivamente a esta tarea, la mejora en la prestación del servicio será notoria y significativa, especialmente, especula Linden Lab, para los usuarios del resto del mundo (léase, usuarios fuera de Estados Unidos).
A raíz de una petición de Oz Linden al grupo de desarrolladores del visor Singularity y, especialmente, para quienes vivimos fuera de Estados Unidos, tuve la oportunidad de participar en una prueba de esta nueva metodología, prueba que, para Oz, buscaba mostrar el comportamiento del visor Singularity con la red CDN.
Efectuada la prueba de rigor, que implicó hacerla en el grid Aditi (grid Beta de pruebas de Second Life), teniendo que borrar manualmente el caché del visor antes de cada test, fijar la distancia de dibujo a 512 metros, utilizar durante toda la prueba las mismas preferencias gráficas y fijar (en nuestro caso, vía debug Settings) el ancho de banda máximo (para texturas y Mesh) en 10.000Kbps – 10Mbps), entrar directamente a los 4 sims de prueba (según el tipo de contenido y la metodología de entrega utilizada), confeccioné el informe correspondiente y se lo remití por mail a Oz. Pero, mi inquietud no quedó ahí, había hecho las pruebas, tal como él lo pidió, con Singularity, pero ahí nació la idea de este artículo y, para que fuera mas completo, repetí dichas pruebas, con los visores Oficial de Linden Lab y Firestorm 64 bits.
A continuación, comparto con ustedes los resultados de dichas pruebas y las condiciones en que fueron ejecutadas, como así también los parámetros de hardware y red disponibles para el test:
Sistema Operativo: Linux Kubuntu (Ubuntu + KDE) 14.04, 64 bits.
Procesador: Intel i5 750 (2.67Mhz)
Memoria RAM: 12Gb
Tarjeta Gráfica: Nvidia GeForce GT 610 (2GB de RAM interna)
Conexión a Internet: CableModem 6Mb.
Ubicación geográfica: Buenos Aires, Argentina
Configuración del Visor ( en todos los casos)
Ancho de banda Máximo: 10000Kbps
Distancia de Dibujo: 512 metros
capacidades gráficas: todas activas, menos Efectos Atmosféricos y Modo de Iluminación Avanzado, que han sido desactivados.
Condiciones para la prueba:
Utilizar el grid Aditi de Second Life
Vaciar manualmente el caché del visor antes de cada prueba
Iniciar sesión directamente en cada uno de las regiones destinadas a la prueba. Son 4, a saber:
TextureTest CDN, para la prueba de descarga de texturas vía CDN
MeshTest2H, para la prueba de descarga de Mesh vía CDN
TextureTest SLS, para la prueba de descarga de texturas con la metodología tradicional (a través del propio simulador)
MeshTest2, para la prueba de descarga de Mesh con la metodología tradicional (a través del propio simulador)
Procedimiento:
Como he dicho anteriormente, primero se debe vaciar manualmente el caché del visor, luego, iniciar sesión en el grid Aditi, directamente en la región elegida (de las 4 disponibles). Activar la consola de información de descarga de Texturas (Ctrl+Mayus+3) y cronometrar el tiempo transcurrido entre que pulsamos en el botón Iniciar Sesión y la consola nos informa que se han descargado todas las texturas (o Mesh) disponibles en la región.
Nuestro avatar debe ser el único en la región (suele estar vacía) para no «ensuciar» la prueba al tener que cargar otros avatares.
Esta prueba, debe repetirse, al menos, 3 veces por cada región y debemos obtener un resultado promedio para hacer una corecta evaluación de los tiempos obtenidos.
Visores:
Singularity
Firestorm
Visor Oficial de Second Life
Resultados obtenidos:
(la prueba implica una descarga de unas 5600 texturas y unos casi 5200 mesh)
| Región / Visor | Singulariity | Firestorm | Second Life |
| TextureTest SLS | ~210 seg. | ~160 seg. | ~170 seg. |
| MeshTest2 | ~150 seg. | ~140 seg. | ~135 seg. |
| TextureTest CDN | ~120 seg. | ~98 seg. | ~80 seg. |
| MeshText2H | ~65 seg. | ~75 seg. | ~60 seg. |
Como podemos ver, la diferencia a favor del nuevo sistema es significativa y varía entre una mejora de velocidad entre el 50 y el 100% respecto del actual sistema. En el caso de del test de texturas con singularity(1) y el actual sistema, si bien, en los distintos test me ha dado valores inferiores, opté por tomar el citado para enviárselo a Oz ya que hice otras pruebas y obtuve tiempos similares, al menos, el 30% de las pruebas realizadas en el mismo simulador.
En general, con pocas diferencias, podemos ver que los resultados son similares para los 3 visores, lo que indica que cuando Linden Lab implemente CDN en el grid Agni (principal) no importará que visor utilicemos (esta fue la idea de realizar el test con estos 3 visores) para poder vernos beneficiados con esta mejora.
Algo que si noté visualmente mientras vigilaba las estadísticas de descarga de cada prueba y en cada visor, es que Singularity fué el visor que mas texturas detectó y descargó, seguido por el visor Oficial y luego Firestorm. Y aquí hablamos de valores significativos, una diferencia de entre 500 y 1000 texturas (500 mas que el oficial y 1000 mas que firestorm).
Si quieren realizar el test por su cuenta (con cualquier de estos visores o con otro), ya he detallado los parámetros de la misma y las reglas generales, pero, les dejo el siguiente enlace al wiki )en inglés) donde se explica la misma: Prueba de envio de Texturas y Mesh. Y, ovbiamente, quien cumplimente dichas pruebas, está invitado a compartir con nosotros sus propios resultados.
SaludOS/2
(1) El caso del visor Singularity lo considero especial por varios motivos. Vale aclarar que cuando Linden Lab implemente CDN, dará de baja el sistema actual de simulador (tanto a nivel servidor como en el código del visor), con lo cual, eliminará algo importante para la compatibilidad de características con Opensim. Si el proyecto Opensim no sigue este camino, muchos visores se verán obligados o, a duplicar el trabajo al tomar el código del visor 3 Oficial y luego agregarle la compatibilidad con UDP/http (Sistema Actual) o desarrollar una versión para SL y otra para Opensim. Firestorm ha seguido este último camino, pero por otro motivos, asi que es obvio que continuará por esta senda y, recientemente, Kokua ha anunciado que, precisamente, por los cambios que se vienen, dividirá su proyecto en un visor para SL y otro para Opensim. ¿Qué hara el resto? aún no se sabe.
En el caso de Singularity, al tener código propio, al que se le incorpora el código del visor 3 oficial, no tiene este problema y la intención es continuar dando soporte a ambos métodos en una sola versión del visor. Es por este motivo que, también, puede parecer que Singularity es «mas lento» en las pruebas, solo que está decidiendo internamente cual método utilizar.