Citando Michael van Elst <[EMAIL PROTECTED]>:

> On Thu, Jun 24, 2004 at 07:29:30PM -0300, Alexander Belck wrote:
>
> > There is realy a huge difference in size. The modular apche is about 300K,
> while
> > the one I build in OpenPkg is about 6M. Normaly I see several instances of
> > apache running (about 10 as setup in httpd.conf).
> > I was wundering if using OpenPkg static version of apache will consume
> about 60M
> > of my ram, or will it be smart enouth to share the common code and consume
> > juste a bit more than 1 copy of apache ?
>
> It will share the common code but it won't share the data which
> also grows with the number of modules.

How can I avaliate the amount of memory efectivly used ?
I think that frequenly apache processes are just waiting for a connection and
will hope that in this situation the data reserved for all modules are relativly
small. They should only grow when some module is realy being used by an
webapplication and released again when the site/page is leaved.

>
>
> > I'm afraid that OpenPkg static aproch isn't a good aproach for an (eaven
> small)
> > ISP, where several instances of apache with lots of possible modules will
> be
> > needed.
>
> Two observations:
>
> If your modular apache is about 300K then it doesn't load or use
> all the modules. So why build them into the static binary ?

I just looked at the size of /usr/sbin/httpd, I do not know how to check the
efective memmory used when running, where the necessary modules will be loaded
and obviosly much more ram will be used from the system.
Most modules are enabled, and also most time they are not used, but they are
avaible if someone whants to use them. As an ISP I could not say that I support
PHP, but do not offer lots of functions availble thru PHP.

>
> Building apache with all modules is a bad idea anyway. Most things
> served will be static pages, but the process serving static
> pages has to carry the weight of all the modules. You should think
> about a more flexible approach and use several apache instances
> together, each tailored for a specific purpose. With OpenPKG you
> can do this easily by creating several OpenPKG instances.

I agree that most pages will be static. But administrate lots of sites and
change them to diferent apache instances if/when some cliente tryes to use a new
functionality in his sites is, for me, unhandable.
To be able to compeet with hosting services offerd at prices as low as $3/month
I need to transfer all possible administration to the client. Thats why I'm
trying to use ISPMAN and for his requirments it seams apropriate to use OpenPKG
as the softwares are mostly uptodate, and on a normal distribution I offen got
problems to get the apropriate pre-requisits for the servers with
authentication and ldap requirements ISPMAN needs.


>
> N.B. Yes, this approach wastes disk space, but it helps a lot
> maintaining such an installation which is more important even
> for a small ISP.

Disk space I'm not warried about. But RAM is more expensive and sometimes
dificult to expand.

I whant to think that with static apache the response should be better as all
code is already loaded when some webapplications request there use (in modular
apache I think that the code will be loade just when the webapplication trys to
use it). I just need to know how this will impact my memmory needs.

>
> Greetings,
> --
>                                 Michael van Elst
> Internet: [EMAIL PROTECTED]
>                                 "A potential Snark may lurk in every tree."
> ______________________________________________________________________
> The OpenPKG Project                                    www.openpkg.org
> User Communication List                      [EMAIL PROTECTED]
>


--
ATIX Tecnologia e Com Ltda
Tel.: +55-(11) 4667-5900

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
______________________________________________________________________
The OpenPKG Project                                    www.openpkg.org
User Communication List                      [EMAIL PROTECTED]

Reply via email to