Juan: Como explicas vos, no serviría.
Saludos GallegO Juan Buligovich escribió: > Gallego > > Hernán comentaba > "Hay una herramienta para sincronizar repositorios de esa manera... no > me > acuerdo el nombre... pero básicamente lo que hace es anotarse como > observer > de los cambios realizados en un repositorio y replicarlos en otro... > nunca > la use pero se que existe. Te conviene preguntar en la lista de > gemstone por > ella." > > Hernán. Te referías a operar con un servidor duplicado? > > En el capítulo 1, última sección (1,7) del manual SysAdminGuide para > GemStone 6.1 (estamos utilizando GemStone 6.1.2 y 6.1.5) explica cómo > operar con un duplicate server. Se basa en un segundo GemStone Server > corriendo permanentemente a modo restore. El segundo server se > alimenta de la información en los logs generados por el server > principal. > > Creo que esta opción es piola como para poder conmutar rápidamente al > segundo server si se cae el primero. Para eso habría que hacer un > commitRestore para sacar al segundo server de la modalidad restore. > > Gallego, por lo que entendí de tus comentarios esto no te serviría. O > mejor dicho, te serviría si fueran dos servers activos, o que el > segundo server funcionara como nodo más cercano y que la maquinaria > GemStone terminaran sincronizándolos transparentemente. > > Me parece que GemStone -al menos en las versiones que conozco- no > tiene algo así. > > Saludos > Juan > > On Dec 3, 10:35 am, GallegO <[EMAIL PROTECTED]> 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 >> > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
