We have set up a SQL sever database that serves as the back end for an Access front end.

We have users in Australia (NSW, Victoria and SA) and in Batam, Indonesia.

All Australian users have acceptable access speeds, but the users in Batam, Indonesia are experiencing severe slowdowns, even on a clear 12meg duplex connection.

Please advise how we may resolve this so our Indonesian users have the same access speed as our Australian users.

Hi,

In what region is your database located?

You can use this page to test the latency from each of your users' locations to all of the Azure data centers.

--------------------------------------------
Guy Glantser
SQL Server Consultant & Instructor
Madeira - SQL Server Services
http://www.madeirasql.com

• Edited by Guy GlantserMVP 2 hours 34 minutes ago

Hi,

In what region is your database located?

You can use this page to test the latency from each of your users' locations to all of the Azure data centers.

--------------------------------------------
Guy Glantser
SQL Server Consultant & Instructor
Madeira - SQL Server Services
http://www.madeirasql.com

• Edited by Guy GlantserMVP 2 hours 25 minutes ago

Hi Guy,

Database is located Australia East according to my Azure profile.

At the moment, I am actually getting faster ping times out of SE Asia (currently in our Melbourne office).

Have requested our Batam site to run test as well.

What do you advise best way to improve access speeds?

Happy to move the DB for faster speed, or to set up a replication, but not sure how to go about this with Azure.

Thanks for prompt response.

Regards,

Nigel

Hi,

In what region is your database located?

You can use this page to test the latency from each of your users' locations to all of the Azure data centers.

--------------------------------------------
Guy Glantser
SQL Server Consultant & Instructor
Madeira - SQL Server Services
http://www.madeirasql.com

• Edited by Guy GlantserMVP Tuesday, April 21, 2015 4:41 AM

Hi,

In what region is your database located?

You can use this page to test the latency from each of your users' locations to all of the Azure data centers.

--------------------------------------------
Guy Glantser
SQL Server Consultant & Instructor
Madeira - SQL Server Services
http://www.madeirasql.com

• Edited by Guy GlantserMVP Tuesday, April 21, 2015 4:41 AM

Hi,

In what region is your database located?

You can use this page to test the latency from each of your users' locations to all of the Azure data centers.

--------------------------------------------
Guy Glantser
SQL Server Consultant & Instructor
Madeira - SQL Server Services
http://www.madeirasql.com

• Edited by Guy GlantserMVP Tuesday, April 21, 2015 4:41 AM

Hi,

In what region is your database located?

You can use this page to test the latency from each of your users' locations to all of the Azure data centers.

--------------------------------------------
Guy Glantser
SQL Server Consultant & Instructor
Madeira - SQL Server Services
http://www.madeirasql.com

• Edited by Guy GlantserMVP Tuesday, April 21, 2015 4:41 AM

Hello Nigel,

It is best practice is to chose the region that is closes to you. In your case Australia seems the right choice.

We have however seen cases where the routing of the packages to the datacenters is not optimal. You might want to try to run a traceroute to see what route your packages take the datacenter. Depending on the outcome maybe a different region offers better ping latency.

Thanks,

Jan

• Proposed as answer by Casey KarstMicrosoft employee, Moderator 11 hours 12 minutes ago
• Unproposed as answer by Nigel George2 9 hours 9 minutes ago

Hello Nigel,

It is best practice is to chose the region that is closes to you. In your case Australia seems the right choice.

We have however seen cases where the routing of the packages to the datacenters is not optimal. You might want to try to run a traceroute to see what route your packages take the datacenter. Depending on the outcome maybe a different region offers better ping latency.

Thanks,

Jan

• Proposed as answer by Casey KarstMicrosoft employee, Moderator 11 hours 2 minutes ago
• Unproposed as answer by Nigel George2 9 hours 0 minutes ago

Hello Nigel,

It is best practice is to chose the region that is closes to you. In your case Australia seems the right choice.

We have however seen cases where the routing of the packages to the datacenters is not optimal. You might want to try to run a traceroute to see what route your packages take the datacenter. Depending on the outcome maybe a different region offers better ping latency.

Thanks,

Jan

• Proposed as answer by Casey KarstMicrosoft employee, Moderator Tuesday, April 21, 2015 8:05 PM
• Unproposed as answer by Nigel George2 Tuesday, April 21, 2015 10:08 PM

Hello Nigel,

It is best practice is to chose the region that is closes to you. In your case Australia seems the right choice.

We have however seen cases where the routing of the packages to the datacenters is not optimal. You might want to try to run a traceroute to see what route your packages take the datacenter. Depending on the outcome maybe a different region offers better ping latency.

Thanks,

Jan

• Proposed as answer by Casey KarstMicrosoft employee, Moderator Tuesday, April 21, 2015 8:05 PM
• Unproposed as answer by Nigel George2 Tuesday, April 21, 2015 10:08 PM

Hello Nigel,

It is best practice is to chose the region that is closes to you. In your case Australia seems the right choice.

