Choosing an Azure datacenter for your service

When building a web-based service that will be used by people all around the world you also have to think about network latencies that are imposed by geographical distances. Your service itself may be very fast, but it won't matter if users on the other side of the globe will experience it with a delay of 1 second.

With Microsoft Azure, the cloud provider that we also use for all of our own services, you can choose from datacenters at different locations to run your service, thus optimizing network distance for your target audience. That is, of course, if you only want to run your service in just one datacenter and not in multiple ones to be able to reach more geographical regions on fast lines. We'll deal with the one-datacenter case in this blog post, since running a web-based service in multiple locations is neither technically simple, neither cheap, but optimizing the user experience for the intended target audience is something even the smallest applications are ought to do. So let's see how we can decide which datacenter to choose!

The methodology described here is the same we used to decide where to deploy our Orchard SaaS, DotNest.

Where are my users located?

First, you have to determine where your (intended) target audience is mostly located, since foremost you want users of your target audience to have the best user experience.

If your service is already running in some form, or you know that your target audience is the same as one of your other service's than you can consult your web analytics to get some exact anwers. This is of course not available if your service is totally new and you don't yet have experience of this sort; then it depends on your business plan to make a guess that's sufficiently educated.

For DotNest we decided that our primary audience is in West Europe and North America. This actually is quite lucky match: since there are a lot of high-speed network cables laid out under the Atlantic Ocean between the two continents (as you can see from e.g. this slightly out-of-date picture) it's actually possible to find a location that will be able to serve both sides of the big pond equally well.

Gathering the tools

OK, now we know where our users are located. But how are we going to determine which datacenter is best suited for them? We'll make some measurements!

Firstly we need to set up endpoints in all of the datacenters so we can use them to measure latency. For this we'll use Azure Web Sites: we won't deploy anything to the websites, the default page that a blank website returns will be enough, since we don't want to measure server performance but only network latency as much as possible. The websites will be just free ones, as the performance of a blank website, in our experience, doesn't differ from or vary significantly more than one on a paid tier, so it doesn't affect latency measurements.

At the time when our measurements were made less datacenters were available on Azure, so we've only made test websites for those DCs, namely the following:

You can use these endpoints for your own tests if you wish of course.

Since websites can go idle, especially the ones on the free tier, it's best if you warm them up by opening them before making any measurements.

Seondly we also need some tool to measure latency of the various endpoints from different locations. For this we've used Alertra's Spot Check tool (see the textbox on the top of the page) that can measure response times from a variety of locations. (Another interesting tool to check the latency from your current locations to all Azure datacenters is Azure Speed Test.)

Evaluating the results

So we've set up all the test sites and have the right tool to measure response times. The next step is get the numbers clear and see which location performs best.

For this purpose we've created a simple spreadsheet that you can use to evaluate the results. As you cen see we've made measurements to all of the websites with Alertra's tool and put them into a table. Then we calculated the average response times for our intended target audience's locations, namely London, Chicago, Los Angeles and Washington DC in the P column. By simply changing the function that calculates the values in that row you can see the numbers for your target audience too.

As one can see from the spreadsheet East US came out as the winner with North Central US being a close second. East US was faster than North Central US in the majority of cases and also a bit faster on average too.

While the proportion of these numbers may be accurate, take the concrete values with a grain of salt. In our experience the actual response times are much better than the ones measured by Alertra's tool. For example from Hungary, where we're located, we can get a response from DotNest within 150ms at worst for cached pages, what is much faster even than what Alertra's tool measured from London (about 500ms)

For DotNest we've gone with the East US datacenter, and so far it seems like a good decision. We've got numerous feedbacks form our users that the service is very fast.

So where are you going to put your application?

zoltan.lehoczky Azure Latency

Other recent posts

Clear Specs Go a Long Way: Inside Our Three-Year Orchard Core Collaboration with Fieldman

What happens when your application needs both stability improvements and new features at the same time?

That was the situation when Lombiq joined the Fieldman project. Their Orchard Core-based web application already had established business logic, but it required bug fixes, upgrades, and further development.

Fieldman is an American software company that helps local governments and utility vendors manage all types of assets, jobs, and field projects.

Your analytics isn’t broken. It’s incomplete.

Web analytics is the foundation of modern marketing decisions. But today, a growing portion of user behavior simply doesn’t show up in your reports.

Ad blockers, browser extensions, and privacy tools can strip tracking parameters or block analytics scripts entirely. The result is incomplete campaign data, misleading attribution, and decisions based on partial visibility.

For marketing and product teams, this is not just a technical inconvenience. It is a business risk. Campaign performance becomes harder to evaluate, budgets are harder to justify, and growth decisions rely on guesswork instead of evidence.

