Yo me hice un singleton al que llamo productor que le hago #start, #stop y #restart para que me levante el seaside el magma server segun parametros configurados en un archivo de texto plano de configuracion en el directorio de la imagen. Lo registré para que cuando la imagen levanta hace start y cuando baja haga stop. Una de las cosas que hace al hacer stop es ese cleanUp. El cleanUp tardó bastante cuando la hizo pasar de 120 mgeas a 27 (lo corri y salvé). A partir de alli, si no dejás que acumule a lo bestia va muy bien no tarda más que un #garbageCollect o dos.
saludetes, Sebastian On Oct 24, 2:27 pm, "Ramiro Diaz Trepat" <[EMAIL PROTECTED]> wrote: > 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. -~----------~----~----~----~------~----~------~--~---
