[Seaside] Re: multiple piers on the same image with apache
Yanni Chiu
yanni at rogers.com
Wed Nov 9 03:29:24 UTC 2011
On 08/11/11 8:00 PM, mail list wrote:
> Lukas wrote:
> You need to make sure that the persistence mechanisms between the
> instances do not mess with each other.
> SCOTT- I had set up different pier kernals for each instance.
Having different pier kernels does not address the issue that Lukas
mentioned.
If you're using image persistency (i.e. image save, done in a forked
process), then there is only one image saved for all kernels. Each pier
kernel will be initiating (IIRC) a check of the transaction log, to
determine if an image save is needed. I think there are concurrency
checks and other code, to ensure that a pier kernel is saved in a
consistent state; however, I'm not sure whether this logic would be
sufficient when another pier kernel initiates an image save.
If you're using image segment persistence, then the above issues don't
apply. But, I'm pretty sure image segment persistence does not work out
of the box, and the image segment code has been (will be?) removed from
Pharo - so that's a bad path.
I use Fuel persistence. See: http://ss3.gemstone.com/ss/pierfuel.html
> SCOTT- This was different piers on different ports in the same image. eg
> in the apache config for domain1.com <http://domain1.com> i would point
> to localhost:8080/pier1 and for domain2.com <http://domain2.com> it
> would ponts to localhost:8081/pier2. Both 8081 and 8080 were on the same
> image but different piers
I don't understand why you need to have separate ports (8080 and 8081),
as well as separate paths (pier1 and pier2). It seems to me that
choosing one or the other would be sufficient.
> I will continue to explore the issue and feedback if i can get it to
> run. I just wanted one image serving the piers since it would be less
> maintenance and less resources on myserver.
Is keeping multiple images up-to-date your maintenance concern? If you
go with the Fuel persistence, then you can use the same image for all
kernels, by reading in the kernel at startup. Fuel has a design goal to
be fast for reading (i.e. de-serializing).
The resource calculation will depend on the size and number of pier
kernel(s) you're running vs. the size of the basic Pier image. Suppose
the basic Pier image is 20MB, and you're running 5 kernels that are each
200MB. Then it's 5*220MB = 1100MB vs 5*200MB + 20MB = 1020MB. Yes, it's
always going to be more memory, but it works now (without your having to
code it). It might be better to spend the time shrinking the size of the
basic Pier image.
> On seasidehosting.st for example, many hundred Pier images run in
> parallel on different ports ...
> SCOTT- Thisis my current configuration. One image for one domain.
How many images? Size of each? Are users seriously impacted by losing
access to their kernel, due to problems in another kernel causing a
re-start?
--
Yanni
More information about the seaside
mailing list