Hello folks,
I have one server here that is starting to get overloaded thanks to a nice steady growth in traffic. (The issue is with mysql and the web application are starting to dump up against each other over disk I/O and memory usage. CPU and network performance are not issues -- yet.)
I've been thinking about getting a second server to act as the database (mysql) back end for things.
My concerns are getting ding for server-to-server bandwidth consumption and any latency involved between the front end server and the back end.
Does anyone have any experience here with such a configuration at the planet? How is it working out?
Thanks in advance,
-- Michael B.
PS. I've emailed an inquiry to sales about this.
Full Version: Back end server experience?
Would be interesting to hear from those using the new virtual private rack solution...
Yeah it should would. 
Michael,
For a few years now I've had those separated between servers - a dedicated webserver (Windows) and a dedicated database server (SQL Server). I've had no latency problems at all. I had a private rack for awhile but it was not at all necessary.
For a few years now I've had those separated between servers - a dedicated webserver (Windows) and a dedicated database server (SQL Server). I've had no latency problems at all. I had a private rack for awhile but it was not at all necessary.
Internal connectivity is pretty good. The only special request i would make is for a new machine to be in the same DC as the other if at all possible, since that will lower the cross DC latency
QUOTE (Martyn Dale @ May 20 2008, 09:13 AM) 
Internal connectivity is pretty good. The only special request i would make is for a new machine to be in the same DC as the other if at all possible, since that will lower the cross DC latency
With a solution like Virtual Rack, you can guarantee the servers are in the same data center. You can get pooled bandwidth and cross-connects to directly meet the needs of a heavily trafficked site, so it might be a great alternative to evaluate.
I recently purchased a seperate DB server and I ended up have one server in Houston and one in Dallas. Though latency is "low" (10 ms ping from one server to the other) it increased our page load times quite a bit, even with this small amount of latency. We were running about 40ms per page before and now hit about 400ms per page. To say the least, I am not happy. It is unfortnate that the virtual private racks can only be setup with new hardware. At minimum you would think you could pay extra to have your servers in the same data center but no dice there either.
QUOTE (Venti @ May 23 2008, 10:57 PM)
I recently purchased a seperate DB server and I ended up have one server in Houston and one in Dallas. Though latency is "low" (10 ms ping from one server to the other) it increased our page load times quite a bit, even with this small amount of latency. We were running about 40ms per page before and now hit about 400ms per page. To say the least, I am not happy. It is unfortnate that the virtual private racks can only be setup with new hardware. At minimum you would think you could pay extra to have your servers in the same data center but no dice there either.
Rather than complicating things for yourself, why not separate your users instead? Keep the DB and webserver part of each account together. This way if something should happen to one server, ALL your customers are not down.
With your idea of separating DB and webservers, now every query your server runs will count against your bandwidth. If you are using a control panel, by separating DB and webserver, you now have to manually(or script something) create the accounts on the DB server.
QUOTE (James Jhurani @ May 25 2008, 04:36 PM)
Rather than complicating things for yourself, why not separate your users instead? Keep the DB and webserver part of each account together. This way if something should happen to one server, ALL your customers are not down.
With your idea of separating DB and webservers, now every query your server runs will count against your bandwidth. If you are using a control panel, by separating DB and webserver, you now have to manually(or script something) create the accounts on the DB server.
With your idea of separating DB and webservers, now every query your server runs will count against your bandwidth. If you are using a control panel, by separating DB and webserver, you now have to manually(or script something) create the accounts on the DB server.
I fail to understand how having dedicated servers for specific tasks is complicating issues? Every web company I have ever worked for uses this type of setup. The only difference is they use a private rack so the latency isn't an issue (I had no idea the latency would be this poor or I wouldn't have done it). Infact, the new virtual rack product is for this exact type of setup... Having dedicared servers for specific tasks (mail servers, web servers, db servers, application servers) is more flexible/scalable long term. It also has the benefit of using specific hardware for each task (ex. faster disk for a db server, more cpu but not a lot of disk speed for an application server, etc..). If I were to go this route you suggest, I would need to then replicate the databases and sync the files which would then encounter the same latency issues (admittedly less often). However, I do agree duplication should be done to prevent the sites from going down completely.
Well the problem is we dont even know in which datacenter a server gets when you order. It doesnt show anywhere pre order or post order. Thats bad, some people prefer to maintain all their servers in a specific datacenter. Also The Planet seems to the only provider that still charges for internal bandwidth.
Not to mention some people like to have their servers located in different data centers belonging to The Planet, for redundancy.
Keep in mind, this is just my personal opinion.
So your justification for using this particular setup is, everyone else is doing it?
(assuming you use a control panel) Your control panel which previously took care of all account creation/termination now only does half the job. You will also now have to use nis or some form of authentication to allow your accounts to be consistent across both servers. You will also run into latency issues(which you have already brought up). What you describe as flexability, to some, may be complication.
If you do not use a control panel, then it should be no more complicated than simply setting up NIS, or some kind of authentication method.
MySQL is quite customizable. You can easily make a disk IO intensive query run using more RAM, and alleviate quite a bit of IO. It will always be a trade off for resources between CPU, Disk IO, and RAM. Specializing each box would be no different than having 2 boxes equally using their resources.
Why would you need database replication? I simply meant splitting your customers up entirely. half the users/webservers/db's on one server. Then the rest of the users/webservers/db's on the other. This alleviates the latency problem, eliminates the need for virtual rack, and as long as you are not overselling the boxes, should be perfectly fine resource-wise.
It would even allow you to create backups on each of the servers.
QUOTE (Venti @ May 25 2008, 07:45 PM)
I fail to understand how having dedicated servers for specific tasks is complicating issues? Every web company I have ever worked for uses this type of setup. The only difference is they use a private rack so the latency isn't an issue (I had no idea the latency would be this poor or I wouldn't have done it). Infact, the new virtual rack product is for this exact type of setup... Having dedicared servers for specific tasks (mail servers, web servers, db servers, application servers) is more flexible/scalable long term.
So your justification for using this particular setup is, everyone else is doing it?
(assuming you use a control panel) Your control panel which previously took care of all account creation/termination now only does half the job. You will also now have to use nis or some form of authentication to allow your accounts to be consistent across both servers. You will also run into latency issues(which you have already brought up). What you describe as flexability, to some, may be complication.
If you do not use a control panel, then it should be no more complicated than simply setting up NIS, or some kind of authentication method.
QUOTE (Venti @ May 25 2008, 07:45 PM)
It also has the benefit of using specific hardware for each task (ex. faster disk for a db server, more cpu but not a lot of disk speed for an application server, etc..).
MySQL is quite customizable. You can easily make a disk IO intensive query run using more RAM, and alleviate quite a bit of IO. It will always be a trade off for resources between CPU, Disk IO, and RAM. Specializing each box would be no different than having 2 boxes equally using their resources.
QUOTE (Venti @ May 25 2008, 07:45 PM)
If I were to go this route you suggest, I would need to then replicate the databases and sync the files which would then encounter the same latency issues (admittedly less often). However, I do agree duplication should be done to prevent the sites from going down completely.
Why would you need database replication? I simply meant splitting your customers up entirely. half the users/webservers/db's on one server. Then the rest of the users/webservers/db's on the other. This alleviates the latency problem, eliminates the need for virtual rack, and as long as you are not overselling the boxes, should be perfectly fine resource-wise.
It would even allow you to create backups on each of the servers.
QUOTE (James Jhurani @ May 26 2008, 02:14 PM)
Keep in mind, this is just my personal opinion.
So your justification for using this particular setup is, everyone else is doing it?
(assuming you use a control panel) Your control panel which previously took care of all account creation/termination now only does half the job. You will also now have to use nis or some form of authentication to allow your accounts to be consistent across both servers. You will also run into latency issues(which you have already brought up). What you describe as flexability, to some, may be complication.
If you do not use a control panel, then it should be no more complicated than simply setting up NIS, or some kind of authentication method.
MySQL is quite customizable. You can easily make a disk IO intensive query run using more RAM, and alleviate quite a bit of IO. It will always be a trade off for resources between CPU, Disk IO, and RAM. Specializing each box would be no different than having 2 boxes equally using their resources.
Why would you need database replication? I simply meant splitting your customers up entirely. half the users/webservers/db's on one server. Then the rest of the users/webservers/db's on the other. This alleviates the latency problem, eliminates the need for virtual rack, and as long as you are not overselling the boxes, should be perfectly fine resource-wise.
It would even allow you to create backups on each of the servers.
So your justification for using this particular setup is, everyone else is doing it?
(assuming you use a control panel) Your control panel which previously took care of all account creation/termination now only does half the job. You will also now have to use nis or some form of authentication to allow your accounts to be consistent across both servers. You will also run into latency issues(which you have already brought up). What you describe as flexability, to some, may be complication.
If you do not use a control panel, then it should be no more complicated than simply setting up NIS, or some kind of authentication method.
MySQL is quite customizable. You can easily make a disk IO intensive query run using more RAM, and alleviate quite a bit of IO. It will always be a trade off for resources between CPU, Disk IO, and RAM. Specializing each box would be no different than having 2 boxes equally using their resources.
Why would you need database replication? I simply meant splitting your customers up entirely. half the users/webservers/db's on one server. Then the rest of the users/webservers/db's on the other. This alleviates the latency problem, eliminates the need for virtual rack, and as long as you are not overselling the boxes, should be perfectly fine resource-wise.
It would even allow you to create backups on each of the servers.
We do not run any control panels and all the servers we have are for a single large website. My justification is need for scalability in the future for separate tasks (we need way more db resources than web or app resources. so having 10 web/app/db/mail servers in the future would complicate things WAY more than having 2 web/app servers, 7 db servers, and 1 mail server), ability to use specialized hardware to serve pages in less than 50ms (with a 50gb relational database), keep all the data and files synced at any given point in time so each end user has the same experience, not have to buy a software license for every task for every server, etc..
Yes, MySQL is very customizable (which we use) however real world performance on a 50gb database (and growing) on 7.2k drives vs a 15k drives will be quite different no matter how much you tweak it. So rather than getting 10 top of the line in every respect servers to handle the db/web/mail/app resource issues, we will go the route of having tailored hardware for each task. We dont need 4 cpus for DB servers but we do for the app servers. We dont need 15k drives in the app servers but we do in the db servers, and so on..
We need database replication to sync the website data... unless you want some people seeing some data while others do not see it.
QUOTE (nibb @ May 26 2008, 11:40 AM)
Well the problem is we dont even know in which datacenter a server gets when you order. It doesnt show anywhere pre order or post order. Thats bad, some people prefer to maintain all their servers in a specific datacenter. Also The Planet seems to the only provider that still charges for internal bandwidth.
Not true, i know a few places that still charge for internal bandwith, its not as uncommon as you think
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.