You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Justin <jb...@dslreports.com> on 2000/12/20 04:59:59 UTC

recommendation for image server with modperl

Hi, 
I've been catching up on the modperl list archives, and would 
just like to recommend "mathopd" as an image web server.

After having difficulties with the sheer number of front end
apache processes necessary to handle 10 backend modperls,
(difficulties: high load average and load spikes, kernel time
 wasted scheduling lots of httpds, higher than expected latency
 on simple requests), I switched all images to another IP
address on the same box (extending their IMG SRC somewhat
obviously), but now served by mathopd.

Mathopd is a simple select based, http 1.1 (keep alive)
compliant tiny webserver that is very configurable. I was
doubtful that it would hold up (it comes with zero documentation ..
the docs say "read the source"). But it has not crashed *once*,
and its very nice to see just one 22mb process with 500+ minutes
of cpu time (for several weeks of work), and have images
come in fast and reliably.

It uses select and as many file handles for a proc as you have.
If load increases beyond (say) your limit of 1024 fds, it re-uses
currently unused but kept-alive fds, meaning a graceful
degradation. It is also exceedingly fast, much faster than
apache serving images (that doesnt matter, but it does mean
its frugal with your CPU).

Of course I still have 120+ apache httpds (now just being front
end for *page* requests), and my wish is that mathopd would add
proxy and regexp rewrite capability, then I could do away with
apache completely on the front end !! or I guess apache2 with
mod_rewrite and mod_proxy would solve that, at the risk of
thread related teething problems.

Just a recommendation from left field.
-Justin

Re: recommendation for image server with modperl

Posted by "Jeremy A. Mates" <jm...@sial.org>.
On Tue, 19 Dec 2000, siberian wrote:
> Is there some sort of ssl version to handle secure image requests so you
> dont get those nasty security flags?

stunnel could wrap the requests to a non-ssl backend, but that would most
likely be harder and cost more resources than just running a SSL-enabled
Apache:

http://www.stunnel.org/

However, I could be wrong, as I haven't used stunnel to wrap an http
server before, only low-usage IMAP and LDAP servers.

-- 
Jeremy Mates                                       http://www.sial.org/
Chiacuthulu: watch the horror grow!


Re: recommendation for image server with modperl

Posted by siberian <si...@siberian.org>.
Is there some sort of ssl version to handle secure image requests so you
dont get those nasty security flags?

John-

On Tue, 19 Dec 2000, Buddy Lee Haystack wrote:

> Tell me more...
> 
> How about memory leaks & mod_perl issues?
> 
> 
> 
> Justin wrote:
> > 
> > Hi,
> > I've been catching up on the modperl list archives, and would
> > just like to recommend "mathopd" as an image web server.
> > 
> > After having difficulties with the sheer number of front end
> > apache processes necessary to handle 10 backend modperls,
> > (difficulties: high load average and load spikes, kernel time
> >  wasted scheduling lots of httpds, higher than expected latency
> >  on simple requests), I switched all images to another IP
> > address on the same box (extending their IMG SRC somewhat
> > obviously), but now served by mathopd.
> > 
> > Mathopd is a simple select based, http 1.1 (keep alive)
> > compliant tiny webserver that is very configurable. I was
> > doubtful that it would hold up (it comes with zero documentation ..
> > the docs say "read the source"). But it has not crashed *once*,
> > and its very nice to see just one 22mb process with 500+ minutes
> > of cpu time (for several weeks of work), and have images
> > come in fast and reliably.
> > 
> > It uses select and as many file handles for a proc as you have.
> > If load increases beyond (say) your limit of 1024 fds, it re-uses
> > currently unused but kept-alive fds, meaning a graceful
> > degradation. It is also exceedingly fast, much faster than
> > apache serving images (that doesnt matter, but it does mean
> > its frugal with your CPU).
> > 
> > Of course I still have 120+ apache httpds (now just being front
> > end for *page* requests), and my wish is that mathopd would add
> > proxy and regexp rewrite capability, then I could do away with
> > apache completely on the front end !! or I guess apache2 with
> > mod_rewrite and mod_proxy would solve that, at the risk of
> > thread related teething problems.
> > 
> > Just a recommendation from left field.
> > -Justin
> 
> -- 
> BLH
> www.RentZone.org
> 


Re: recommendation for image server with modperl

Posted by Buddy Lee Haystack <ha...@email.rentzone.org>.
Tell me more...

How about memory leaks & mod_perl issues?



Justin wrote:
> 
> Hi,
> I've been catching up on the modperl list archives, and would
> just like to recommend "mathopd" as an image web server.
> 
> After having difficulties with the sheer number of front end
> apache processes necessary to handle 10 backend modperls,
> (difficulties: high load average and load spikes, kernel time
>  wasted scheduling lots of httpds, higher than expected latency
>  on simple requests), I switched all images to another IP
> address on the same box (extending their IMG SRC somewhat
> obviously), but now served by mathopd.
> 
> Mathopd is a simple select based, http 1.1 (keep alive)
> compliant tiny webserver that is very configurable. I was
> doubtful that it would hold up (it comes with zero documentation ..
> the docs say "read the source"). But it has not crashed *once*,
> and its very nice to see just one 22mb process with 500+ minutes
> of cpu time (for several weeks of work), and have images
> come in fast and reliably.
> 
> It uses select and as many file handles for a proc as you have.
> If load increases beyond (say) your limit of 1024 fds, it re-uses
> currently unused but kept-alive fds, meaning a graceful
> degradation. It is also exceedingly fast, much faster than
> apache serving images (that doesnt matter, but it does mean
> its frugal with your CPU).
> 
> Of course I still have 120+ apache httpds (now just being front
> end for *page* requests), and my wish is that mathopd would add
> proxy and regexp rewrite capability, then I could do away with
> apache completely on the front end !! or I guess apache2 with
> mod_rewrite and mod_proxy would solve that, at the risk of
> thread related teething problems.
> 
> Just a recommendation from left field.
> -Justin

