PRIMER PASO HACIA LA LIMITACION DE SCRIPTS
Como parte de nuestro plan de trabajo a largo plazo para mejorar el rendimiento regional y ofrecer más y mejores herramientas para los propietarios y creadores de contenidos por igual, hemos estado trabajando en un proyecto para medir y controlar mas precisamente los scripts. Históricamente, aunque hemos limitado el número de avatares y prims dentro de una región, nunca hemos limitado los scripts.
Esta omisión ha hecho que los problemas de rendimiento de una region sean a menudo el resultado de un exceso de scripts, de ahí la necesidad de reducir la carga de scripts por regiones. Cuando una region tiene demasiados scripts, puede suceder que su consumo de memoria deteriore el rendimiento de todos los simuladores en ese servidor en particular, lo que claramente no es justo para los propietarios de otras tierras que pueden ser afectadas por causas ajenas . Además, sin límites de scripts, el propietario de una sola parcela en una region, podria utilizar tantos scripts, que esto afectara negativamente a los otros propietarios de la región.
En términos generales el proyecto que estamos trabajando tiene tres fases:
1. Información: Lo primero es proporcionar información detallada a los residentes para que puedan entender el impacto de la carga de scripts en objetos y complementos (ropa, pelos, etc) Las primeras informaciones sobre la carga de scripts se incluyen en el Server release 1,38, a partir de Abril, aunque sólo serán visibles para los usuarios de Visor de 2 y Snowglobe. No esperamos agregar esta funcionalidad en el Visor de 1.23, sin embargo puede que otros desarrolladores de software lo integren en sus visores.
2. Herramientas: La segunda fase del proyecto, a final de 2010, será la de proporcionar mejores herramientas y controles para la gestión de scripts. Además, proporcionaremos orientación desde el principio sobre cuáles seran los límites, para que todo el mundo tenga tiempo para adaptarse en caso de que sea necesario. Los límites no deberian afectar a la gran mayoría de la gente, sino que tendrán un impacto en las regiones de más pesado uso.
3. Ejecución: La fase final del proyecto consistirá en hacer cumplir efectivamente el recorte de recursos de script, a nivel de región, basado en la cantidad de tierra dentro de la región - de la misma manera en que los prims se controlan ahora. El baremo estará alto, esperamos que la mayoría de las personas no se verán afectadas por los límites.
Por lo tanto: información, herramientas, y finalmente la ejecución.
¿Qué veremos cuando entre en servicio el servidor 1,38?
Cuando funcione el servidor 1.38, los usuarios de Visor de 2,0 verán un nuevo botón en la pantalla Acerca de la Tierra. Este botón mostrará una nueva ventana que detallara el consumo de los recursos de scripts (memoria). Hay una tabla para el uso de memoria en la parcela, y otra para los scripts adjuntados a los avatares. Para el propietario real de la tierra, la información estara detallada por objeto para que puedan ver exactamente donde la memoria de script se esta utilizando y si es necesario encontrar y eliminar los objetos. Los propietarios de estados y los administradores tendran acceso a los datos de toda la región y todas las parcelas dentro de ella.
¿Qué significan los números?
En la pestaña de la tierra, el número que se muestra es la memoria máxima reservada requerida por todos los scripts de todas las parcelas de propiedad en esa región. Así como la totalidad de prims, puede ser compartida por la totalidad de las parcelas en la región, lo mismo se aplica aquí.
Por ejemplo, si usted es dueño de dos parcelas y tiene un pequeño script de 16K ejecutandose en la parcela A, y si tiene diez scripts de 64 K en la parcela B,el informe de su consumo total seria de 640k + 16k = 656k.
Para la pestaña de Avatar, los números se refieren a los attachments que se lleven ese momento.
En ambas pestañas también verá un contador para el número de direcciones URL. Este es otro componente del consumo de memoria para los scripts - el número de URLs que el servidor tiene que mantener, por ejemplo si el script usa HTTP para hablar con un servicio web externo.
Más detalles tecnicos
(Y por qué usted no debe leer demasiado en los números todavía)
Los números indicados para el uso de memoria de scripts se refieren a memoria reservada, esencialmente al maximo de memoria que puede usar un script, aunque en cualquier momento puede ser que esten utilizando menos de dicho máximo. Usted podría preguntarse por qué no utilizamos el uso de memoria exacta, el problema es que, por definición, el uso de memoria exacta es impredecible y dinámico. El sistema necesita administrar recursos con el máximo de memoria que un script podria utilizar cada vez para garantizar que el contenido no se dispare de los límites previstos, necesitamos saber que si un objeto con script puede hacer un rez (y lo logra utilizando memoria) siempre lo lograra, no que se quede sin memoria y deje de funcionar porque en ese momento necesite mas memoria de la que uso cuando fue rezzeado por primera vez. El uso de la memoria reservada permite predecir esta conducta.
Un script puede ser compilado como LSL o con el nuevo Mono. La huella de memoria para un script LSL es siempre 16K incluso para el más simple script. Se asigna un block de simulador de memoria de 16 K cada vez que se rezzea un script y eso es todo lo que el script cada vez puede utilizar. Scripts que se ejecutan en Mono son capaces de utilizar tanta memoria como necesiten. Si algún script utiliza sólo unos pocos bytes de memoria, entonces eso es lo que el simulador asignará para el script. Nos servimos de esto cuando se introdujo la máquina virtual de Mono: había unos pocos casos donde los scripts utilizados en Mono usaban 4 veces más memoria que un script LSL, por eso dejamos crecer Mono hasta 64 K cuando lo necesitaran, imprescindible para poder garantizar que todos los scripts se puedan convertir en Mono con un solo clic.
Desde entonces, muchos programadores se han aprovechado de la memoria extra que se le dio a los scripts Mono para desarrollar experiencias en Second Life que antes no eran posibles y que se basan en los 64K de la memoria que utilizan. Debido a esto vamos a ser en principio, conservadores en los informes de 64K de memoria reservada para cada script Mono. A finales de este año vamos a añadir características a la plataforma de scripts que permiten a los scripts de Mono cambiar su tamaño de 64k hasta 4k. Hasta entonces las cifras de memoria parece que favorecen los scripts LSL, cuando en realidad Mono es generalmente mucho más eficiente. El tamaño promedio de un script Mono es en realidad 9KB: 7KB más pequeño que el usado por los 16KB de los scripts LSL. En muchos casos, como lo scripts Mono se utilizan para agregar funcionalidad simple, el ahorro es considerable.
Teníamos una opción difícil aqui, por una parte podríamos haber exagerado la carga de memoria de LSL falsamente , o podriamos reportar los números como son en realidad y aceptar que por un momento que LSL sea mas eficiente. Pensamos que teniendo en cuenta que los scripts Mono pronto seran capaces definir sus propios tamaños, más pequeños que los 16k LSL, lo mejor era reportar los numeros reales desde el principio. Esperamos que la posibilidad de los scripts Mono para establecer su tamaño por debajo de 64 K aparezca en el tercer cuatrimestre de este año, mucho antes de cualquier aplicación de limitacion de scripts. Mono sera entonces, en ese momento, claramente la mejor opción en cuanto a memoria se refiere.
Que sera lo proximo?
Una vez que en abril se lance la version de servidor 1.38 , le recomendamos que instale el Visor 2 y eche un vistazo a la información de recursos de script para irse familiarizando con ella. Tenga en cuenta que esto es sólo el primer paso ,iremos perfeccionando la manera de mostrar la información, para hacerla lo mas util posible.
Desde finales de la primavera y en verano esperamos empezar a trabajar con mejores herramientas junto con la información de los scripts, también dentro de poco hablaremos de cuáles probablemente seran los límites de scripts y garantizar que al igual que con los prims, el visor mostrara el uso de los recursos a la vez que estos niveles , de modo que usted pueda ver el impacto que estos limites puedan tener en usted.
Texto original:
http://blogs.secondlife.com/community/land/blog/2010/03/19/the-first-step-toward-script-limits
Traducido por Mariaria Kimono.
Publicado por Gamolan Adamski..!!
