Caramba.... ¿Y cuándo se supone que es adecuado llamar al #cleanUp, cada vez que levantas la imagen?
On 10/24/07, Sebastian <[EMAIL PROTECTED]> wrote: > > > Otra anecdota fue que despues de las pruebas había muchas instancias > de MagmaSession incluso despues de bajar todo lo relativo a la app y > limpiar la pool. > Así fue que la imagen quedó en unos 120megas de tamaño en disco. > Luego vi un poco más y encontré que MagmaSession tiene un metodo de > clase que se llama #cleanUp es medio bestia porque hace de todo para > limpiar pero despues de correrlo dejó esa imagen en 27megas. > > saludos, > > Sebastian > > On 22 out, 15:50, Sebastian <[EMAIL PROTECTED]> wrote: > > 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. -~----------~----~----~----~------~----~------~--~---
