peterdaly - 1:45 am on Aug 16, 2004 (gmt 0)

If you don't see an obvious need to have two boxes dedicated to their own task (web and db), you may very well not have the need.

One major reason for having them on different machines is so you can scale either piece when it becomes a bottleneck. Generally when the DB starts to become a bottleneck, it should be on it's own machine which is specifically built for the task of serving a database. That generally means as many hard drives and CPU's as possible as well as tons of RAM for starters. Additionally, you can tune the database to take full advantage of the servers resources without worry of affecting the web service side of things.

Generally a good web server is mostly about raw CPU performance, with disk speed as a distant second. A moderate amount of ram will usually be fine.

I have built systems where the database server's disks (6 of them) are totally maxed out in terms of IO at any given time, yet most aspects of the web site, including the database performance for most users seems fine. The web server (a different machine) is on a server who's disk is NOT being starved, so it behaves fine. The DB server is mostly servicing user request/queries from cache (RAM), so end user performace still seems to zip along. Since it's a multi-cpu box, the disk io (jornaling processes), the process causing disk io, and user queries don't have to share a cpu, again decreasing negative effects. If both machines were on the same box, the disk IO would affect the web server, maybe severly. On a well tuned db in a two server system like this, most (all?) users don't even know this disk IO is maxed out and backlogged. Things just hum right along.

Don't know if that helps, but it's one example of where two servers are helpful.