Re: [zones-discuss] Programming for zones
On 3 Oct 2008, at 21:46, Dan Price wrote: Nick, I think this is an interesting idea, but I must caution you that zone_enter(2) isn't a public API, and using it correctly is truly non-trivial. Indeed, that's the impression I have, and seems to be a dominant theme in other replies to my post. One thing I don't really understand about your solution is what economy it achieves. That is to say, why not run an apache instance per-zone? I'm not clear on that until I've tried. I expect modest memory optimisation (one instance). More interesting is if I can make this work without the requirement for a separate public IP address for each zone: it has been suggested that crossbow makes this possible. If you like we can chat offline by phone sometime about this. Yes please! Perhaps you could email me off-list your Sun extension and timezone. -- Nick Kew ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Programming for zones
On 3 Oct 2008, at 23:02, Jordan Brown wrote: Nicolas Williams wrote: On Fri, Oct 03, 2008 at 02:37:28PM -0700, Jordan Brown wrote: Nick is trying to isolate virtual systems, not users. I've seen this That was, obviously, not the impression tat I got. It's trivial to separate virtual systems by just running them in zones. But if I misread what Nick was asking, then you're right, we should respond with documentation on how to setup zones and so on (that documentation exists, of course, and can easily be found online; I suspect Google knows all about it). My interpretation (and hopefully Nick will jump in here soon and clarify) is that he's trying to get some additional cross-zone sharing, over simply running a fresh Apache in each zone. Sorry, shouldn't have posted that shortly before a near-7-hour journey. Just digesting the replies now. I think the mention of zone_enter() is what made me think take Nick's question quite literally. That is, I assumed that zones newbie would not have known about zone_enter(), therefore I assumed Nick is not a newbie. Nick is a newbie to zones:-) Remember that user is a relative term. The user of a hosting company is the hosting customer, *not* the guy behind the web browser. Exactly. The zone_enter will happen at server startup. To have it happen per-request in the server would imply an enormous overhead, because it's a complete misfit to the Apache architecture. CGI could perhaps do it in a similar manner to the existing setuid wrapper, but that's a lesser solution to a less-interesting problem. Note also that (with no disrespect meant to Nick) a common newbie behavior is to latch onto some random interface and attempt to bend it to solve the problem at hand, whether or not it's the intended way to solve that problem. That may indeed be the case. Though I should add, my newbiedom applies to Solaris kernel goodies, not to Apache or web-serving (guess it's time to attach my apache book .sig:-) I'm exploring (or, if you prefer, latching on to) the possibility of a strong solution to a long-standing problem. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/ ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Programming for zones
On 3 Oct 2008, at 22:37, Jordan Brown wrote: Nick is trying to isolate virtual systems, not users. I've seen this problem on my personal hosting providers - my CGI scripts run as the same user as everybody else's, in the same file system. We'd better all trust each other. That's OK for cheesy little personal sites, but not so good for real businesses. Exactly. That's the target market for this development. Though even more so if instead of CGI you used PHP or other in-process scripting, with even less protection than your CGI enjoys. It's quite possible that the IP address alone is enough to determine which zone the server should run in, in which case you could probably do the zone_enter before the listen(). Even without that, the host name (HTTP Host: header) is enough, so you could do the zone_enter() early in HTTP processing. There's no zone_enter in HTTP processing. Just dispatch to a worker that entered a zone at server startup. I agree with Dan that the savings here are questionable over simply running separate Apaches in each zone. You'd save on all-zone-global data (which might be COW pages that never get written) but that's about it. Indeed, it may be that I'm chasing something of very little value, though it should be added that Apache can have a very big memory footprint when in-process bloat like PHP is added. But I'm also interested in whether a global dispatcher can be harnessed to drive virtual servers even when there's only one public IP address. (Note, incidentally, that the picture might be different for a Java server, where the Java byte code for the application and a bunch of overhead objects might well fall into that sharable bucket.) Would that apply to similar bytecode like Python, which is commonly run in-process in Apache? -- Nick Kew ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] Programming for zones
Nick Kew wrote: (Note, incidentally, that the picture might be different for a Java server, where the Java byte code for the application and a bunch of overhead objects might well fall into that sharable bucket.) Would that apply to similar bytecode like Python, which is commonly run in-process in Apache? Don't know, maybe. It would depend on how much of the memory is common between the various servers. Looking again at my comment, the effect I'm imagining would depend a great deal on whether they're all using the same application, and then on whether you know that (and initialize the application) before you fork the servers. It would also depend on how memory happens to be laid out - if it happens that sharable (read-only after initialization) and unsharable (written after initialization) data get interleaved, you might end up with few pages shared. If you initialize the application and *then* fork, I'd expect a great deal of sharability, for any development environment. If, on the other hand, you fork and then initialize the application, probably none of it will be sharable. (Environments that precompile the program and save it in a file might end up sharing that part, but not data or dynamically compiled code.) It should be possible to determine this sharability today, if you're already forking new processes for each customer. The zone_enter() won't affect that. Unfortunately, I don't know how to ask the virtual memory subsystem how much COW memory is shared between two processes. Sorry, that's a little rambling. I'm still asleep :-) ___ zones-discuss mailing list zones-discuss@opensolaris.org
