| 7:28 pm on Feb 14, 2009 (gmt 0)|
My 2 cents: Start with one box and monitor performance.
As soon as your app becomes slow, start poking around until you find the cause and then see what can be done.
If coded efficiently (caching, quick db queries etc), today's software and hardware should allow you to serve thousands of concurrent users from one physical box.
Branching out is expensive, more servers mean more juice (electricity) and more maintanence.
Hope this helps,
| 7:18 pm on Feb 18, 2009 (gmt 0)|
Thanks for the reply, do you suggest anything in particular to monitor performance outside of the standard System Monitor / Task Manager arena?
| 7:33 pm on Feb 18, 2009 (gmt 0)|
Yes and no... Depending on the size and makeup of your site, you may get better performance by separating functions to different servers.
For years, we ran web, DB, and mail on the same server. About 6 months ago we added a new server just for DB. Instead of often redlining CPU & memory usage, both boxes are now comfortably in the green. Granted, the new box has more processing and memory, so if we moved everything to the new box things might still be in the green (but probably still jumping at least into the yellow) for now. But we also plan for continued expansion of the site so would eventually need 2 boxes later anyway.
| 4:09 pm on Feb 19, 2009 (gmt 0)|
If you have current hardware, server side performance is rarely an issue unless you have high loads. I work with a LAMP powered site pumping out 1+ million page views a day (about 25-30TB/month) in traffic. We run it from 2 servers and use a SAN for the database.
Often disk IO is the issue. Check into tools like sysstat to monitor performance.
| 4:44 am on Mar 25, 2009 (gmt 0)|
Putting the database server and a seperate machine means all your queries are going to go over a network connection. This may (or may not) slow things down. It depends a lot on how much data you actually transfer.
| 11:47 pm on Mar 27, 2009 (gmt 0)|
|Putting the database server and a seperate machine means all your queries are going to go over a network connection. This may (or may not) slow things down. It depends a lot on how much data you actually transfer. |
We've setup clients where the the separate servers were physically hardwired to each other, so it was an extremely fast and private/secure connection between the two boxes.
If you have an extremely DB heavily application, it might be a good idea to have multiple servers.
OR, you can build in a memory caching solution (ie - memcached) to replace the heavy dependency on your database. We do this and it allows us to keep everything on one server. Of course we don't get a million pageviews a day, only about 200k or so.
| 10:12 pm on Apr 3, 2009 (gmt 0)|
|servers were physically hardwired to each other |
In what way? Just saying they had wires connecting them doesn't mean much.
| 4:11 pm on Apr 14, 2009 (gmt 0)|
I have three servers currently. Two are Web servers and the third is my SQL server. It offers load balancing along with the SQL being on its own box. Runs the sites very fast and allow for a vast amount of users. I would recommend hosting with a larger company if you plan to use multiple servers. I host with Server Intellect and one the advantages to a larger company is private IP address. All of the boxes can be reached even during high load via the private ips. Some of your shared or smaller server companies cant offer solutions like this. Plus lets say you have abusive user or someone is trying to DDOS your sites you can still access your own boxes.
| 12:52 am on Apr 26, 2009 (gmt 0)|
|one the advantages to a larger company is private IP address. |
Why wouldn't you have a "private" IP address if you have a dedicated server? You certainly don't need a large hosting company for that.