Re: loading mod_perl DSO on a per-virtualhost basis?
Thomas I'd like to configure my apache installation (which contains Thomas several virtualhosts) to use mod_perl (compiled as DSO) only Thomas with _some_ of the virtualhosts, but not all of them. Apache fork()s children to handle requests, hence they are all exact copies of the parent process. Unfortunately, there isn't really a way to do what you want. Thomas That is, I'd like to put a LoadModule directive into those Thomas virtualhost sections which use mod_perl and leave it out Thomas in the other virtualhosts. The benefit (so I hoped) would be Thomas a "small" httpd for the non-mod_perl-virtualhosts and a Thomas bigger one for the others. A single httpd process could handle requests for many different vhosts. You could always run separate Apache instances per vhost. :-) --bruno Bruno Connelly [EMAIL PROTECTED] Interweb Ninjaneer Whack Productions
Re: loading mod_perl DSO on a per-virtualhost basis?
Hi, On Wed, 26 Jan 2000, Bruno Connelly wrote: You could always run separate Apache instances per vhost. :-) Thanks for your comments. From the added ":-)", I derive that this may not be common practice :) However, if I'd like to do so, I'd have to split up my httpd.conf into a part with mod_perl-using-vhosts and a part with the remaining vhosts and setup 2 startup scripts for 2 separate apache instances, both listening on port 80 (or 443 for https). Has anyone ever tried such a setup or used it for a longer period in a production setup? _ Thomas Corte [EMAIL PROTECTED]
Re: loading mod_perl DSO on a per-virtualhost basis?
Bruno You could always run separate Apache instances per vhost. :-) Thomas From the added ":-)", I derive that this may not be common Thomas practice :) It's not uncommon, I'm just making the assumption that if you're worried about resource consumption, this might not your desired solution. However, I don't know your setup. If you'll only be splitting vhosts between a mod_perl enabled Apache instance and one that's not, it might not be too bad. ...assuming the management of that wouldn't be too much of a headache. Thomas However, if I'd like to do so, I'd have to split up my Thomas httpd.conf into a part with mod_perl-using-vhosts and a part Thomas with the remaining vhosts and setup 2 startup scripts for 2 Thomas separate apache instances, both listening on port 80 (or 443 Thomas for https). Yup, it's pretty straight forward. Given you won't want to bind() to every interface plumbed on the machine, you'll probably want to put in a Listen directive per vhost. Unless you're doing name based vhost'ing, but you'll still want a single Listen directive per instance. Thomas Has anyone ever tried such a setup or used it for a longer Thomas period in a production setup? It should work fine, just keep in mind the extra resources required for multiple instances (especially with pre-forking). But again, splitting one instance into two shouldn't be too nasty. --bruno Bruno Connelly [EMAIL PROTECTED] Interweb Ninjaneer Whack Productions
Re: loading mod_perl DSO on a per-virtualhost basis?
However, if I'd like to do so, I'd have to split up my httpd.conf into a part with mod_perl-using-vhosts and a part with the remaining vhosts and setup 2 startup scripts for 2 separate apache instances, both listening on port 80 (or 443 for https). I think you might find the answer to this in the performace tuning section of the mod_perl guide: http://perl.apache.org/guide I haven't got the full url handy. Kees
Re: loading mod_perl DSO on a per-virtualhost basis?
Hi Thomas, On Wed, 26 Jan 2000, James G Smith wrote: Thomas Corte [EMAIL PROTECTED] wrote: So, if I switch to DSOs for (at least) mod_ssl and mod_perl, can I expect to decrease top's values above significantly? I don't think so. My understanding of DSOs in Apache was to allow inclusion of code without recompiling the whole thing. This allows for third-party proprietary modules. The DSOs can, in general, share code across binaries, not processes. All processes sharing a binary don't have separate copies of the binary, or shouldn't. However static libraries cannot be shared between binaries. Only DSOs. Your biggest savings could come from making the perl core a DSO so the perl binary and Apache share the same core perl interpreter code. James is quite right, but I'm told that even making the perl core a DSO won't give the savings that I think you are hoping for. In a mod_perl box, as far as memory consumption is concerned, the processes of concern are usually the Apache children. They are fairly big, and there can be a lot of them. Because of the way that Apache tries to preempt incoming requests by pre-forking a pool of children `just in case', you may not always know how many! They share a good chunk of their memory when they are forked, but then as a result of copy-on-write (two or more processes share a page of memory, one wants to change it, the others don't, so a copy has to be made just for that process) the memory gradually (or otherwise) becomes unshared. When they grab some memory to store a large object, the children have a habit of hanging on to it until they die. In addition there have been memory leakage and similar problems which have sometimes caused the Apache children to do antisocial things like growing without bound and refusing to die. Some of these problems are being dealt with as new releases come out and I'm sure that a lot of us have high hopes for mod_perl 1.22. Running a second server (a `proxy', not mod_perl enabled, and which listens normally on port 80 but always on a _different_ port from the mod_perl enabled server) to serve static documents, tweaking the server configuration variables such as MaxRequestsPerChild to limit child growth, the use of modules designed to limit the processes' resource consumption, and faster networks, clients and servers can all offer partial solutions, but I feel that memory footprint is going to remain an issue with mod_perl until memory is much cheaper per byte (happening as we write) or until Doug and friends make it use less, or until something unthinkable happens - like the technology becoming obsolete overnight because of a breakthrough elsewhere. In the meantime, some people are using Gigabytes of RAM to cope with their mod_perl children. I hope this isn't too depressing:) 73, Ged.
Re: loading mod_perl DSO on a per-virtualhost basis?
Hello, On Wed, 26 Jan 2000, G.W. Haywood wrote: If not, what is the real benefit of DSO It's intended to save memory, by sharing it between processes. Well, this is exactly what I want :). Currently, I have mod_ssl and mod_perl linked statically into my httpd binary (under HP/UX 11), which as a result is about 3MB big. "top" yields a process size of about 9MB, with about 4,5MB resident for each httpd running. This size seems to cause some memory and swapping problems. So, if I switch to DSOs for (at least) mod_ssl and mod_perl, can I expect to decrease top's values above significantly? _ Thomas Corte [EMAIL PROTECTED]
