Ahh, gracias por la aclaraciòn. Pensé que ya se podía usar.
Saludos. El día 25/10/07, Facundo Vozzi <[EMAIL PROTECTED]> escribió: > > > Hola Germán, > Gemstone todavía no está disponible para probar. Supuestamente en poco > tiempo vamos a poder probar la versión Beta pero todavía no se sabe > cuando. > > Saludos, > Facundo > > Germán Arduino escribió: > > Muy interesantes todas las experiencias con Magma, gracias. > > > > Una pregunta que se me ocurre es si alguien probó Gemstone, ahora que > > (teóricamente) está disponible para Squeak. > > > > Saludos. > > Germán. > > > > El día 24/10/07, *Ramiro Diaz Trepat* <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> escribió: > > > > 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] > > <mailto:[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] > > <mailto:[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] > > <mailto:[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 > > > > > > > > > > > > > > > > > > > > -- > Facundo Vozzi > InfOil S.A. > Project Leader > (+54-11) 4542-9999 x108 > [EMAIL PROTECTED] > > > > > --~--~---------~--~----~------------~-------~--~----~ 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. -~----------~----~----~----~------~----~------~--~---
