Re: HTTP Mod_Perl mini-server

2000-12-03 Thread Greg Stark

Perrin Harkins [EMAIL PROTECTED] writes:

 On Fri, 3 Nov 2000, Vivek Khera wrote:
  Lately I've been getting very interested in using solid-state disks
  for high-performance issues.  They're expensive, but if you need that
  much speed, they're worth it.
 
 Are they?  I tried one once, and it wasn't any faster than my normal disk
 because I had so much RAM it was all getting buffered already.  If you
 don't have enough RAM, it might help, but I suspect these are more
 expensive than equivalent amounts of RAM.

Solid state disks are very effective for particular applications like mail
spools and database logs where the application waits for data to be flushed to
disk before continuing. For most normal applications the same effect can be
obtained by adding RAM and/or playing with tools like memfs. 

-- 
greg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: HTTP Mod_Perl mini-server

2000-12-03 Thread spam

On 3 Dec 2000, Greg Stark wrote:

 Perrin Harkins [EMAIL PROTECTED] writes:
 
  On Fri, 3 Nov 2000, Vivek Khera wrote:
   Lately I've been getting very interested in using solid-state disks
   for high-performance issues.  They're expensive, but if you need that
   much speed, they're worth it.
  
  Are they?  I tried one once, and it wasn't any faster than my normal disk
  because I had so much RAM it was all getting buffered already.  If you
  don't have enough RAM, it might help, but I suspect these are more
  expensive than equivalent amounts of RAM.
 Solid state disks are very effective for particular applications like mail
 spools and database logs where the application waits for data to be flushed to
 disk before continuing. For most normal applications the same effect can be
 obtained by adding RAM and/or playing with tools like memfs. 

SCREW solid state disks. Get more ram. Depending on the size of your
website it might be smart to make a ramdisk of a 200MB in size... would be
lightning fast, and apache won't even know about it. For database
application with limited growth and size it might be very good thing to
do, like a dynamic website, from a content database, that is mirrored from
harddrive to the ramdisk on regular basis. Content editing is done
straight to the disk, but lock tables and dump the database, and go on
like a happy camper... =) NO RAID will be faster than RAM, and if it is,
it will cost a price of the new prosche and latency will never be anywhere
near ram... so I'd just give it up right now. Raid is good for large
amounts of data, but if your site is not over 500MB altogther, just get a
linux(or BSD) box fit it with 1G of ram 8G IDE drive and you will be
faster than amazon, provided, that you have enough processing power.

That is all.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




Re: HTTP Mod_Perl mini-server

2000-11-03 Thread Matt Sergeant

On Fri, 3 Nov 2000, Nigel Hamilton wrote:

 Hi,
 
 I'm contracting for an Ad Serving company and we were mooting the idea of
 writing our own lean and mean web server for serving the Ads.
 
 We would like to hold all the Ads in memory (each Ad is less than 20K).
 
 The next thing is to create a pool of mod_perl-esque processes that will
 handle the AD requests and also hold persistent connections to the
 database.
 
 I would like to write this mini-server in perl ... but maybe a threaded
 programming language is better?
 
 Does anyone know a good process/threading model for handling the requests
 and passing them around? Will we see a significant performance improvement
 in any event?

egads, don't do it... Web servers are well developed for this kind of
thing, and modern filesystems (e.g. ext2fs) will buffer the ads in RAM
anyway if you have enough. You're not likely to get any speed increase
doing it this way. If you're that concerned about perhaps the weight of
Apache + mod_perl, consider trying TUX or thttpd, or something else
lightweight written in C.

-- 
Matt/

/||** Director and CTO **
   //||**  AxKit.com Ltd   **  ** XML Application Serving **
  // ||** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // ** Personal Web Site: http://sergeant.org/ **
 \\//
 //\\
//  \\




Re: HTTP Mod_Perl mini-server

2000-11-03 Thread David Hodgkinson

Matt Sergeant [EMAIL PROTECTED] writes:

 egads, don't do it... Web servers are well developed for this kind of
 thing, and modern filesystems (e.g. ext2fs) will buffer the ads in RAM
 anyway if you have enough. You're not likely to get any speed increase
 doing it this way. If you're that concerned about perhaps the weight of
 Apache + mod_perl, consider trying TUX or thttpd, or something else
 lightweight written in C.

Dare I add that Squid has plenty of low-latency cacheing features you
could use? 

-- 
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star   http://www.deep-purple.com
  Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
  -



