GuidesImproving mod_perl Driven Site's Performance -- Part I: Choosing Operating System and...

Improving mod_perl Driven Site’s Performance — Part I: Choosing Operating System and Hardware Page 6

ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.




You have the best hardware you can get, but the service is still
crawling. Make sure you have a fast Internet connection. Not as fast
as your ISP claims it to be, but fast as it should be. The ISP might
have a very good connection to the Internet, but put many clients on
the same line. If these are heavy clients, your traffic will have to
share the same line and your throughput will suffer. Think about a
dedicated connection and make sure it is truly dedicated. Don’t trust
the ISP, check it!

The idea of having a connection to The Internet is a little
misleading. Many Web hosting and co-location companies have large
amounts of bandwidth, but still have poor connectivity. The public
exchanges, such as MAE-East and MAE-West, frequently become
overloaded, yet many ISPs depend on these exchanges.

Private peering means that providers can exchange traffic much
quicker.

Also, if your Web site is of global interest, check that the ISP has
good global connectivity. If the Web site is going to be visited
mostly by people in a certain country or region, your server should
probably be located there.

Bad connectivity can directly influence your machine’s performance.
Here is a story one of the developers told on the mod_perl mailing
list:

What relationship has 10% packet loss on one upstream provider got to
do with machine memory ?

Yes.. a lot. For a nightmare week, the box was located downstream of a
provider who was struggling with some serious bandwidth problems of
his own… people were connecting to the site via this link, and
packet loss was such that retransmits and TCP stalls were keeping
httpd heavies around for much longer than normal.. instead of blasting
out the data at high or even modem speeds, they would be stuck at
1k/sec or stalled out… people would press stop and refresh, httpds
would take 300 seconds to timeout on writes to no-one.. it was a
nightmare. Those problems didn’t go away till I moved the box to a
place closer to some decent backbones.

Note that with a proxy, this only keeps a lightweight httpd tied up,
assuming the page is small enough to fit in the buffers. If you are a
busy internet site you always have some slow clients. This is a
difficult thing to simulate in benchmark testing, though.

Tuning I/O Performance

If your service is I/O bound (does a lot of read/write operations to
disk) you need a very fast disk, especially if the you need a
relational database, which are the main I/O stream creators. So you
should not spend the money on Video card and monitor! A cheap card
and a 14” monochrome monitor are perfectly adequate for a Web server,
you will probably access it by telnet or ssh most of the time.
Look for disks with the best price/performance ratio. Of course, ask
around and avoid disks that have a reputation for head-crashes and
other disasters.

You must think about RAID or similar systems if you have an enormous
data set to serve (what is an enormous data set nowadays? Gigabytes,
terabytes?) or you expect a really big web traffic.

Ok, you have a fast disk, what’s next? You need a fast disk
controller. There may be one embedded on your computer’s motherboard.
If the controller is not fast enough you should buy a faster one.
Don’t forget that it may be necessary to disable the original
controller.

How Much Memory Is Enough?

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends & analysis

Latest Posts

Related Stories