Practical limits of free license

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Practical limits of free license

patmaddox
I'm looking at the licensing page (http://seaside.gemstone.com/docs/GLASS-Announcement.htm) and just wondering how those different options work in practice. You guys say it "scales to over a hundred billion objects" which is, um, a lot :)  What are the practical limits of the 2 GB / 2 CPU free option? I did some super rough testing in Pharo and came up with around 20-30 million objects in the shared page cache at any one time (1.5 million took up 100 megs of RAM. Then I multiplied).

Also curious about versions: I'm using Seaside 3.0.3. Is GemStone/S 3.0 beta readyish for production? Or should I be deploying to 2.4.4.1 and doing parallel testing on 3.0 to help you guys work out the kinks?

Pat
Reply | Threaded
Open this post in threaded view
|

Re: Practical limits of free license

Mariano Martinez Peck
I will explain it to you easily: don't worry about the limit. I promise. If you reach the limit of GLASS, it means you will have more than enough money to pay Gemstone license :)

On Fri, May 6, 2011 at 12:20 AM, Pat Maddox <[hidden email]> wrote:
I'm looking at the licensing page (http://seaside.gemstone.com/docs/GLASS-Announcement.htm) and just wondering how those different options work in practice. You guys say it "scales to over a hundred billion objects" which is, um, a lot :)  What are the practical limits of the 2 GB / 2 CPU free option? I did some super rough testing in Pharo and came up with around 20-30 million objects in the shared page cache at any one time (1.5 million took up 100 megs of RAM. Then I multiplied).

Also curious about versions: I'm using Seaside 3.0.3. Is GemStone/S 3.0 beta readyish for production? Or should I be deploying to 2.4.4.1 and doing parallel testing on 3.0 to help you guys work out the kinks?

Pat



--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Practical limits of free license

Dale Henrichs
In reply to this post by patmaddox
Pat,

The basic rule of thumb for GemStone is that the whole object table should fit into the SPC. I'm on vacation this week, so I can't talk to folks about calculating the size of the object table based on the number of objects, but when I get back next week I will provide you with the figures ...

 The SPC isn't an upper bounds on the number of objects that you can have ... the SPC limits you in terms of working set size, so the object table must be resident in memory (SPC)...

The gems copy objects into their memory space from the SPC, so a gem with a 1Gigabyte tempObjCache could hold ~10 million 100 byte objects and none of those 10 million would have to remain in the SPC ... they would be read through the SPC ... so with enough RAM, you could have 100 gems each with a unique set of 10 million objects alive on a machine ... that's 1 billion objects in memory ... the trick is that we'd need to calculate how big the object table is for 1 billion objects ... oh and you would load 1 biillion objects into your 100 gems in parallel without some SPC contention going on ... another factor for sizing the SPC ...

There's probably more:)

Does this help a bit?

Dale

On May 5, 2011, at 3:20 PM, Pat Maddox wrote:

I'm looking at the licensing page (http://seaside.gemstone.com/docs/GLASS-Announcement.htm) and just wondering how those different options work in practice. You guys say it "scales to over a hundred billion objects" which is, um, a lot :)  What are the practical limits of the 2 GB / 2 CPU free option? I did some super rough testing in Pharo and came up with around 20-30 million objects in the shared page cache at any one time (1.5 million took up 100 megs of RAM. Then I multiplied).

Also curious about versions: I'm using Seaside 3.0.3. Is GemStone/S 3.0 beta readyish for production? Or should I be deploying to 2.4.4.1 and doing parallel testing on 3.0 to help you guys work out the kinks?

Pat

Reply | Threaded
Open this post in threaded view
|

Re: Practical limits of free license

