More on Squeak scalability, and a question concering Pharo and Cog.

I appreciated the helpful replies to my last post, the one on scalability.

I am leaning towards Pharo + Seaside and GLORP + PostgreSQL. I don't really have
much experience with Pharo, but from playing around with it, it resembles the
way my custom Squeak images always seem to end up (with the Polymorph widgets,
eCompletion, OmniBrowser, and so on), so it makes sense to just start with Pharo
rather than trying to make Squeak into Pharo. Two things concern me about using
either Squeak or Pharo: first, the current VM is kind of slow, but Cog seems
like it will go a long way towards fixing that. Second, memory consumption. A
fully-stocked Pharo image takes up ~40MB. However, a little Googling revealed
that a fully-stocked Python and Django process requires at least ~30MB, which
isn't that much better, and I am guessing that a lot of stuff (dev tools, for
example) can be ripped out of the image to slim it down (and more so as Pharo
becomes more modular).

Does Eliot, Andreas or anyone else have any estimate on when Cog will be ready
for production use with Pharo? Also, I have no experience with GLORP or with
using PostgreSQL from Squeak. Are there any major show-stopping issues I should
be made aware of, or does this combination work well enough?

Thank you for the help.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 13-Sep-09, at 4:30 AM, Joseph Harrison wrote:

Yes, for mobile wiki server on the iphone we have a Pharo image that  
is 10.5 mb in size.
However if you work at it  you'll find that only 3.4 MB of oops memory  
is actually needed out of the
10.5 image to load a Pier CMS and stick some pages up.  But that  
requires you to avoid
doing an explicit full GC, usage of allInstances, and some tuning of  
the GC parms to ensure a full GC
is a last resort.

Although your desktop/server version of Linux/Unix likely will reserve  
pages for the entire image/oops space, the diagram below
which I showed the XtC group in London last week clearly shows that  
much of the oops space isn't needed to run Pier/Seaside.
Under memory pressure the "_" pages below as they aren't referenced  
would be candidates for being marked as free by the operating
system's virtual memory manager.  On the iPhone the pages are only  
loaded from flash into ram on demand, unlike most systems you use
today where they would page in the entire image via the image file  
mmap request.

The trick then is to avoid an allInstances or a full GC.

Sorry I don't have a diagram that details memory behaviour when the  
Pier CMS is serving pages

Diagram:
WikiServer memory footprint as it runs on the iPhone after image  
startup using the default set of pages when it reaches the first point  
of idle time:
Presented to the London XtC group Sept 8th, 209.

1932 pages in flash memory not in ram (the _)
806 in ram memory (the I )
68 modified (the #, also implies that it is in ram)


######II##I______III#_I_I__#II_I___________#____I__I____________#II_____
___________#_______________________I_______#I_II________________________
______I_IIIIIIIII#IIIII#IIIIIIIIIIIIIIIIIIIIIIIIII_IIIIIIIIIIIIIIIIIIIII
IIIII_IIIIIIIIII_IIII_III_IIII_II_IIIIIIIIIIIIIIIIIII_I#______III_I___II
I_____II##II____II_II___I_I___II_I_I_IIII#IIIIIIIIIII_#IIIIIIIII___IIIII
_____I__II_#_##___IIIII_I__________III####_________________I__IIIII_#II_
__I_III_IIIIII_IIIII_I________II_I_IIIIII#IIIIII_IIII#_IIII__I___IIIIIII
___IIII_III_____________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
___________________II__II___III___III_IIIIIII#I_IIIIIIIIII_____I#II__I__
__________II__III##IIII________________________________I__IIII_I__II_I#_
_##_I#____________#II_____I__#III#I_________#II____III#II_III_IIIIIIIIII
III_III_II___I_I_IIIIIIIIIIIIIII_I_IIIII_IIIIIIIII__IIIIIIII___I_III___I
II______I___IIIIIII_I___II_____I_____I_I_________IIII_IIII_IIIIIII_____I
IIIII_I_IIIIIIIIIIIII_IIIIII_I__I_I____II_II_II________II____I_I__I_III_
______II__###__________________________________________________#I__I____
II__I___III____________IIIII_I_#IIIIII__________#I______________________
III____II________I_____IIIIIIII_________IIIIII_______IIIIIII_I__________
_II#I__I_III____I____II_I__II__I____I___II##I_______II________I__I_III__
__IIIIII________I_______II_________IIII_______IIIIIIII_____I______I___II
__IIII_II______I___IIII__IIII_I_______________________________________________________________________II______________________I_______II__I____I________II________IIIIIIIIIIIIIIIIIII_IIII_I__I_I_____I##_IIIIIIIII_I####II_II_________________________________________II_________I_I_________I_____________________________________________________________IIIIII_III_________________III_______III_III_I_I_I__II_II__I_II______II____________IIII__I_____________________________________________________________________________________________________________________________________II__IIIII_______IIII___________IIIII__I#I#I_II________I__IIII__II_I_III_IIII#I__##I___II______________________II__II________I____________________I_______IIIII_______________I_I_I______II___I_____I___________II__I______________________I____________________________II_I________________________________III____II_____________I____##I__I______#___________________________#



--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================




_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside