GLASS is now free up to 16 GB and 2 CPU (formerly $7000/year)(seaside.gemstone.com)
seaside.gemstone.com
GLASS is now free up to 16 GB and 2 CPU (formerly $7000/year)
http://seaside.gemstone.com/docs/GLASS-Announcement.htm
6 comments
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.
Is anyone using that here, and if, what for?
I am using it for a web application I sell to public utilities.
GLASS 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.
GLASS 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.
Any feel for "how many objects" 16GB holds? Sure, I know it depends on how big your objects are. But do you have any rule of thumb?
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.
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.
Just curious: How much memory does your system use in practice?
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.
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.
Excellent news.
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.
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.
Looking at those stats, they are going for mid sized corporations.
Probably a smart move if it increases the market. Small nit: Seaside 3 has been released, and it looks like they are only supporting 2.8 right now.
I am downloading the OS X install right now - something to play with while I am on vacation next week.
I am downloading the OS X install right now - something to play with while I am on vacation next week.
It seems that Seaside 3.0 is supported, from the GLASS wiki:
"Seaside3.0 is supported on GemStone/S 64 2.4.4.1 and older.":
http://code.google.com/p/glassdb/wiki/Seaside30LoadOptions
http://www.avibryant.com/2008/03/ive-had-a-numbe.html