We have however seen cases where the routing of the packages to the datacenters is not optimal. You might want to try to run a traceroute to see what route your packages take the datacenter. Depending on the outcome maybe a different region offers better ping latency.

Thanks,

Jan

• Proposed as answer by Casey KarstMicrosoft employee, Moderator Tuesday, April 21, 2015 8:05 PM
• Unproposed as answer by Nigel George2 Tuesday, April 21, 2015 10:08 PM

Hello Nigel,

It is best practice is to chose the region that is closes to you. In your case Australia seems the right choice.

We have however seen cases where the routing of the packages to the datacenters is not optimal. You might want to try to run a traceroute to see what route your packages take the datacenter. Depending on the outcome maybe a different region offers better ping latency.

Thanks,

Jan

• Proposed as answer by Casey KarstMicrosoft employee, Moderator Tuesday, April 21, 2015 8:05 PM
• Unproposed as answer by Nigel George2 Tuesday, April 21, 2015 10:08 PM

Thanks Jan,

I am still waiting for the results from our Indonesia site for the Azure speed test suggested by Guy. This will give me a better understanding of the lowest latency datecentre for all sites.

So to refine my question:

Is picking the server with the lowest latency for all sites the only option I have to maximise the speed of the client?

Take into account that I have already optimised queries, indexes etc with SQL server and I am not able to run a local replication server.

I looked at geo-replication in Azure, but that seems to be read-only secondaries. Happy to be corrected here - I have not had any experience with replication servers.

Regards,

Nigel

Hi Nigel,

It is correct that the geo-replication only offers readable secondaries (in the Premium service tiers). If your workload is mostly reads with occasional writes, you can consider having local secondaries for the read queries and perform the writes into the central primary DB.

One other thing you could look into is to shard the data, if the application and dataset allows this: http://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-get-started/

However if you cannot split up the data and all your sites require constant write access and operate on the same dataset, I believe it comes down to running a single DB in the 'optimal' location.

Hope that helps,

Jan

• Marked as answer by Nigel George2 7 hours 52 minutes ago

Hi Nigel,

It is correct that the geo-replication only offers readable secondaries (in the Premium service tiers). If your workload is mostly reads with occasional writes, you can consider having local secondaries for the read queries and perform the writes into the central primary DB.

One other thing you could look into is to shard the data, if the application and dataset allows this: http://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-get-started/

However if you cannot split up the data and all your sites require constant write access and operate on the same dataset, I believe it comes down to running a single DB in the 'optimal' location.

Hope that helps,

Jan

• Marked as answer by Nigel George2 7 hours 42 minutes ago

Thank you Jan,

Much appreciated.

Looks like short term optimal server location is way to go. Will wait for feedback on latency numbers from our Indo site and go from there.

Never heard of sharding - a day you learn something new is a good day! :)

Cheers,

Nigel

Hi Nigel,

It is correct that the geo-replication only offers readable secondaries (in the Premium service tiers). If your workload is mostly reads with occasional writes, you can consider having local secondaries for the read queries and perform the writes into the central primary DB.

One other thing you could look into is to shard the data, if the application and dataset allows this: http://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-get-started/

However if you cannot split up the data and all your sites require constant write access and operate on the same dataset, I believe it comes down to running a single DB in the 'optimal' location.

Hope that helps,

Jan

• Marked as answer by Nigel George2 Tuesday, April 21, 2015 11:26 PM

Hi Nigel,

It is correct that the geo-replication only offers readable secondaries (in the Premium service tiers). If your workload is mostly reads with occasional writes, you can consider having local secondaries for the read queries and perform the writes into the central primary DB.

One other thing you could look into is to shard the data, if the application and dataset allows this: http://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-get-started/

However if you cannot split up the data and all your sites require constant write access and operate on the same dataset, I believe it comes down to running a single DB in the 'optimal' location.

Hope that helps,

Jan

• Marked as answer by Nigel George2 Tuesday, April 21, 2015 11:26 PM

Hi Nigel,

It is correct that the geo-replication only offers readable secondaries (in the Premium service tiers). If your workload is mostly reads with occasional writes, you can consider having local secondaries for the read queries and perform the writes into the central primary DB.

One other thing you could look into is to shard the data, if the application and dataset allows this: http://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-get-started/

However if you cannot split up the data and all your sites require constant write access and operate on the same dataset, I believe it comes down to running a single DB in the 'optimal' location.

Hope that helps,

Jan

• Marked as answer by Nigel George2 Tuesday, April 21, 2015 11:26 PM

Hi Nigel,

It is correct that the geo-replication only offers readable secondaries (in the Premium service tiers). If your workload is mostly reads with occasional writes, you can consider having local secondaries for the read queries and perform the writes into the central primary DB.

One other thing you could look into is to shard the data, if the application and dataset allows this: http://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-get-started/

However if you cannot split up the data and all your sites require constant write access and operate on the same dataset, I believe it comes down to running a single DB in the 'optimal' location.

Hope that helps,

Jan

• Marked as answer by Nigel George2 Tuesday, April 21, 2015 11:26 PM