Me alegro mucho que estés haciendo estas pruebas, no dejes de mandar tus conculsiones a la lista, una vez que hayas avanzado.
Un par de cosas más para comentar: 1. Fijate el connection pool de MagritteGlorp si no te gusta más que el de Gjallar. 2. Según parece, hoy en día la gran mayoría de las tecnologías *chetas* de generación de sitios web dinámicos son super lentas (Seaside, Rails, Django, etc), y por lo tanto, para lograr una performance decente todas se apoyan en arquitecturas muy similares de reverse proxies y distribución de carga en múltples VMs/imágenes, utilizando un apache 2.2, haproxy, pound o algo equivalente adelante, y por lo general compartiendo un cache de objetos distribuido en el famoso memcached para pegarle menos a la base de datos, que suele convertirse en el cuello de botella. Yo quería hacer un cliente en Squeak para memcached el fin de semana largo pasado, pero cuando me disponía a hacerlo me fijé si ya había alguno hecho y justo Philippe acababa de subir uno, que parece estar lleno de patterns, mucho más prolijo que el que yo tenía en mente :). Aunque no sé si serializa bien los objetos o si sólo manda y recibe ByteArrays.... En fin, te recomiendo, si aún no lo has hecho, que explores si usando memcached en alguna parte de tu aplicación podés mejorar mucho la performance y compartir instancias entre diferentes imágenes de Seaside. Saludos On 10/19/07, Sebastian <[EMAIL PROTECTED]> wrote: > > Hey Ramiro gracias por la sintesis, > > estuve leyendo el código de Gjallar y el pool de conecciones no es > nada del otro mundo. De hecho es una sola clase y la puse en un > paquete monticello aparte en 5 min. La estoy empezando a probar. Vamos > a ver todavía no la cargué con muchos usuarios pero no me dio ningún > problema despues de portarla dándole un uso básico con sesiones > seaside. > > Por lo de hacer algunas de lectura y otras de lectura/escritura no > llegué a ver que la pool haga nada en especial. Al menos en Gjallar > 0.3 no vi nada tipo #getReadonlySession, tiene el método #getSession > normal (que la agarra activa y/o revive y/o crea en forma protegida > por un semaforo). > > Lo de la performance.. si se trata de una aplicación seaside está la > web de por medio y eso enmascara un poco para el usuario por lo que > creo que manejándose con cuidados debería poderse lograr una > experiencia buena. > > Lo que si hay que evitar al máximo es la agrupación de muchos > objetos en una coleccion. Hay veces que no se puede evitar pero creo > que se debe tratar de evitar. Para ilustrar lo que digo se me ocurre > este ejemplo: si uno tiene que modelar las personas en un país, en ves > de hacer > > Pais>>ciudadanos > ^ ciudadanos > > y que en esa instVar esten todos los individuos, (supongamos un orden > de magnidud inferior a la centena de millón) sería preferible hacer > que > > Ciudad>>ciudadanos > ^ ciudadanos > > cada ciudad los (sos)tengan y para consultarlos hacer que las queries > tengan el rol de encuestas. Si unaCiudad supera un número de > individuos que sea fácilmente o razonablemente manejable y ocurre que > por ejemplo supera los 100mil individuos, entonces instanciarla como > CiudadGrande y particionar los ciudadanos a que los tengan > algunosBarrios. > > Todo esto de la tecnología de objetos virtuales que se comunican es > para crear un ambiente que propicie hacer fácilmente (para nosotros > los humanos) modelos virtuales, y limintados, de objetos reales que > son órdenes de magnitud más complejos. > > Las odb no hacen otra cosa que persistirlos tal cual son en algún > medio tecnológico y en forma confiable, fault tolerant, ACID, etc. > Esto significa que la virtud de la odb es que no te exige que > revirtualizes (alejando aún más de la realidad el modelo) lo ya > virtualizado en algún otro molde, como por ejemplo tablas, porque el > estado de la tecnología al dia de hoy es una kk en cuanto a usabilidad > para desarrollar. Con esto quiero decir: las odb te ayudan a no > deformar más el modelo y facilitarte la vida para materializar la > virtualización del modelo vigente. O sea respetando lo mejor posible > el concepto que un cerebro humano concibió y eligió aceptar como > válido (realísticamente solo por un período) para un objeto real. > > Por qué digo todo esto? para contextualizar esto: minimizar la > importancia o no valorar la citada virtud es dejar de lado la > heurística no en uno sino en varios de sus principios. > > También reflexiono y me pregunto por los números que Norberto > citaba. 12mil objetos deberían ser "like a walk in the park" para una > odb de modo que voy a hacer un par de pruebas de carga a ver como se > desempeña. > > saludos, > > Sebastian > PD: si después le venden sistemas de encuestas de opinión a las > consultoras de los candidatos por favor hacerlos mejores que los del > INDEC </chistin> > > On Oct 18, 10:08 pm, "Ramiro Diaz Trepat" <[EMAIL PROTECTED]> wrote: > > Un par de aclaraciones más, aunque vuelvo a aclarar: no por > > experiencia real en sistemas en producción: > > > > 1. Chris dice que cuando separás el cliente y el servidor Magma, la > > parte gruesa del trabajo se la lleva el cliente, no el servidor, como > > quizás sea más intuitivo pensar. Por lo que la distribución de carga > > entre n servidores está buena seguro, pero también hay que pensar en > > el cuello de botella de los clientes. > > > > 2. Usar connection pools en las sesiones de Seaside es crítico. > > Göran dijo alguna vez que los connection pools de Gjallar estaban muy > > buenos por que diferenciaban sessiones de lectura y de escritura, pero > > la verdad nunca las vi. También dice que no tiene tiempo de > > *refactorizarlas* en un paquete externo. > > > > 3. Chris tiene siempre la mejor y te ayuda todo lo que puede, en la > > lista y fuera de lista. Yo en una época le quemé la cabeza, realmente > > pensé que me iba mandar al carajo, pero simpre me dio bola con mis > > problemas. Yo vengo *jugando* con Magma desde 2003 y siempre fue así. > > Comparado con el soporte de GOODS y OmniBase, me quedo seguro con > > Magma. GLORP tiene una buena lista y soporte... pero hay que venderle > > el alma al diablo de las bases relacionales :) Hay una forma de hacer > > el uso de GLORP más amigable, más parecido al ActiveRecord de Ruby, > > con el paquete MagretteGlorp de Ramón Leon, pero en muchas > > circunstancias no funciona y hay que terminar uando GLORP puro. > > > > 4. Magma tiene un sistema de queries que, a mi criterio, es un valor > > agregado enorme, y sé que esto es un asunto discutible, que hay mucha > > gente que te dice que es "solo una cuestión de diseño". En los > > sistemas grandes uno piensa un modelo lo más puro posible y no desea > > pensarlo en función de consultas posteriores, después los usuarios > > piden reportes complejos y cosas como un "order by" te pueden venir > > mucho mejor que estar filtrando y ordenando colecciones a mano. > > > > 5. Otro punto a favor es que creo que Magma es estable, y Chris le > > pone tests muy rigurosos. > > > > 6. De a poco, le van dando más lugar a Magma en la comuniad Squeak. > > Creo que están explorando hacer la persistencia de Pier y de > > squeaksource sobre Magma. Pero realmente nos sé como va esto. > > > > La verdad, creo que el único punto fuerte en contra de Magma es la > > performance, y por cuestiones de diseño, esto siempre hay que probarlo > > en el caso particular de cada uno. > > Otro punto en contra podría ser que no está disponible en otros > > dialectos fuera de Squeak. > > > > Saludos > > > > r. > > > > On 10/18/07, Sebastian <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hola Norberto, > > > > > esta respuesta está mejor que algunos post de blogs que vi por ahi > > > (bueno que para ser justos hay que aclarar que en realidad eran > > > bastante básicos). Pero realmente conocer los detalles que comentás de > > > la experiencia que pasaron al usarlo me resulta de lo más interesante. > > > > > Con lo que vi de Magma, muy superficialmente, hasta ahora, también me > > > resulta muy atractivo el nivel de transparencia que promete. Parece > > > ser ideal para cuando uno necesita poner todo en un objeto modelo y > > > usarla acediendo a cada cosa según su reacheability con ese root > > > object (que debería ir somewhere en el diccionario root de magma) y > > > usar las MagmaCollections solo cuando se trata de muchas instancias. > > > > > Las pautas que pasaste me traen algunas preguntas que me gustaría > > > pasarte: > > > -Quisiera saber si te interpreto correctamente cuando decís: "También > > > es bueno mantener el diccionario (root) de las colecciones magma." te > > > referís a que las MagmaCollection son más ineficientes si están en > > > algún lado diferente (más profundo del modelo persistido) que a > > > tenerlas instaladas directamente en un valor del diccionrio root? o se > > > trata de otra cosa? > > > -Cuando decís que no deja de pensar en bases de datos te referís a qué > > > aspecto/s exactamente? a los problemas de transacciones, concurrencia, > > > al relacional o a algún otro/s? > > > > > Con certeza que hay que colaborar tanto para su usabilidad como buenas > > > prácticas, etc porque esto lo banca la comunidad pero más que nada > > > Chris M. y es la única forma de salir del problema del "one man show" > > > que bien menciona Ramiro y que no me preocupa a priori porque todos > > > hablan bien del soporte que viene dando hace rato Chris. Por otra > > > parte la comunidad va mostrando tímido interés a medida que Magma > > > mejora. Una clara señal de esto es el proyecto Gjallar el cual estoy > > > leyendo código para ver como van usando la odb. Ya vi por ejemplo que > > > usan un pool de conexiones me pareció bien interesante. Y bueno > > > también porque lo cierto es que no tenemos a la mano alternativas open > > > que sean más atractivas. > > > > > Imagino que lo de la posibilidad de hacer un farm de magmas debe ser > > > el camino de esto pero te hago la pregunta igual la van a usar > > > multiusuario? aparentemente Gjallar la usa multiusuario y tengo > > > entendido que es el uso más osado en el sentido de que las actuales en > > > realidad son todas experiencias pioneras porque no ha nadie que haya > > > cargado mucho a Magma (no solo en cantidad de instancias) en el > > > pasado. Algo con respecto a la carga de usuarios? > > > > > Lo que después le respondiste a Ramiro acerca de la memoria que va > > > creciendo tiene alguna consecuencia extra además de no liberarla? > > > concretamente ese problema llega a ser grave como generar caídas de la > > > imagen o algún otro tipo de inestabilidad? o simplemente hace que se > > > infle digamos hasta 200 megas y despues nunca adelgace? es 200 megas > > > un numero cercano al que experimentaron o sería mayor? > > > > > gracias de nuevo por la info y saludos, > > > > > Sebastian > > > > > On 18 out, 10:15, "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.000 > > > > registros > > > > 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. -~----------~----~----~----~------~----~------~--~---
