Loading ...
Sorry, an error occurred while loading the content.

2170Re: Apache::ASP with Worker MPM

Expand Messages
  • Fagyal Csongor
    Dec 5, 2006
      Tom Haapanen wrote:

      > On 2006-12-05 06:47, Fagyal Csongor wrote:
      >> What I have been running lately is an Apache2.2 with the worker MPM
      >> as a proxy, and a good-old Apache1.3 with mod_perl+Apache::ASP as
      >> the "real" server. The mod_perl server serves the dynamic ASP pages,
      >> while the front servert the static content. This is a very typical
      >> configuration IMHO.
      >> I could once (something like two years ago?) make Apache::ASP run
      >> with Apache 2.0, but that was a long time ago... since then, I stick
      >> to the above config - which I recommend to you if you do not want to
      >> waste too much time on figuring out all the stuff about Apache2.x and
      >> mod_perl (even though it shouldn't be too hard).
      >> For the record: we do somewhere around 6M-8M pageviews per month (see
      >> http://www.kepeslap.com at http://www.apache-asp.org/sites.html),
      >> which peeks to approx. 500-700k pageviews per day in busy periods.
      >> This is a 1.8Ghz Core2 with 3G RAM, in a shared environment (with two
      >> other rather busy sites running on the same server). CPU utilization
      >> reaches 50% of all available CPU time, tops (I guess half of that is
      >> coming from the ASP site).
      > Thanks ... it sounds like your config works well for you. However,
      > since 95% of our page views are dynamic, I'm not sure it would gain
      > much. The only thing I can think of there is serving all the images
      > off Apache 1.3.

      Usually a webpage (at least in our case) consists of the main .asp
      (.pet, etc.) file plus the additional stuff, like .js, .css and image
      files. The ration is usually around 1:10 (of course that can vary a
      lot). It is a huge benefit that these hits do not hit the heavyweight
      mod_perl server. Also, the front proxy server can have keepalive
      switched on, runs threaded, very lightweight, only using small memory
      footprint as compared to the huge mod_perl server.

      Also keep in mind that you will end up having a lot of mod_perl-ed
      Apache instances running unnecessarily because of (realtively) slow
      clients, which keep your Apache waiting. Again, this is a typicla
      reverse proxy configuration.

      Before we started to use this config, we always had memory problems,
      having 200+ Apache instances running, which is an overkill. Now we can
      serve dynamic hits with only 30 Apache1.3 instances, while having
      somewhere around 400 Apache2.0 available connections.

      I also have another website running on a dual 2.4GHz Xeon, in a similar
      config, with 4G RAM - that handles 2M pageviews per day (that is over
      20M HTTP requests).
      This results in 2000+ active connections at peek to the front server,
      while we only have somewhere around 120 instances of the backen server

      > Our CPU load isn't too bad (dual Opteron 242 currently) since the
      > database is on a separate server, but there are still times that the
      > number of httpd processes are maxed out and the browser has to wait
      > for a connection. So the new hardware will be dual Opteron 270s (dual
      > core) so I have no worries about CPU load -- I'd just rather run 4-6GB
      > rather than 8-10GB of RAM.

      Well, see above :)
      You can easily decrease the number of instances needed if you make your
      incoming connections independent of the speed of the remote client.

      Just take a look at your /server-status/. Especially if you have big
      files to serve, you will see connections lingering there. That is what
      eats up your resources.

      > But maybe the images on a separate server process are the answer ...
      > there are close to 10x as many requests for images as for pages.
      > Mostly small GIFs but also a lot of larger JPEGs. Need to give this
      > idea some thought as an alternative. Thanks!

      Even though I do not know your application, I am pretty sure this would be a possible alternative for you.

      See this:

      There are many white pages and how-to-s on this subject around. I can also give you an example httpd.conf snippet if you are interested.

      - Fagzal

      To unsubscribe, e-mail: asp-unsubscribe@...
      For additional commands, e-mail: asp-help@...
    • Show all 7 messages in this topic