Aha, ok voy a mirar MagriteGlorp pero el de Gjallar por ahora no me presentó insuficiencias. Vale la referencia del memcached. Para mi eso está para más adelante porque todavía estoy mucho antes de esas optimizaciones. Pero vale porque así ya estoy avisado jé. Igual lo de lento o rápido es algo que termina siendo medio subjetivo y en la vida real no encontré nunca impedimentos para llegar a la usabilidad necesaria o aceptable para el end user que es lo que realmente pesa en la ecuación. Además la web tenés más cosas para entretener al usuario mientras se hace algo que demora un toque más que los que por ejemplo tendrías en una app desktop.
Comments: las pruebas que fueron son elementales. Primero hice una transaccion gigante que no se completaba porque superaba los 10megas. En la lista de Magma me recordaron lo de hacer transacciones "medio pequeñas" ni grandes ni microscópicas pero que le podía cargar duro nomás. Así fue. Cuando hice eso le pude entrar a cargar pesado hasta que la imagen engordaba. En mis observaciones entre los 250 y 300 megas de RAM el squeak hace crash (very badly). Lo comenté a la lista y me dijeron que use #stubOut: que lo que hace es poner un proxy en lugar de un objeto ayudando a que el GC de squeak reclame el espacio de esa instancia ayudando a mantener a raya la "voracidad RAMica" del squeak. Tengo que aprender mejor como usar ese stubOut: pero al menos ya logré cargarlo con más de 11mil objetos persona del modelo real que tenian una magma collection cada una con un par de presupuestos cada una. No es mucha cosa pero es mejor que usar ImageSegments :) saludos, Sebastian On 20 out, 14:50, "Ramiro Diaz Trepat" <[EMAIL PROTECTED]> wrote: > 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 > --~--~---------~--~----~------------~-------~--~----~ 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. -~----------~----~----~----~------~----~------~--~---
