[users@httpd] Emergency Web Server Configuration

["Campbell, Lance" <la...@illinois.edu>]

OS: Linux Red Hat

Apache: 2.2.x

 

I am setting up a dedicated apache web server in order to push out
emergency web pages in the event of an emergency on campus.  The content
that would be pushed out would be static content only consisting of a
few dozen web pages.  I have verified that the number of possible open
files is over a million in the OS.  I have also made sure to shut off
HTACCESS.  Are there any other technical items I should be identifying
or evaluating in order to make sure we could handle an obscene number of
web hits?  Would it be a necessity to have two or more network cards
running in conjunction together?

 

 

Lance Campbell

Project Manager/Software Architect

Web Services at Public Affairs

University of Illinois

217.333.0382

http://webservices.uiuc.edu

My e-mail address has changed to lance@illinois.edu

 

RE: [users@httpd] Emergency Web Server Configuration

[David Dyer-Bennet <Da...@pinerivercapital.com>]

Lance Campbell < lance@illinois.edu > said:


	OS: Linux Red Hat

	Apache: 2.2.x

	 

	I am setting up a dedicated apache web server in order to push
out emergency web pages in the event of an emergency on campus.  The
content that would be pushed out would be static content only consisting
of a few dozen web pages.  I have verified that the number of possible
open files is over a million in the OS.  I have also made sure to shut
off HTACCESS.  Are there any other technical items I should be
identifying or evaluating in order to make sure we could handle an
obscene number of web hits?  Would it be a necessity to have two or more
network cards running in conjunction together?

	 

 

The realizable bandwidth of your network card depends so much on the
exact card, and the driver for it, that I doubt anybody can answer the
general question you asked.  Switch performance, router performance, and
so forth, are all critical factors. 

 

For maximum bandwidth on static content, there are probably better
choices than Apache; Apache is the premiere full-power,
highly-customizable server that can support all the fancy stuff, but all
that ability leaves it probably not being the fastest way to push static
pages out.  I haven't worked with the alternatives myself, but there is
for example a static server that can be embedded in the Linux kernel
that's supposed to be very fast.  There's publicfile, which  is more
supposed to be very secure, I don't know what its performance claims
are. And no doubt there are others.

 

Are you locating this server on campus?  Are the expected users located
on campus during the emergency, or elsewhere?  Emergencies might well
cut off campus net connectivity, and campus power.  It's a common
scenario for big web-hosting companies to set up their emergency status
page *somewhere else*; but your situation is complicated by the fact
that the on-campus population might still have power and need to reach
the emergency pages even if the connectivity to the rest of the net was
cut off.  I'm guessing you've gone into this in detail in your planning
and it just didn't come up in your question, and if so there's no point
in discussing it again here. 

 


--- 

The contents of this message and its attachments, if any, are meant for the sole use of the intended recipient and may be confidential, privileged, or otherwise protected from disclosure. If you are not the intended recipient of this message or have received this message in error, please delete it, immediately alert the sender by reply e-mail, and do not read, disclose, distribute, or otherwise use the information contained herein. If this message was misdirected, neither Pine River nor its affiliates waives any confidentiality or privilege. Pine River retains and monitors e-mail communications sent through its network. This e-mail does not constitute or form part of any offer or invitation to sell, or the solicitation of an offer to purchase any investment and is provided for information purposes only. Pine River believes that the information it provides is accurate and complete as at the date of publication, but does not grant any warranty of such and neither Pine River nor its affiliates accepts any liability in respect of errors or omissions. Past performance is not necessarily a guide to future results.

---