Hi again!
Thanks for the answers btw. Now, some more:
I assume you (Brent) use two processes on a single machine (a Magma server proc and a Seaside proc) and remote connections. And given what you wrote on minnow I also guess you use one Magma session per Seaside session. And AFAIK each Magma session builds its own "read set" so a Seaside image with x users (sessions) would have x copies of the domain objects read, right?
Now - the system in question will possibly involve around 100 concurrent users. And most of them will be readers. So.... :) any ideas on "smarter" solutions to that issue? For example, all Seaside sessions could share a single read session and then allocate a new Magma session (from a pool so that we avoid the allocation of course) when performing a modifying transaction.
And while on the subject - anyone using multiple Seaside images in a "round robin" fashion to utilize multiple CPUs or multiple servers?
regards, Göran
On 12/22/05, goran@krampe.se goran@krampe.se wrote:
Now - the system in question will possibly involve around 100 concurrent users. And most of them will be readers. So.... :) any ideas on "smarter" solutions to that issue?
Kiluaea does connection pooling for Magma. You'll only need as many sessions as you'll have maximum concurrent transactions (compared to concurrent sessions, this can easily make one or two orders of magnitude difference).
I assume you (Brent) use two processes on a single machine (a Magma server proc and a Seaside proc) and remote connections. And given what you wrote on minnow I also guess you use one Magma session per Seaside session. And AFAIK each Magma session builds its own "read set" so a Seaside image with x users (sessions) would have x copies of the domain objects read, right?
Right.
Now - the system in question will possibly involve around 100 concurrent users. And most of them will be readers. So.... :) any ideas on "smarter" solutions to that issue?
We were also concerned about this - we got to +/-50 users using one Magma session per Seaside session without problems.
And while on the subject - anyone using multiple Seaside images in a "round robin" fashion to utilize multiple CPUs or multiple servers?
We have apache with https infront of our Seaside image.
Our very simple idea was to have each Seaside image add an integer keyword (_i=1,2,3..) to the Seaside URLs and had apache redirect to a different port:
https//...../_s=..&._k=...&_i=1 --> http://localhost:1111/https//...../_s=..&._k=...&_i=1 https//...../_s=..&._k=...&_i=2 --> http://localhost:2222/https//...../_s=..&._k=...&_i=2 etc.
I am not sure how new sessions were to be distributed amongst the Seaside images.
It turns out we never needed this though - too damed stable as it is !
I would like to get the canonical answer to this though.
Brent
On 12/22/05, Brent Pinkney brent.pinkney@aircom.co.za wrote:
And while on the subject - anyone using multiple Seaside images in a "round robin" fashion to utilize multiple CPUs or multiple servers?
We have apache with https infront of our Seaside image.
Did you look at mod_backhand?
Now - the system in question will possibly involve
around 100 concurrent
users. And most of them will be readers. So.... :)
any ideas on
"smarter" solutions to that issue?
We were also concerned about this - we got to +/-50 users using one Magma session per Seaside session without problems.
I would just like to inform everyone who may not know, for maximum performance in 3.8, be sure to install this fix:
http://bugs.impara.de/view.php?id=1382
This fix improves peak commit rate by 33%. It may improve other operations as well.
This used to be included in the one-click load but I was advised to remove it. But now it bugs me that people will download Magma and not know about this to enjoy its full performance potential..
magma@lists.squeakfoundation.org