On 10/18/07, Ramiro Diaz Trepat <[EMAIL PROTECTED]> wrote: > > > Hola Norberto, > Muy interesante tu post. Me gustaría saber si probaron la última > versión de Magma (r40?) y si notaron algún cambio de performance en > esta nueva versión.
Si, estamos trabajando con la r40 y la performance mejoró mucho desde que la usamos. Hace un tiempo yo hice un pequeño sistema/tesis de análisis técnico > de precios de la bolsa en Squeak, una parte importante era bajar > series históricas y almacenarlas en Magma para analizarlas luego. El > sistema manejaba volúmenes muy pequeños, parecidos a los tuyos, por > ejemplo tenía que cargar 10,000 registros de precio de una acción para > calcular algo. Esto se tornaba casi imposible por lo lento que era, a > pesar de que también le puse un poco de voluntad al tunning de los > indices y ReadStrategies. Tuve que terminar poniendo caches por todos > lados... Las ReadStrategies son un misterio para mi. Me la pasé afinandolas para mejorar la performance y después en algunas pruebas que hicimos, teníamos los mismo tiempos con estrategias muy distintas. Y si, también tuvimos que darle a las cachés. Como Magma era la OODB que más me gustaba como quedaba integrada al > código (de las gratarola, como bien decís) me interesaba mucho saber > si había una mejora importante en la nueva versión, sobre todo por que > creo recordar que Chris Muller dijo que en algún caso de query simple > la mejora de performance era de más de un orden de magnitud. > Creo que otra cosa buena de la nueva versión es que soporta > replicación on-line y por lo tanto distribución de carga en varios > servers, esto es otra cosa que puede ayudar a una aplicación en > producción. Hum, eso no lo probamos. Junto con los problemas de performance, lo más riesgoso de usar > Magma en producción (para mi) es que que Magma es un "one man show" > (igual que GOODS, OmniBase e incluso GLORP). El día que estos > muchachos peguen una novia (hay media naranja para todos nosotros) o > decidan ponerse un parri-pollo, te regalo mantener el código de una > OODB prácticamente sin documentación, aunque por otro lado, Magma ya > tiene muchos años de desarrollo y creo que debe ser un paquete > bastante sano/estable. > Pero, por otro lado, casi todo lo importante en Squeak es así, al > mismo Seaside no lo mantiene *solo* Lukas, pero la ayuda que tiene > diría que es mediana, Avi creo que ya no aporta casi nada y Philippe > es el otro desarrollador que hace un aporte sistemático. Pero el > único core developer, creo que es Lukas Renggli. Si, el Squeak es un poco así. Uno de los problemas que estamos teniendo es que la memoria que se va morfando Magma es enorme y la liberación de memoria en Squeak no es un tema sencillo. No podemos evitar que las imágenes crezcan aunque hagamos todos los cleanup posibles. Saludos > > > r. > > On 10/18/07, Norberto Manzanos <[EMAIL PROTECTED]> wrote: > > Hola Sebastián. > > Nosotros (Juan Burella, Hernán Morales y yo) estamos usando Magma y en > estos > > días estamos poniendo en producción lo que venimos haciendo. > > Optamos por Magma porque era la solución más transparente a nuestra > > disposición. En eso me parece que le gana a todos (dentro de lo que es > > gratarola), aunque no es lo suficientemente transparente, porque uno no > deja > > de pensar en términos de "base de datos". > > El gran problema de Magma es la performance, esto es gravísimo. > > Por ejemplo, nosotros teníamos que hacer una migración de 12.000registros > > de una base de datos que se convertirían en otros tantos objetos, con > > bastante profundidad, lo cual terminaba en unas 15 colecciones Magma > con > > algunos miles de objetos cada una. Como la base original no estaba > > normalizada, había que buscar en magma cada cosa que se agregaba para no > > duplicarla. La migración, a pesar de varios intentos de optimizar estos > > tiempos, tardó 10 dias!!!! > > En la aplicación que estamos poniendo en producción, los tiempos de > > recuperación de objetos son apenas aceptables. > > Te paso algunas pautas > > - Es muy importante controlar cuantos objetos se materializan cuando uno > > muestra subconjuntos de una colección. > > -Mantener los MagmaCollectionReader en memoria mejora muchos los > tiempos. > > - También es bueno mantener el diccionario (root) de las colecciones > magma. > > - La generación de índices es bastante costosa. Hay que buscar el > equilibrio > > entre la cantidad y tamaño de los índices y la performance. En el caso > de > > subidas masivas de datos, es preferible tener un sólo índice > impresindible > > durante el proceso, y después agregar los demás al final. Tener un > índice es > > imprescindible, no se gana nada al crear una colección sin índices y > buscar > > por oids. > > > > Espero que te sirva para algo. Cualquier duda, preguntame a ver si se > como > > resolverlo. Lo mismo si descubrís algo importante, pasalo, porque la > > documentación es muy escasa, así que son más las dudas que las certezas. > > > > Saludos > > Norberto > > > > > > > > > > On 10/17/07, Sebastian <[EMAIL PROTECTED]> wrote: > > > > > > Hola todos, > > > > > > quería preguntarles si alguno ha usado con éxito Magma en > > > producción, que le parece el sistema, en fin cualquier feedback y en > > > general que les parece Magma. Escucho todas las opiniones más aún las > > > que sean basadas en experiencias de produción reales (workload, etc). > > > > > > gracias, > > > > > > Sebastian > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Has recibido este mensaje porque estás suscrito a Grupo "clubSmalltalk" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a [email protected] Para anular la suscripción a este grupo, envía un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups.google.com/group/clubSmalltalk?hl=es. -~----------~----~----~----~------~----~------~--~---