James Foster-8
According to the System Admin Guide (available at http://community.gemstone.com/display/GSS64/GemStoneS+64+Documentation), page 16 (42 of 562), each object takes up five (5) bytes in the table. Note that the table size is based on the maximum number of objects ever present in the database.

James


From: "Dale Henrichs" <[hidden email]>
To: "GemStone Seaside beta discussion" <[hidden email]>
Sent: Thursday, May 5, 2011 8:47:31 PM
Subject: Re: [GS/SS Beta] Practical limits of free license

Pat,

The basic rule of thumb for GemStone is that the whole object table should fit into the SPC. I'm on vacation this week, so I can't talk to folks about calculating the size of the object table based on the number of objects, but when I get back next week I will provide you with the figures ...

 The SPC isn't an upper bounds on the number of objects that you can have ... the SPC limits you in terms of working set size, so the object table must be resident in memory (SPC)...

The gems copy objects into their memory space from the SPC, so a gem with a 1Gigabyte tempObjCache could hold ~10 million 100 byte objects and none of those 10 million would have to remain in the SPC ... they would be read through the SPC ... so with enough RAM, you could have 100 gems each with a unique set of 10 million objects alive on a machine ... that's 1 billion objects in memory ... the trick is that we'd need to calculate how big the object table is for 1 billion objects ... oh and you would load 1 biillion objects into your 100 gems in parallel without some SPC contention going on ... another factor for sizing the SPC ...

There's probably more:)

Does this help a bit?

Dale

On May 5, 2011, at 3:20 PM, Pat Maddox wrote:

I'm looking at the licensing page (http://seaside.gemstone.com/docs/GLASS-Announcement.htm) and just wondering how those different options work in practice. You guys say it "scales to over a hundred billion objects" which is, um, a lot :)  What are the practical limits of the 2 GB / 2 CPU free option? I did some super rough testing in Pharo and came up with around 20-30 million objects in the shared page cache at any one time (1.5 million took up 100 megs of RAM. Then I multiplied).

Also curious about versions: I'm using Seaside 3.0.3. Is GemStone/S 3.0 beta readyish for production? Or should I be deploying to 2.4.4.1 and doing parallel testing on 3.0 to help you guys work out the kinks?

Pat


Reply | Threaded
Open this post in threaded view
|

Re: Practical limits of free license

Conrad Taylor
In reply to this post by Dale Henrichs
On Thu, May 5, 2011 at 8:47 PM, Dale Henrichs <[hidden email]> wrote:
Pat,

The basic rule of thumb for GemStone is that the whole object table should fit into the SPC. I'm on vacation this week, so I can't talk to folks about calculating the size of the object table based on the number of objects, but when I get back next week I will provide you with the figures ...

 The SPC isn't an upper bounds on the number of objects that you can have ... the SPC limits you in terms of working set size, so the object table must be resident in memory (SPC)...

The gems copy objects into their memory space from the SPC, so a gem with a 1Gigabyte tempObjCache could hold ~10 million 100 byte objects and none of those 10 million would have to remain in the SPC ... they would be read through the SPC ... so with enough RAM, you could have 100 gems each with a unique set of 10 million objects alive on a machine ... that's 1 billion objects in memory ... the trick is that we'd need to calculate how big the object table is for 1 billion objects ... oh and you would load 1 biillion objects into your 100 gems in parallel without some SPC contention going on ... another factor for sizing the SPC ...

There's probably more:)

Does this help a bit?

Dale

Dale, thanks for posting this information because I'm starting to hit a wall with MySQL.  Next, I have been playing with Maglev in my free time and I would like to eventually put together some performance tests at the web level.  Anyways, I would be very interested in any information that you have beyond the standard manuals because I'll need both demo and data to sell this to my company.

Thanks in advance,

-Conrad
 

On May 5, 2011, at 3:20 PM, Pat Maddox wrote:

I'm looking at the licensing page (http://seaside.gemstone.com/docs/GLASS-Announcement.htm) and just wondering how those different options work in practice. You guys say it "scales to over a hundred billion objects" which is, um, a lot :)  What are the practical limits of the 2 GB / 2 CPU free option? I did some super rough testing in Pharo and came up with around 20-30 million objects in the shared page cache at any one time (1.5 million took up 100 megs of RAM. Then I multiplied).

Also curious about versions: I'm using Seaside 3.0.3. Is GemStone/S 3.0 beta readyish for production? Or should I be deploying to 2.4.4.1 and doing parallel testing on 3.0 to help you guys work out the kinks?

Pat