Performance on Azure

deals with geocoding and reverse geocoding

Performance on Azure

Postby rac » Fri Feb 17, 2017 3:49 pm


We are implementing xLocateServer on a VM scaleset on Microsoft Azure & would be interested in some recommendations so that we can achieve the best performance

- What is a reasonably safe queue length setting and maximum number of query threads for a machine with the spec of our VMs
- Initial deployment is to machine type A2 : 2 CPUs, 3.5 GB RAM, 135 GB HDD 4x500 IOPS) set to scale from 1 to 10
- Targeted deployment is to machine type D2v2 : 2 CPUs, 7GB RAM, 100GB SSD, 4x500 IOPS ) set to scale from 1 to 10

Literature on these machine sizes is available here: [url][/url]

- Are there any other config settings which we would need to modify in order to increase those settings safely without any risk of the server process running out of memory?

Many thanks for your attention
Posts: 10
Joined: Tue Sep 29, 2015 9:08 am

Re: Performance on Azure

Postby Bernd Welter » Mon Feb 20, 2017 8:38 am

Hello Rac,

I forwarded this question to DEV. I think it's challenging to answer "what is a proper config for a single instance" on a generic base. Maybe the colleagues can give you some info about how we setup our xServer INTERNET servers in Azure®.

The second question is then "how many instances do we need?".

We'll see,

best regards Bernd
Bernd Welter
Manager Technical Consulting & Requirement Engineering
Senior Technical Consultant Developer Components
PTV GROUP - Germany

Bernd at Youtube
User avatar
Bernd Welter
Site Admin
Posts: 1070
Joined: Mon Apr 14, 2014 10:28 am

Re: Performance on Azure

Postby Marco » Mon Feb 20, 2017 2:38 pm


our measurement on hosting xServer on Azure found, we got the best performance if cores and modules are equal. So I recommend two xLocate modules.
Depending on the usage, one xLocate module can use up to 2GB memory. Together with the Server process and OS usage, I also suggest only two modules for your case.

The queue length is depending on your preferred pattern. A long queue is possible and costs only a bit of memory. A good compromise between response time and rejection is a queue between 50 and 100.


Marco Schmitt
Software Developer
User avatar
Posts: 17
Joined: Wed Feb 24, 2016 12:09 pm
Location: Karlsruhe, Germany

Re: Performance on Azure

Postby rac » Tue Feb 21, 2017 8:54 am

Thank you very much Bernd & Marco.

Your (as usual) quick & helpful responses are much appreciated :-)

Posts: 10
Joined: Tue Sep 29, 2015 9:08 am

Return to PTV xLocateServer