locked
Migration tips for MVC app using LINQ to SQL, retry logic, etc. RRS feed

  • Question

  • I have an existing ASP .NET MVC application hosted on a VPS with IIS and SQL Express both running on the one VPS.  I am outgrowing this configuration and am considering either migrating to a separate VPS running SQL or SQL Azure.  I would keep IIS on the VPS (not migrate the MVC app to Azure).

    Based on initial research, it sounds like having a robust strategy for retries at the data access layer is critical to success in implementing SQL Azure.  I would expect this would be even more critical in my scenario where IIS lives outside of the Azure datacenter.

    I've seen some blog posts and general guidance for implementing retry logic, but nothing specific to LINQ to SQL. 

    Also if you think this path is going to be fruitless and I am nuts to be considering this type of migration (IIS outside of the Azure infrastructure, migrating an existing LINQ to SQL app), please let me know.  I saw a comment from an MVP on another thread where he said "One thing to note here: SQL Azure is not really designed/optimized for classical 2-tier scenarios (where the clients live outside the Azure data center). "

     

     

    Thursday, January 6, 2011 10:14 PM

Answers

  • Hi Pat,

    As I understand, your application is running on premise and want to consume Sql Azure. Based on my knowledge, this is not a good solution. The network connection between sqlazure and your local application would be critical to your app's performance, besides, the price of Sql azure is not cheap. It's better to use local Sql server express which has more reliable connection, faster connection speed and free of price.

    Thanks,


    Mog Liang
    • Proposed as answer by Patriek van Dorp Monday, January 10, 2011 11:43 AM
    • Marked as answer by Mog Liang Friday, January 14, 2011 8:41 AM
    Monday, January 10, 2011 3:39 AM

All replies

  • Hi Pat,

    As I understand, your application is running on premise and want to consume Sql Azure. Based on my knowledge, this is not a good solution. The network connection between sqlazure and your local application would be critical to your app's performance, besides, the price of Sql azure is not cheap. It's better to use local Sql server express which has more reliable connection, faster connection speed and free of price.

    Thanks,


    Mog Liang
    • Proposed as answer by Patriek van Dorp Monday, January 10, 2011 11:43 AM
    • Marked as answer by Mog Liang Friday, January 14, 2011 8:41 AM
    Monday, January 10, 2011 3:39 AM
  • Related to this, if I am running my app on premise and have data hosted in Azure Table Storage, does Table Storage have the same performance/latency problem Sql Azure would give, is that also a bad idea? 

    Beside one problem I see is that any data your on-premise app gets from Azure would be charged for the bandwidth of transferring that data in and out.  Wheraze, if you app is also hosted on Azure, that bandwidth between middle tier (your app) and data tier (azure storage) is free, only data transferred out to your visitors by your app would be ultimately charged, right?

    Monday, January 10, 2011 4:15 PM
  • if I am running my app on premise and have data hosted in Azure Table Storage, does Table Storage have the same performance/latency problem Sql Azure would give, is that also a bad idea? 

    I imagine the performance/latency problems are similar to those of SQL Azure. As to its being a bad idea that really depends on the needs of your application.

    I read somewhere recently a suggestion that remote access to SQL Azure should be avoided because TDS is not optimized for remote access.

    Monday, January 10, 2011 4:52 PM
    Answerer