GallegO wrote: > Hernan Wilkinson escribió: > >> La performance de GemStone es menor comparada con cualquier Smalltalk >> común por un hecho muy simple, tiene que poder escalar a disco todo lo >> que tiene en memoria, esto implica que a veces manda a disco zonas de >> memoria que estás usando o a veces tiene que traer de disco zonas de >> memoria que necesitas. Además, hay que tener en cuenta todo el trabajo >> necesario que tiene que hacer para poder determinar cuando se hace >> commit que objetos debe modificar, etc. >> > Si, entiendo y estoy de acuerdo en que sea asi. Además la opción RDBMS > también es lenta. En algún lado tenemos que guardar... save image > abstenerse de hacer comentarios :D > >> Un tema importante a tener en cuenta en la performance también es el >> tiempo que consume el GemKit. El GemKit es el componente de GemStone >> que instalas en VW o VAST para ver a GemStone como otro Smalltalk, o >> sea, es el responsable de hacerte creer que estás trabajando con >> objetos en tu Smalltalk en vez de con GemStone. Entonces, no es lo >> mismo probar performance desde VW o directamente en un Gem (la VM de >> GemStone), se entiende? O sea, el trabajo que tiene que hacer el >> GemKit de replicación de objetos o forwarding de mensajes impacta. >> Ojo, con esto no quiero decir que la performance es mala, sino que hay >> que tener en cuenta estas cosas. >> > Con GLASS se elimina ese overhead, pero quedas pegado a la menor > perfomance de GemStone. > >> Así y todo, la VM de GemStone (el Gem) es más lento que el resto. Por >> ejemplo, correr esto: >> Time millisecondsToRun: [ 10000 timesRepeat: [ | coll | coll := >> OrderedCollection new. 10000 timesRepeat: [ coll add: 1 ]]] >> En VAST lleva: 3453 >> En VW lleva: 5712 (Sorpresivamente casi el doble...) >> Aca la diferencia no es tan grande pero todavía existe... (Estoy con >> GemStone 6.1.4, o sea, 32 bits) >> > [snip] > Si, en el curso de GemStone de Smalltalks 2008 calculamos un factorial > grande y tardo mucho, mucho, ya con eso nos imaginamos que la > performance como Smalltalk era menor. > También vimos como Squeak calculaba factorial más rápido que VW (Todavia > no lo puedo creer y aún tengo dudas sobre eso ja!) > > Lo que si hay que reconocer que en GemStone, comparado con una > relacional no tenes el costo de instanciación como en las relacionales, > siempre hablando de no usar GemBuilder y usar GLASS, claro esta. > >> Si querés datos de performance de GLASS, andá la blog del tipo que lo >> está haciendo que tiene varios datos sobre hits per second, etc. >> >> > Si, es bastante buena, eso es gran punto a favor de GLASS. > > Saludos > GallegO > > > > yo tambien estoy haciendo cosas con GLASS, empezando, y nada serio, asi que no puedo aportar mucho.
Pero mirá este post de Dale Henrichs sobre algunas medidas rapidas que hizo de performance de aplicaciones hechas en GLASS. http://gemstonesoup.wordpress.com/2007/10/19/scaling-seaside-with-gemstones/ es muy interesante. Cuantos requests necesitas poder contestar por segundo? me gustaria saber esa respuesta. En la prueba que peor le fue aguanta 10 por segundo. Fijate las respuestas al post, la primera de Avi Bryant (el que originalmente hizo Seaside y ahora tiene dabbledb.com un site que recomiendo mucho navegar, hecho en Seaside... y Squeak por detras, con persistencia unicamente en ImageSegments). Obviamente, una opcion recomendable siempre es usar fastcgi (diria que si vas a armar un webserver de cero uses lighttpd y no apache, lighttpd es mucho mas chiquito y rapido, pero no tiene todas las cosas de apache... que no vas a necesitar si usas Seaside), y pongas todo el contenido estatico (imagenes, quizas javascripts, QUIZAS css, flash, video, etc) directamente afuera del seaside. Siempre depende de los requerimientos de tu aplicacion, obviamente. richie --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