Re: HTTP Mod_Perl mini-server

2000-11-03 Thread Gunther Birznieks

Other than some of the caching other people talked about (eg squid)...You 
might also take a look at mod_mmap to hold the ads in shared memory among 
the Apache processes and still use mod_perl for the logic of which ad to serve.

Later,
Gunther

At 09:46 AM 11/3/00 +, Nigel Hamilton wrote:
Hi,

I'm contracting for an Ad Serving company and we were mooting the idea of
writing our own lean and mean web server for serving the Ads.

We would like to hold all the Ads in memory (each Ad is less than 20K).

The next thing is to create a pool of mod_perl-esque processes that will
handle the AD requests and also hold persistent connections to the
database.

I would like to write this mini-server in perl ... but maybe a threaded
programming language is better?

Does anyone know a good process/threading model for handling the requests
and passing them around? Will we see a significant performance improvement
in any event?

NIge

__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/




Re: HTTP Mod_Perl mini-server

2000-11-03 Thread G.W. Haywood

Hi all,

 At 09:46 AM 11/3/00 +, Nigel Hamilton wrote:
 I would like to write this mini-server in perl ... but maybe a threaded
 programming language is better?
 I'm contracting for an Ad Serving company and we were mooting the idea of
 writing our own lean and mean web server for serving the Ads.

Matt's right, don't do it.  And Gunther, what on earth is the date on
your machine doing?

73,
Ged.




Re: HTTP Mod_Perl mini-server

2000-11-03 Thread Vivek Khera

 "MS" == Matt Sergeant [EMAIL PROTECTED] writes:

MS doing it this way. If you're that concerned about perhaps the weight of
MS Apache + mod_perl, consider trying TUX or thttpd, or something else
MS lightweight written in C.

Lately I've been getting very interested in using solid-state disks
for high-performance issues.  They're expensive, but if you need that
much speed, they're worth it.  I'm looking more for mail spool issues,
but I guess for serving up static content, it might make sense...

Personally for this type of thing I'd start with one of the mini web
servers and tweak it by hand to meet my needs (logging to a database
as you indicated).

But then it isn't mod perl and you can't discuss it here ;-)

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.Khera Communications, Inc.
Internet: [EMAIL PROTECTED]   Rockville, MD   +1-240-453-8497
GPG  MIME spoken herehttp://www.khera.org/~vivek/



Re: HTTP Mod_Perl mini-server

2000-11-03 Thread Perrin Harkins

On 3 Nov 2000, David Hodgkinson wrote:
 Dare I add that Squid has plenty of low-latency cacheing features you
 could use? 

In my tests, a modern version of mod_proxy (serving from cache) was faster
than Squid on Linux.

- Perrin




Re: HTTP Mod_Perl mini-server

2000-11-03 Thread Perrin Harkins

On Fri, 3 Nov 2000, Vivek Khera wrote:
 Lately I've been getting very interested in using solid-state disks
 for high-performance issues.  They're expensive, but if you need that
 much speed, they're worth it.

Are they?  I tried one once, and it wasn't any faster than my normal disk
because I had so much RAM it was all getting buffered already.  If you
don't have enough RAM, it might help, but I suspect these are more
expensive than equivalent amounts of RAM.

- Perrin




Re: HTTP Mod_Perl mini-server

2000-11-03 Thread David Hodgkinson

Perrin Harkins [EMAIL PROTECTED] writes:

 On 3 Nov 2000, David Hodgkinson wrote:
  Dare I add that Squid has plenty of low-latency cacheing features you
  could use? 
 
 In my tests, a modern version of mod_proxy (serving from cache) was faster
 than Squid on Linux.

Really? Cool. What about taking memory usage into account?

-- 
Dave Hodgkinson, http://www.hodgkinson.org
Editor-in-chief, The Highway Star   http://www.deep-purple.com
  Apache, mod_perl, MySQL, Sybase hired gun for, well, hire
  -



Re: HTTP Mod_Perl mini-server

2000-11-03 Thread Perrin Harkins

On 3 Nov 2000, David Hodgkinson wrote:

  In my tests, a modern version of mod_proxy (serving from cache) was faster
  than Squid on Linux.
 
 Really? Cool. What about taking memory usage into account?

Well, Squid is kind of a memory hog and mod_proxy has been extremely light
and well-behaved, even under heavy load.  I would encourage others to try
benchmarking it for themselves, but I currently see no reason to use Squid
over mod_proxy.
- Perrin