Just to put a little more info in the post, Gemstone (acquired in May by VMWare's Springsource http://www.theregister.co.uk/2010/05/06/spring_gemstone_futu...) put together GLASS (GemStone, Linux, Apache, Seaside, Smalltalk) as a service for Seaside deployment.
To put it simply, it is an object database. Instead of having clients connecting to it, it is a bit like running the Seaside framework right in the database making development just like having infinite RAM. The database itself is made in two parts, a Stone which persists data and Gems who execute pretty much everything. Scaling usually mean adding more Gems.
The free version prevents you from distributing the gems over several machines. It also limits the size of the database itself (it used to be 4GB, now 16GB) and the size of in-memory data (used to be 1GB, now 2GB).
I use nginx and connect and distribute to several gems through FastCGI. It is a VERY convenient environment to develop for with pretty good performance, then again, I don’t have many concurrent users anyway. I still get better performance than my original web app with a Postgres backend but I beleive it is a lot due to changes in my design.
It is indeed difficult, I had evaluated mine based on the size of my previous postgres database and had greatly overestimated the size. Sadly I don't have my numbers from back then.
It is especially difficult to evaluate since in Smalltalk, you don't specify the type of variables and many of the basic types like numbers will change type to best fit the represented number.
For what it is worth, numbers from a mark and sweep of the repository that happened minutes ago: "<537228> possible dead objects, occupying approximately <48350520> bytes, may be reclaimed.". I mostly store Timespans, dates floats and object references. I have little number strings.
So far it has been running off a 512 Megs slice on slicehost with memory usage below 260 megs. I have seen spikes at over 400 megs a while back but I have considerably modified my app since then.
It is running NGinx, two instances of squeak for generating images, Gemstone along with four service gems and a few ruby processes controlled by cron.
It is difficult to give an exact reading for Gemstone since a lot of the memory it uses is in shared memory and would be accounted many times. Right now I am using about 135 megs of shared memory compared to the allowed 2gigs under the new license. Again, it is a very specific application and I have a few number of users.
12 comments
[ 7.9 ms ] story [ 37.5 ms ] threadGLASS stands for "Gemstone Linux Apache Seaside Smalltalk". http://seaside.gemstone.com/
To put it simply, it is an object database. Instead of having clients connecting to it, it is a bit like running the Seaside framework right in the database making development just like having infinite RAM. The database itself is made in two parts, a Stone which persists data and Gems who execute pretty much everything. Scaling usually mean adding more Gems.
The free version prevents you from distributing the gems over several machines. It also limits the size of the database itself (it used to be 4GB, now 16GB) and the size of in-memory data (used to be 1GB, now 2GB).
I use nginx and connect and distribute to several gems through FastCGI. It is a VERY convenient environment to develop for with pretty good performance, then again, I don’t have many concurrent users anyway. I still get better performance than my original web app with a Postgres backend but I beleive it is a lot due to changes in my design.
It is especially difficult to evaluate since in Smalltalk, you don't specify the type of variables and many of the basic types like numbers will change type to best fit the represented number.
For what it is worth, numbers from a mark and sweep of the repository that happened minutes ago: "<537228> possible dead objects, occupying approximately <48350520> bytes, may be reclaimed.". I mostly store Timespans, dates floats and object references. I have little number strings.
It is running NGinx, two instances of squeak for generating images, Gemstone along with four service gems and a few ruby processes controlled by cron.
It is difficult to give an exact reading for Gemstone since a lot of the memory it uses is in shared memory and would be accounted many times. Right now I am using about 135 megs of shared memory compared to the allowed 2gigs under the new license. Again, it is a very specific application and I have a few number of users.
Since the standard way of working in GLASS is to persist sessions to the stone, the 4GB limit was always a worry in case I get a big peak in traffic.
I am downloading the OS X install right now - something to play with while I am on vacation next week.
http://www.avibryant.com/2008/03/ive-had-a-numbe.html