-- 
BLH
www.RentZone.org

Re: recommendation for image server with modperl

Posted by Justin <jb...@dslreports.com>.
I did try thttpd.

As I understood it, and I did send an email to acmesoftware to ask
but got no reply, thttpd does not handle keep-alive, and indeed
users complained that images "came in slowly". I also observed this.
I'm happy to be corrected, maybe I picked up the wrong version or
did not study the source carefully enough. I could not find any
config variables relating to keep-alive either..

I found some benchmarks which showed mathopd and thttpd similar in
speed. Only linux kernel httpd can do better than either.. but
request rates per second of 1000+ is of academic interest only..

-Justin

On Tue, Dec 19, 2000 at 08:37:23PM -0800, Perrin Harkins wrote:
> On Tue, 19 Dec 2000, Justin wrote:
> > I've been catching up on the modperl list archives, and would 
> > just like to recommend "mathopd" as an image web server.
> 
> I think you'll find thttpd (http://www.acme.com/software/thttpd/) faster
> and somewhat better documented.  However, I'd like to point out that we've
> had no problems using Apache as an image server.  We need the ability to
> serve HTTPS images, which mathopd and thttpd can't do, but more than that
> we've found the performance to be more than good enough with a stripped
> down Apache server.
> 
> > After having difficulties with the sheer number of front end apache
> > processes necessary to handle 10 backend modperls, (difficulties: high
> > load average and load spikes, kernel time wasted scheduling lots of
> > httpds, higher than expected latency on simple requests)
> 
> Load averages are tricky beasts.  The load can get high on our machines
> when many processes are running, but it doesn't seem to mean much: almost
> no CPU is being used, the network is not saturated, the disk is quiet,
> response is zippy, etc.  This leads me to think that these load numbers
> are not significant.
> 
> Select-based servers are very cool though, and a good option for people
> who don't need SSL and want to squeeze great performance out of budget
> hardware.
> 
> - Perrin

-- 
Justin Beech                      http://www.dslreports.com
Phone:212-269-7052 x252             FAX inbox: 212-937-3800
mailto:jb@dslreports.com --- http://dslreports.com/contacts

Re: recommendation for image server with modperl

Posted by Steve Reppucci <sg...@logsoft.com>.
I'll second Perrin's remarks on using apache for this -- we run a stripped
down apache to serve image files, and have been extremely happy with the
performance.  I've casually investigated thttpd and a couple of others,
but ended up sticking with Apache mainly because it's well documented and
we already know how to do the care and feeding of it.

On Tue, 19 Dec 2000, Perrin Harkins wrote:

> On Tue, 19 Dec 2000, Justin wrote:
> > I've been catching up on the modperl list archives, and would 
> > just like to recommend "mathopd" as an image web server.
> 
> I think you'll find thttpd (http://www.acme.com/software/thttpd/) faster
> and somewhat better documented.  However, I'd like to point out that we've
> had no problems using Apache as an image server.  We need the ability to
> serve HTTPS images, which mathopd and thttpd can't do, but more than that
> we've found the performance to be more than good enough with a stripped
> down Apache server.
> 
> > After having difficulties with the sheer number of front end apache
> > processes necessary to handle 10 backend modperls, (difficulties: high
> > load average and load spikes, kernel time wasted scheduling lots of
> > httpds, higher than expected latency on simple requests)
> 
> Load averages are tricky beasts.  The load can get high on our machines
> when many processes are running, but it doesn't seem to mean much: almost
> no CPU is being used, the network is not saturated, the disk is quiet,
> response is zippy, etc.  This leads me to think that these load numbers
> are not significant.
> 
> Select-based servers are very cool though, and a good option for people
> who don't need SSL and want to squeeze great performance out of budget
> hardware.
> 
> - Perrin
> 

=-=-=-=-=-=-=-=-=-=-  My God!  What have I done?  -=-=-=-=-=-=-=-=-=-=
Steve Reppucci                                       sgr@logsoft.com |
Logical Choice Software                          http://logsoft.com/ |


Re: recommendation for image server with modperl

Posted by Perrin Harkins <pe...@primenet.com>.
On Tue, 19 Dec 2000, Justin wrote:
> I've been catching up on the modperl list archives, and would 
> just like to recommend "mathopd" as an image web server.

I think you'll find thttpd (http://www.acme.com/software/thttpd/) faster
and somewhat better documented.  However, I'd like to point out that we've
had no problems using Apache as an image server.  We need the ability to
serve HTTPS images, which mathopd and thttpd can't do, but more than that
we've found the performance to be more than good enough with a stripped
down Apache server.

> After having difficulties with the sheer number of front end apache
> processes necessary to handle 10 backend modperls, (difficulties: high
> load average and load spikes, kernel time wasted scheduling lots of
> httpds, higher than expected latency on simple requests)

Load averages are tricky beasts.  The load can get high on our machines
when many processes are running, but it doesn't seem to mean much: almost
no CPU is being used, the network is not saturated, the disk is quiet,
response is zippy, etc.  This leads me to think that these load numbers
are not significant.

Select-based servers are very cool though, and a good option for people
who don't need SSL and want to squeeze great performance out of budget
hardware.

- Perrin