• Blog
  • Info Support
  • Career
  • Training
  • International Group
  • Info Support
  • Blog
  • Career
  • Training
  • International Group
  • Search
logo InfoSupport
  • Latest blogs
  • Popular blogs
  • Experts
      • All
      • Bloggers
      • Speakers
  • Meet us
  • About us
    • nl
    • en
    • .NET
    • 3D printing
    • Advanced Analytics
    • Agile
    • Akka
    • Alexa
    • Algorithms
    • Api's
    • Architectuur
    • Artificial Intelligence
    • ATDD
    • Augmented Reality
    • AWS
    • Azure
    • Big Data
    • Blockchain
    • Business Intelligence
    • Chatbots
    • Cloud
    • Code Combat
    • Cognitive Services
    • Communicatie
    • Containers
    • Continuous Delivery
    • CQRS
    • Cyber Security
    • Dapr
    • Data
    • Data & Analystics
    • Data Science
    • Data Warehousing
    • Databricks
    • DataOps
    • Developers life
    • DevOps
    • Digital Days
    • Digital Twin
    • Docker
    • eHealth
    • Enterprise Architecture
    • Event Sourcing
    • Hacking
    • Infrastructure & Hosting
    • Innovatie
    • Integration
    • Internet of Things
    • Java
    • Machine Learning
    • Microservices
    • Microsoft
    • Microsoft Bot Framework
    • Microsoft Data Platform
    • Mobile Development
    • Mutation Testing
    • Open source
    • Pepper
    • Power BI
    • Privacy & Ethiek
    • Python
    • Quality Assistance & Test
    • Quality Assurance & Test
    • Requirements Management
    • Scala
    • Scratch
    • Security
    • SharePoint
    • Software Architecture
    • Software development
    • Software Factory
    • SQL Server
    • SSL
    • Start-up
    • Startup thinking
    • Stryker
    • Test Quality
    • Testing
    • TLS
    • TypeScript
    • Various
    • Web Development
    • Web-scale IT
    • Xamarin
    • All
    • Bloggers
    • Speakers
