Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Different physical locations between db and app servers bad idea?
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Different physical locations between db and app servers bad idea?

Say I had 3 app servers (with load balancing in place) in Las Vegas and two MySQL servers in Atlanta; how much does distance affect performance on this sort of situation? Let's assume the db servers are just running master-master so the second one is just there for HA purposes.

My gut feeling tells me this setup vs. a typical LEMP box running WordPress setup will be slower because of the latency but I don't really have a way to test this situation.

Thanks for any advice you guys can give!

Comments

  • The majority of delay is going to be the roundtrip time and how much data that needs to be transferred. I imagine something like 50-100 ms delay if your servers are located on east / west coast.

  • black said: The majority of delay is going to be the roundtrip time and how much data that needs to be transferred. I imagine something like 50-100 ms delay if your servers are located on east / west coast.

    That delay sounds reasonable, but I'm just wondering if the performance benefit of having a dedicated db server will make up for that delay. But given that amount of delay/latency, I feel for something like WordPress, the queries won't execute that much slower on a LEMP box however, I'm sure the difference is negligible.

    Now, I think I'm just splitting hairs...

  • It works, but not the best way to do it.

    You should always have 3 servers in a cluster not 2. If 1 out of 2 fails or pretends to fail there can be major problems.

    I'd get 3 - 2 in the same location as the website and 1 further away as your last backup or 1 in the same location and the other 2 in different locations.

  • Well if every mysql query suffers a 100ms delay, and the app gets busy, then there's gonna be a big queue of app processes waiting on mysql replies.

    The result I think would be elevated load on the app server and a bad user experience.

  • DomainBopDomainBop Member
    edited November 2013

    Well if every mysql query suffers a 100ms delay, and the app gets busy, then there's gonna be a big queue of app processes waiting on mysql replies.

    Another problem is when there are network problems between the app server and the database server.

    I'd recommend placing the app server in the same data center as the mysql server.

  • MrOwenMrOwen Member
    edited November 2013

    Thanks for all the suggestions, guys. I was a little leery about placing all my eggs in one basket (BuyVM) but it seems like will give the best performance by far (since they're the only ones offering internal IP addresses afaik). I guess I'm just paranoid something catastrophic will happen and everything will die at once but:

    A) I'll have stuff backed up remotely

    B) What are the chances

    C) I'm not running anything mission critical

  • bdtechbdtech Member
    edited November 2013

    The best combo I've got running is app/db with linode and front end caches with DO. 2-10ms latency too. If there's a DO network issue it drops out of the pool instantly

  • @MrOwen: I have given a lot of thought to such a setup. My take on this is that there is no point complicating things with a HA backend (i.e. DB), if not coupled with HA on the frontend (in your case Wordpress). I have been contemplating something like this:

    • a HA backend consisting of a cluster of 3 Percona/Galera DB servers;

    • a HA frontend (part I) consisting of 2 mirrored Drupal webservers;

    • a HA frontend (part II) consisting of 2 Varnish reverse proxies, with the 2 Drupal webservers as backends). Later on this will be expanded, so there is such RP pair on each continent.

    • a DNS with simple failover (i.e. multiple A records), to start with, plus geolocation functionality to direct queries to the closest RP later on.

    I'm thinking of putting two of the DB servers in the same DC's as the two Drupal webservers (each pair in a different city). So latency between each frontend/backend pair <0.5ms. The third DB server will be in a DC in another city.

    Any comments/suggestions/pointers very welcome ;)

  • @aglodek skip the xtradb cluster and just use a master slave setup if you don't need the simultaneous writes to both DC. You can always promote the slave while you're doing the ip failover.

  • Why host those servers so far away (closer the better)? But I think your current set up would be faster then a LAMP set up with wordpress on it.

  • jriderjrider Member
    edited November 2013

    Just my 2 cents.
    I have worked on / developed many high performance sites and the one thing that will kill the performance faster then anything is latency between the database and the app servers.
    If you really want true HA (99.99% uptime) then you need local fail over and disaster recovery.
    In the same datacenter, preferably with the same provider have 2 servers , each with an app server and a database. The app servers don't need to be clustered, just use DNS round robin.
    Setup the databases as master-master replication pair. Use keepalived and a virtual IP to ensure that a database is always available. App servers can be stateless and restart fast so don't worry too much about fail over. Just monitor.
    In a second datacenter, have 1 server with a app and database server setup just like the main site. Configure the database as a slave of one of the main db servers, doesn't matter which one.

    Now if either of the main servers goes down the other can pickup. If the main site dies, you can failover to the DR site.

Sign In or Register to comment.