1

I try to connect with PHP to a MySql Server and it took in average 2 seconds to establish the connection.

We host our Database in Germany (Frankfurt) and the PHP-Application in Singapore.

We're hosting on AWS. Our Database Server is a RDS Multi-AZ instance (db.m4.2xlarge).

At the moment the connection is via public internet.

A solution would be to create a master/master replication for the Database, but it's not that easy on AWS and for the current usecase it's a little bit overengineered.

Is there any way to reduce the latency? Is it faster to establish the connection via a VPN?

Pawel
  • 113
  • 4
  • "We host our Database in Germany (Frankfurt) and the PHP-Application in Singapore." WHY? – ceejayoz Nov 14 '16 at 13:06
  • It was a quck fix, because we need to be available with our site in china as quick as possible and the latency from china to singapor is better then from china to Germany. Our main business is in europe and for that reason the database is in Germany. All other services like redis, varnish, Loadbalancer etc. are in Singapore, too. But at the moment we need a centralized Database – Pawel Nov 14 '16 at 13:11
  • I guess just hosting the site from Germany would yield a better end result for your chinese customers, maybe with just the cache and LB in Singapore. – Sven Nov 14 '16 at 13:48
  • that was my first attempt and the result was even worse. – Pawel Nov 14 '16 at 13:51

1 Answers1

6

I'm going to be blunt: you've made a horrible architecture decision by having your database queries traverse the public internet. Traffic between your servers is taking perhaps the longest path possible on planet earth.

Plain and simple, short of co-locating your application and DB servers, there is nothing you can do to improve performance in any meaningful way.

EEAA
  • 109,363
  • 18
  • 175
  • 245
  • I totaly agree with the horrible architecture, but unfortunately we have to do it as a quick fix. We are working on a restructure of our infrastucture. – Pawel Nov 14 '16 at 13:11
  • 1
    Well unfortunately you're stuck. You *may* be able to shave off a couple of ms by using a VPN with compression, but that's certainly not a sure thing, and it could actually have an opposite effect by adding compression and encryption latency. The work required to build a VPN should be instead devoted to digging out from the current architecture. – EEAA Nov 14 '16 at 13:22
  • @EEAA VPN and compression generally **add** latency, rather than reduce it. – shodanshok Nov 14 '16 at 13:57
  • @shodanshok In my experience that completely depends on the nature of the data and on the capabilities of your VPN equipment. – EEAA Nov 14 '16 at 14:04
  • @EEAA for throughput, maybe. But for pure latency, it inevitably insert some additional delay (after all, packets need to be encrypted, and compression does not help with packets smaller than MTU). – shodanshok Nov 14 '16 at 14:39
  • @shodanshok Right, so it depends. Which is what I said in my comment above. – EEAA Nov 14 '16 at 14:40