Home » Using Azure CDN to extend Bing Maps
  • Using Azure CDN to extend Bing Maps

    • By Erik Oppedijk
    • Cloud 12 years ago
    • Cloud 0 comments
    • Cloud Cloud
    Using Azure CDN to extend Bing Maps

    Update(2) 23-dec-2010: You don’t have to pay for CDN storage, but the CDN storage isn’t guaranteed to be filled, it could be emptied based on multiple factors(see understandbilling and open “understand the Current charges”).

    The Content Delivery Network (CDN) is a nice Windows Azure feature which will help us deliver content across the globe. This is ideal for mostly static content, which needs the fastest possible access/download. The CDN network currently consists of 24 Edge servers, delivering the content to your end users.

    But what are the extra costs of using a CDN, compared to the normal blob storage. First let’s have a look at the scenario, I’ve created an additional layer for Bing Maps, showing some extra charts with nautical navigation information. For every zoom level in Bing Maps I need images, but the detailed zoom levels will take several GB of data (or even TB for all the charts of the world). Here is a screenshot with the navigation charts overlaid on the Bing roads on the left and some Bing Satellite on the right:

    With MapCruncher I made several layers (limited to zoom level 10 in Bing Maps) and uploaded them to the cloud to my blob storage container.

    If most of your user are all from the same region, we can store our content in the Azure storage blob in the datacenter you choose during the creation of your storage, so it will be in Amsterdam if you choose Region West Europe. For more performance, we need more places to store our content.

    So let’s do some calculations on the cost of this solution(use the azure roi calculator for some calculations), and start with some assumptions:

    1. The map consist of 100.000 files, each file is around 60KB, so total storage is 6GB
    2. 200 visitors a day, each querying 1000 files * 30 days is 6 Million transactions/downloads per month
    3. 6 Million downloads * 60KB = 360 GB of traffic each month
    4. No updates to the data are made
    5. Just to calculate for the future, I use 26 CDN locations (only 24 available at this moment)

    Scenario 1

    Normal Windows Azure blob storage in Europe West, users from all over the world connect to this location. All content is stored in a single blob. Users around the world will have some delays as the content is served.

    Total cost:

    6GB of blob storage used in a month 6GB * $0.15 = $0.90
    6 Million downloads a month 6M / 10K * $0.01 = $6
    360 GB of bandwidth every month 360GB * $0.15 = $54

    ===

    $60.90 per month

    Scenario 2

    Store a copy in each of the 6 Windows Azure locations (2x Asia, 2x Europe and 2x US), this will give an increase for users near 1 of the locations, however Australia and other countries still might suffer. This solution needs 6 blob storage, so we manually have to keep all 6 blob storage in sync.
    360 GB of bandwidth, assume 1/3 of all bandwidth is in Asia, at higher costs per GB download.

    Total cost:

    6 datacenters each with 6 GB of storage 6 * 6GB * $0.15 = $5.40
    6 million downloads a month 6M / 10K * $0.01 = $6
    240 GB of bandwidth in Europe/US 240GB * $0.15 = $36
    120 GB of bandwidth in Asia 120GB * $0.20 = $24

    ===

    $71.40 per month

    Scenario 3A

    Again store everything in 1 location, and enable the CDN network. Now we have 26 CDN nodes delivering the content to us. Remember that all nodes need to download the data once, before they can cache it. Also the CDN will check every 2 days if there is a change to the cached files(this is the default), so a connection is made. For this scenario we’ll do some worst case thinking, that all users access all 26 CDN centers AND the CDNs download ALL content.

    Assume all data is kept in cache on each CDN server (assume 26 CDN datacenters,  6GB each)
    Assume each CDN is completely filled during the month (this is worst case, normally over time each CDN will fill up)
    CDN checks every 2 days if the data has changed(so 100.000 files, are checked 30/2 = 15 times each month = 1.5 Million transactions)

    Total cost (worst case scenario):

    6GB of blob storage used in a month 6GB * $0.15 = $0.90 for storage
    6 million downloads a month 6M / 10K * $0.01 = $6
    240 GB of bandwidth in Europe/US 240GB * $0.15 = $36
    120 GB of bandwidth in Asia 120GB * $0.20 = $24
    26 CDN locations check every 2 days for changes for 100.000 files 26 * 30/2 *  100.000 / 10K * $0.01 = $39
    26 CDN locations need to download 6GB of data 26 * 6GB * $0.15 = $23.4 (first month only)
    26 CDN locations each with 6GB of storage 26 * 6GB * $0.15 = $23.40

    ===

    $129.30 152,70 per month (first month, after CDN is filled this will drop to $105.90 129.30)

    Scenario 3B

    Same as scenario 3A, except that the CDN network only checks once a month if there is new content. This will only work with relatively static content, or move new data to a new blob container or new filename and start caching again (at extra download costs)

    Total cost:

    6GB of blob storage used in a month 6GB * $0.15 = $0.90 for storage
    6 million downloads a month 6M / 10K * $0.01 = $6
    240 GB of bandwidth in Europe/US 240GB * $0.15 = $36
    120 GB of bandwidth in Asia 120GB * $0.20 = $24
    26 CDN locations check once a month for changes for 100.000 files 26 * 1 *  100.000 / 10K * $0.01 = $2.60
    26 CDN locations need to download 6GB of data 26 * 6GB * $0.15 = $23.4 (first month only)
    26 CDN locations each with 6GB of storage 26 * 6GB * $0.15 = $23.40

    ===
    $92.90 116,30 per month (first month, after CDN is filled this will drop to $69.50 92.90)

    Scenario 4

    Same as scenario 3B, but lets assume the users from the CDN don’t access all the content, each CDN has an average of 2GB of storage(33.333 files). Now the individual CDN servers don’t need as much transactions to check if the content was modified. Over time the CDN would fill up with more data and the cost could increase over time.

    Total cost (normal scenario):

    6GB of blob storage used in a month 6GB * $0.15 = $0.90 for storage
    6 million downloads a month 6M / 10K * $0.01 = $6
    240 GB of bandwidth in Europe/US 240GB * $0.15 = $36
    120 GB of bandwidth in Asia 120GB * $0.20 = $24
    26 CDN locations check once a month for changes for 33.333 files 26 * 1 *  33.333 / 10K * $0.01 = $0.86
    26 CDN locations need to download 2GB of data 26 * 2GB * $0.15 = $7.80 (first month only)
    26 CDN locations each with 2GB of storage 26 * 2GB * $0.15 = $7.80

    ===
    $75.56 83.36 per month (first month, after CDN is filled this will drop to $67.76 75.56)

    Conclusion

    With the CDN we can quickly deliver content to our customers, but there is still some guesswork to be made. The worst case scenario (3A) is about 2.5 2 times the price of the simple blob storage (scenario 1), but we get a lot of edge servers delivering our content very fast. The slower growth example (4) is around 25%  more expensive compared to scenario 1 and looks more interesting and the price is about the same as scenario 2. But keep in mind that if your service gets popular all around the world, the cost will rise to scenario 3B or even more!

    By caching items longer (scenario 3A versus 3B) we’re saving $36.40 a month in transaction costs! This really pays out. Only think about an update scenario when your content changes a lot. Upload everything in new files, or start a new public blob container as a new cache.

    You can test the overlays, so lets hope my demo Azure account I got from MS keeps working a few more week!

    Other considerations

    If the content would change more often, the CDN would clear old items and save some storage costs.
    Most of the costs are into bandwidth, so make sure your content is cached correctly. Set the CacheControl of all the items in your blob container to “public, max-age=7200” or longer to get the files cached at the client and downstream proxy servers. With returning customers this will save a lot in bandwidth.

    More information

    Understanding Billing
    About the Windows Azure CDN
    Azure ROI Calculator
    NOAA Charts of the US
    MapCruncher
    Bing Maps Quad Key coordinate system

    Cache control at CDN

    Availability of content in the Azure CDN’s local caches (often called “cache efficacy” or “offload”) is nondeterministic but has general behaviors that developers should understand. Availability of content in cache is influenced by multiple factors including:

    • Expiration (“max-age”) header values
    • Overall total size of the developer’s content library (how much could be cached)
    • Active working set (how much is currently cached)
    • Traffic (how much is being served)
    • Cache churn (how often are objects being added to cache, or aging out)

    For example, a developer with a large (“wide”) library with high churn and high traffic will have less cache efficacy than other users, because cache turnover is higher, so objects will be swapped in and out more frequently. Thus, this developer’s overall Windows Azure Storage data transfer charges will be proportionally higher, since more origin requests are required; the overall end-user experience will be also be slightly slower on average since fewer requests are served from cache.

    The main cost control for developers to affect cache efficacy is the “max-age” HTTP header. Longer max-age headers allow the CDN to hold objects longer, reducing the need to make origin requests. Please refer to Windows Azure Storage documentation on MSDN for details.

    Share this

