7

We have problems deploying Sitecore update packages to our servers. Using Sitecore Update package wizard in a local machine to deploy master update package takes about 70-90 seconds, but in the development server, it takes 7 minutes at least, and in the production server, it could take more than 10 minutes getting a timeout sometimes.

We are concerned about so huge difference in time between our local machines and our servers, in consequence our deploy times take more time than desired, and we would like to reduce it.

Our Update package is small, it contains about 2200 items, its size is 5500 kb. We don't have large media items.

Our development/production servers are in Azure as a virtual machine and we use Azure Sql Database. We have been monitoring them while deploying update package and all resources are far from max capacity, CPU of VM is always under 30%, it has a lot of free RAM, hard disk I/O are low, network is low too and database DTU is around 20%. Our current Sitecore Version is 8.0 rev 1 50621

Any idea why is take so much time to deploy the update packages in our servers? Someone using azure as infrastructure has faster update packages than us?

Update

We've been done several tests in azure, with different service tiers. We have tested With S2, S3, and P4 Azure Sql database and there is no difference in time between them.

Our DB Team has checked Database all it seems Ok, monitoring it they have seen that Sitecore opens two connections to Database and most of the time while Sitecore is doing deployment they are in awaiting command. As I said the VM is not out of resources. We have calculated that for our update package deploy Sitecore performs about 200.000 operations to Database (insert, deletes, updates,..).

We are starting to think about network latency problems, doing so many operations to the database if latency is not very low could take some time.

Thanks!

Improve this question
1

2 Answers 2

Reset to default
7

Make sure that your Azure SQL is running on the latest V12 version.

Since you're using Sitecore 8.0 update-4 it would suggest you maybe set these servers up a while ago, so there is the possibility that you created the databses on the older V11 version of the SQL Azure platform. You can check by logging into the portal and checking the databases.

SQL Azure Version

You can also running the following SQL statement against the database:

SELECT 
  SERVERPROPERTY('ProductVersion') AS ProductVersion
GO

We noticed a big difference in performance between the 2 versions and solved a number of performance issues in our site when we moved across to SQL Azure V12.

You also mention you are using Standard S2 size. I would recommend that you use Premium P1, but at a minimum would recommend Standard S3. Of course this all depends on your site, traffic, patterns etc but that would be my general recommendation.

Improve this answer
4
  • Hi @Jammykam, The database is a V12. We have updated our Azure Sql Database to P4, and there is not improvement in update packages deploy. We are going to check database fragmentation, indexs,.. if it helps to improve time execution.. Thanks!
    – Marc Cals
    Commented Mar 17, 2017 at 7:31
  • @MarcCals P4 might be a bit extreme (and expensive). It's worth double checking that the database and VM servers are in the exact same datacentre. You can also test the database performance - this script requires a slight modification to work with SQL Azure/Sitecore 8, it's a very simple change that you should be able to figure out when you run it.
    – jammykam
    Commented Mar 17, 2017 at 11:02
  • We've done the test and all them are under the boundary time. The test compared in our local machine is 7 time slower, but it fits under the boundary limits. We start to think that there is not much room for improvement, it's a sitecore limit that we can not improve.
    – Marc Cals
    Commented Mar 17, 2017 at 12:42
  • It's not a Sitecore limit, it's an issue of latency... well, also partly Sitecore due to heavy database operations.
    – jammykam
    Commented Mar 17, 2017 at 13:31
6

I have seen similar slow-downs in Azure talking to Azure SQL. It seems to be related to the number of database calls made by the installation wizard and general network latency. When you execute locally, you eliminate all of that chatter back and forth.

We ran into extreme performance issues when the Azure SQL had georeplication and we discovered we were connecting to the alternate region (e.g. an East US Sitecore instance connecting to the West US Azure SQL). If you can keep things within the same region, that speeds things up to a manageable level.

Improve this answer
2
  • Hi, I've checked and we don't have geo-replication in our database, and the virtual machine and azure sql database are in the same region. From your point of view about 10 minutes to deploy 2200 items is a normal performance in Azure? The database is Standard:S2. Thanks for your help.
    – Marc Cals
    Commented Mar 16, 2017 at 14:01
  • 10 minutes for 2200 items doesn't seem too unreasonable to me. Check the Azure SQL as mentioned above but otherwise just know that there are some Sitecore operations that are very SQL heavy that will execute a bit slower on Azure SQL.
    – sestocker
    Commented Mar 17, 2017 at 0:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.