Bringing Orchard Core into the classroom at Óbuda University
Since 2013, we’ve been working with Óbuda University on a hands-on way to teach web development. What began as a course built around Orchard CMS later evolved into an Orchard Core-based subject, giving students a chance to learn by building something that could actually work in the real world, not just completing classroom exercises.We asked our colleague Gábor Domonkos, who has led the collaboration for years, to walk us through how the course started, how it works today, and what students usually take away from it.– How did this collaboration start?At first, the university had a Hungarian, non-developer course focused on Orchard CMS and DotNest, Lombiq’s hosted Orchard platform. Students built sites through the admin UI, which was a good introduction to content management. But once Orchard Core arrived, we saw a chance to create something more ambitious: a developer-focused subject where students could also write code and go beyond the basics.– What changed with Orchard Core?Orchard Core made the course much more flexible. Students can now learn not just how to use a CMS, but how to extend it, customize it, and build on top of it. That meant more room for customization and coding. It also gives them a much more realistic picture of what it means to develop with a modern CMS on ASP.NET Core.– How is the course structured?The semester is built around a few milestones. Early on, students choose their project topic and define the basic idea. Midway through the semester, they should already have a working site with real content. By the end, the project should be close to final, both in structure and content.The later stages are mostly about making sure students stay on track. If they need help, they can share a short update so we can spot problems early and steer them in the right direction. Some students also choose to demo their project before the official deadline.– What do students usually build? Any favorites?That depends on which version of the course they take. In the non-developer version, students often build sites with forms, search, taxonomies, and content workflows. In the developer-focused version, they go further and build custom modules, themes, and more advanced functionality.One project that stands out was a volunteer platform. Organizations could publish volunteer opportunities, and users could browse, apply, and track their enrollments. It was a nice example of how Orchard Core can support a real, practical use case without adding unnecessary complexity.– Has this led to anything beyond the course?Yes, some students later became our colleagues at Lombiq. By the time they finish the course, they already know the basics of Orchard Core and have built something real with it. More importantly, they have seen what it’s like to work with a real open-source ecosystem, not just with a classroom demo.– Where should someone start if they want to learn Orchard Core today?If someone wants to learn Orchard Core today, Lombiq has a few good starting points. Dojo Course 3 is a full video course on YouTube that walks through Orchard Core for both users and developers. We also maintain the Lombiq Training Demo for Orchard Core on GitHub, which is a functional module with heavily commented code to help developers understand how Orchard Core works in practice. And beyond that, Orchard Dojo regularly publishes tutorials, tips, and other learning resources for the Orchard community. For us, that is the best proof that the collaboration works. Students gain practical experience, the university gets a more hands-on subject, and the industry gets people who are better prepared for real projects. We believe more universities could benefit from this kind of collaboration, whether with Orchard Core or other open-source technologies. And if you are exploring something similar, we are always happy to share what has worked for us so far.

Event management backend for one of the largest retailers
Avastec, a UK company, approached us to continue the development of their existing Orchard Core-based headless backend utilized by the event management site of one of the world's largest retailers. It was already in use with a publicly accessible Node.js-based frontend. The end client urgently wanted some new features, with follow-up tasks to optimize the system's performance, and keep the app up-to-date while maintaining the integrity of the user interface. Our initial task involved the transformation of data migrations from the simpler recipe-based paradigm to a more structured code-based approach. This transition aimed to enhance the traceability of modifications the development team applied. Simultaneously, a suite of UI tests was integrated into the workflow to uphold continuous code quality assurance. Leveraging the flexibility of Orchard Core's migration API, we executed this pivotal migration process without it negatively affecting users. Since then, we've delivered a lot to meet various user requirements, including event ticketing, integrating with a GDPR compliance API, and launching the site for another brand of the end client. One particularly interesting task was the implementation of QR code-based entry management, which we also supplemented with UI tests using the Lombiq UI Testing Toolbox. We've also implemented a feature to let the app use a fake video feed during tests, what we also demoed during the weekly Orchard Core podcast. From our other open-source projects, we also utilized Lombiq Helpful Extensions, as well as Lombiq Hosting - Azure Application Insights, since the app is hosted in Azure. This is what Steve Taylor, CTO and Founder of Avastec says about our joint work: Working with this team has been a genuinely positive experience from day one. They quickly understood the complexities of our existing Orchard Core setup and delivered improvements without disrupting a live, high-traffic platform. Their ability to balance rapid feature delivery with long-term maintainability and performance has been particularly valuable. The introduction of structured migrations, robust UI testing, and innovative solutions like QR-based entry management significantly elevated the quality of the system. They’ve consistently demonstrated technical expertise, reliability, and a proactive mindset, making them a trusted partner in the ongoing evolution of our platform. Thanks to Orchard Core, UI testing, and innovative feature implementations, we effectively addressed Avastec’s challenges and delivered a significantly improved event management backend. It continues to serve the end client, with us working on improvements to this day. Do you want to launch and event management platform on Orchard Core? We have actually built several more too, get in touch with us!