Erik Oppedijk

View profile

Related IT training

Go to training website

Related Consultancy solutions

Go to infosupport.com

Related blogs

  • Interpreteerbare AI als oplossing voor het Black Box Pr…

    Interpreteerbare AI als oplossing voor het Black Box Pr… Emiel Stoelinga - 1 year ago

  • Interpreteerbare AI als oplossing voor het Black Box Pr…

    Interpreteerbare AI als oplossing voor het Black Box Pr… Emiel Stoelinga - 1 year ago

  • Hosting your own WinGet private repository

    Hosting your own WinGet private repository Léon Bouquiet - 1 year ago

Data Discovery Channel

  • Explainable AI - Break open the blackbox

  • Toekomstvaste microservice data architecturen

  • Modern Data Platform

Nieuwsbrief

* verplichte velden

Contact

  • Head office NL
  • Kruisboog 42
  • 3905 TG Veenendaal
  • T +31 318 552020
  • Call
  • Mail
  • Directions
  • Head office BE
  • Generaal De Wittelaan 17
  • bus 30 2800 Mechelen
  • T +32 15 286370
  • Call
  • Mail
  • Directions

Follow us

  • Twitter
  • Facebook
  • Linkedin
  • Youtube

Newsletter

Sign in

Extra

  • Media Library
  • Disclaimer
  • Algemene voorwaarden
  • ISHBS Webmail
  • Extranet
Beheer cookie toestemming
Deze website maakt gebruik van Functionele en Analytische cookies voor website optimalisatie en statistieken.
Functioneel Always active
De technische opslag of toegang is strikt noodzakelijk voor het legitieme doel het gebruik mogelijk te maken van een specifieke dienst waarom de abonnee of gebruiker uitdrukkelijk heeft gevraagd, of met als enig doel de uitvoering van de transmissie van een communicatie over een elektronisch communicatienetwerk.
Voorkeuren
De technische opslag of toegang is noodzakelijk voor het legitieme doel voorkeuren op te slaan die niet door de abonnee of gebruiker zijn aangevraagd.
Statistieken
De technische opslag of toegang die uitsluitend voor statistische doeleinden wordt gebruikt. De technische opslag of toegang die uitsluitend wordt gebruikt voor anonieme statistische doeleinden. Zonder dagvaarding, vrijwillige naleving door uw Internet Service Provider, of aanvullende gegevens van een derde partij, kan informatie die alleen voor dit doel wordt opgeslagen of opgehaald gewoonlijk niet worden gebruikt om je te identificeren.
Marketing
De technische opslag of toegang is nodig om gebruikersprofielen op te stellen voor het verzenden van reclame, of om de gebruiker op een website of over verschillende websites te volgen voor soortgelijke marketingdoeleinden.
Manage options Manage services Manage vendors Read more about these purposes
Voorkeuren
{title} {title} {title}