As for a database server different from an HTTP server... think about what each is doing.
AN apache http server is about 800k (at least mine was before PHP <G> ) If you add mod_perl to that, each process is about 4 meg (?). That's a bloated chunk of memory, a lot of start up overhead, but faster execution once started. Especially if the same cgi programs are being run, and persistant database connections can be maintained, and most calls are cgi based.
If you are doing mostly http calls, simple "kick the file out the port" type work, mod_perl bloated servers are _not_ the way to go. In fact, that's part of the effort to come up with some guidelines on when it pays to run two servers (check their site).
A database server needs fast disk I/O, good CPU speed to process requests. A server is also tuned to "serving" database files, so read/write access is optimized, and all sorts of other memory, bus, and bios tweaks. The software is leaner, less unnecessary services, and the machine is allowed to do what it was set up to do -- Operate a database system, and manage it's own processes.
An http server on the other hand can be lean, lower powered. Disk I/O is not as near as important as enough RAM to allow the servers to load and keep a cache around. CPU load is very, very low. On my apache system, the servers can't make the machine breath hard even under heavy load. The database on the other hand, when the beta spider is running, can get MySQL up to almost 50% CPU usage (It usually hovers around 2-3% with Link SQL). I did that with only 3 spider processes.
On the other hand, I can serve 40 or 50 http processes with lean apache and have the CPU at about 2-4% depending on how much CGI is being run.
So.... you want a server with fast CPU and system archetecture set up with the software optimized to allow the database to access system resources without having to "share" with unrelated processes.
The other way to look at it is, you've got a really good database server, especially for this sort of read-mostly write-hardly access. You won't be waiting on it much, if ever, even during peak usage. On the other hand, you've got a freakin' awesome http server, that is probably overkill unless you were running a couple of dozen active virtual domains off it.
If you combine the two on one machine, you've got something in the middle of each.
I guess a good analogy would be my DSL line. I've got a 640k line, because I really don't need faster (my cost/value falls off like a cliff after that point, I just want fast pages <G> ). But, I get 640k DOWN stream, and 90k UP stream, with the upstream given preference (I guess because my CPU is calling the shots). If I use 40k of my upstream bandwidth, I lose _at_least_ 300k of my downstream bandwidth.
The database system is like the UPSTREAM and the http is like the downstream. You will lose a lot more of your HTTP as the database sucks it away to keep itself running. Unix is good about making things share, but still, http uses very little resources per process (it's designed that way on purpose, and historically) but databases _need_ more resources, and every feature we ask be incorporated makes them suck more. The bigger the database package, the more horsepower it needs to do the same work (MySQL is _very_ efficient compared to things like Oracle, but it has fewer of the advanced features).
There are no _rules_ for this. Some applications coexist very, very well together, even when they might not on the surface appear to. Others don't get along at all, even if the raw resources are apparantly there.
Links SQL is not a big hog of reasouces (but I only have a realtively small database) but the rest of my site is all cgi and qmail (we guide people through the postcards process, then have to send it).
My overall system usage is still under 10% even running the spider several hours every night.
Your mileage will vary
Oh, BTW, there is _nothing_ better than MySQL out there for the price, and for most applications Oracle is over kill, and MySQL performs better. Check the mysql.org site for some stats on that. If you don't need the advanced and "optional" features of Oracle, MySQL is the way to go. You can port your applications and databases UP to almost any other system should the need ever arise.
If I were building your system, and wanted to put everything in place and grow into it as you are doing, I'd add a disk drive to the machine you have, and consider going to a hardware RAID archetecture if your traffic increases. You'll get better performance and data security as well. I'd put a solid front end machine next to it to handle the basic http requests, and put the CGI file system on the database server with mod_perl (a basic guide is on the mod_perl site). What's a solid machine? If you want to stick with Intel archetecture, a P3 600+ with 256 meg of ram, 2 4-8 meg heavy duty hard drives (hard to get anything smaller now adays), and set it up with apache, 25 or 30 waiting processes. You'll be able to monitor traffic on the HTTP server, as well as the database server, and you'll be able to tune each of them for better performance separately.
Can I give you specifics now? No. But I plan to be in your shoes in about 6 months, and I'm looking at a database server similar to yours, but based on Sparc archetecture since my ISP is a Solaris shop. (If they move to linux, at all, that might change.) I'll keep the Sparc 10 I have now as the front end, and maybe beef up the ram a bit.
Even though this machine is not breaking a sweat yet, I don't want to be in the situation of HAVING to do it all and make it work over a weekend, or in a crunch. I'd rather be there 4 to 6 months early, and have it all working and just scale up, not start out.
Make sense??
It would be nice if others who are running their own machines would jump in with stats -- hardware, usage, etc. Fewer and fewer sites publish that stuff any more, so it's harder to get an idea of what the various sites are using, and what is working best. Only the error messages hint at NT vs Unix <G>
