[TYPE THE COMPANY NAME]

Azure Application Performance Guide

Need to check matrix

Bhonhariya, Salim(Cloud Architect)

1/9/2015

Al rights reserved

1

Contents Event Driver Messaging programming in Receiver side of Service Bus: ....................................................... 2

Azure Access Control Service (ACS) .............................................................................................................. 3

Azure Web Applications and Serialization .................................................................................................... 5

Physical location of services.......................................................................................................................... 5

New D-Series of Azure VMs with 60% Faster CPUs, More Memory and Local SSD Disks ............................ 5

Local SSD Disk and SQL Server Buffer Pool Extensions ................................................................................. 6

Pre-load required data for complex processing ........................................................................................... 7

Use batch processing .................................................................................................................................... 8

Use Asynchronous processing ...................................................................................................................... 8

SQL Azure Performance: ............................................................................................................................... 8

Scaling Out: ............................................................................................................................................... 8

Setting in SQL Azure: ............................................................................................................................... 11

Monitoring Azure SQL Database Using Dynamic Management Views ................................................... 12

Monitoring Connections ..................................................................................................................... 12

Monitoring Query Performance.......................................................................................................... 13

Monitoring Blocked Queries ............................................................................................................... 14

Monitoring Query Plans ...................................................................................................................... 14

Get SQL Profiler info from SQL Azure ................................................................................................. 14

Analysis Resources and Tools ..................................................................................................................... 17

Tracing: ........................................................................................................................................................ 17

Coming soon: .............................................................................................................................................. 20

2

Event Driver Messaging programming in Receiver side of Service Bus:

Instead of polling the queue we’ll be using the new message pump(Push). On receiver side of code.

http://fabriccontroller.net/blog/posts/introducing-the-event-driven-message-programming-model-for-the-windows-azure-service-bus/

// Build the messaging options.

var eventDrivenMessagingOptions = new OnMessageOptions();

eventDrivenMessagingOptions.AutoComplete = true;

eventDrivenMessagingOptions.ExceptionReceived += OnExceptionReceived;

eventDrivenMessagingOptions.MaxConcurrentCalls = 5;

MaxConcurrentCalls: define how many theads will be processing the queue (for

improved performance)

Avoid lazy loading of Entity Data for intense processing scenarios

If you are not careful while writing Navigational properties, EF will lazy load unnecessary data behind the scenes. For EF entities having relations, there will be chances for a developer to write like this..

public class Customer :

{

public int CustomerID { get; set; }

public int CustomerTypeId{get;set;}

//Foreign keyp

public virtual CustomerType CustomerType { get; set; }

}

This is naturally the easiest way, especially if your application need to retrieve “CustomerType: data using Customer entity. If we carefully analyze the above query, each query to Customer object, may cause the EF to lazy load “Customer entity” too. This will have an impact on performance, especially when the data becomes too heavy. In these scenarios, to increase performance, there is a way. Instead of defining “public virtual CustomerType CustomerType” define “public ICollection CustomerType CustomerType”. By using ICollection, EF stops lazy loading. And in queries you can use “Customer” object, and force the EF to use lazy loading by using “Include”

3

ie : var data = Customers.Include("CustomerEntity").ToList(). This will force EF to lazy load.

Azure Access Control Service (ACS)

The two main factors affecting ACS resource usage, and thus performance, are the token size, and encryption.

In general, the key attributes of performance are response time, throughput, and resource utilization. For example, if the application has limited resources such as memory, chances are some information will hit the file system which is much slower than in-memory operations – this will affect overall response time. Here is another example, if the application sends a large amount of data over a network with limited bandwidth, it results in slower than desired response times. One approach to solve performance issues is to add more resources such as network bandwidth, faster CPU, and more memory. This approach may help although not always. Another approach is to improve code so that it uses fewer resources and exchanges less data. Considering the context of claims aware applications and what’s under developer’s control there are a few key factors related to using ACS that affect performance, namely, tokens and cryptographic operations related to the tokens. Token size and encryption are key factors under the developer’s control that affect performance of applications integrated with ACS. Token Size. Token size affects performance in two ways. First it directly

affects performance related to network bandwidth to some degree. The larger the token the more network bandwidth it will take resulting in slower response overall. Second, the larger the token the more CPU cycles required to verify the integrity and extract claims in the token. Token processing includes parsing the token and de-serializing it into binary format so that your code can use it, the processing also includes several cryptography operations such as signature validation, and optionally decryption. The larger the token the more CPU cycles spent on its processing resulting in higher resource utilization and slower overall response. Token size depends on several factors: token format, cryptography applied to the token, and the claims in the token. ACS supports SAML, SWT, and JWT tokens. Generally a SWT or a JWTJWT token is smaller than a SAML token that carries equivalent

4

amount of information. For more information read Token Formats Supported in ACS. There is caveat though, different token formats are optimized for different protocols and application architectures. SWT Tokens are issued over WS-Federation, WS-Trust, and OAuth WRAP

or OAuth 2.0 protocols. This means that SWT tokens can be used in Web applications, WCF (SOAP) services, and WCF (REST) services. WIF does not support the SWT token handler.

SAML Tokens are issued over WS-Trust and WS-Federation protocols. This means that SAML tokens can be used in Web applications and WCF (SOAP) services. WIF supports both SAML 2.0 and SAML 1.1 tokens. Read more about WIF in the following topic Windows Identity Foundation

JWT Tokens are issued over WS-Federation, WS-Trust, and OAuth 2.0 protocols. This means that SWT tokens can be used in Web applications, WCF (SOAP) services, and WCF (REST) services. One factor that contributes most to the token size is the claims contained in the token. The more claims the token carries the larger its size. In most cases claims that come with the token are under developer’s control. The claims used by an application are added, removed, or changed by the Security Token Service (STS) such as AD FS or ACS. ACS uses rule groups and rules to add, remove or change claims in a token. For more information read Rule Groups and Rules.

Encryption. Encryption and other cryptographic operations such as signing, signature validation, and decryption directly affect performance. Cryptography operations consume computation power due to the complex algorithms involved. ACS signs all tokens issued as an integrity measure to counter tampering attacks. Signature validation of tokens is not optional. Token encryption is required if a relying party application is a web service that is not using SSL to encrypt communications. WCF-based services using SOAP require encrypted, proof-of-possession tokens with the WS-Trust protocol. Token encryption is required to protect sensitive information over an unencrypted channel. However, in cases where the communication channel is encrypted, such as using SSL encryption, then using token encryption is optional and may not be applied in favor of improved performance.

5

Azure Web Applications and Serialization

When writing applications for Azure, data serialization becomes increasingly

important when compared to writing on-premises applications. Azure

applications get charged for database use, general storage, data transfers and

caching. For more information on pricing see, Azure Pricing Overview.

Additionally Azure applications may be used from mobile devices like phones,

tablets, etc. and this can introduce latency because of their partially connected

nature. All of these factors mean it is very important to think about how your

application will send and receive data. Smaller payloads will reduce your costs for

bandwidth and storage and may help minimize latency.

The best serializer and encoder to use will depend upon your application and its interoperability needs. For scenarios where the service and client are both running under the .NET Framework consider using the binary encoder and the DataContractSerializer. For scenarios where interoperability is required, use the text encoder. In these types of scenarios the DataContractJsonSerializer will provide the smallest representation, but this requires use of a non-SOAP service. If you need to use SOAP, consider using the DataContractSerializer.

Physical location of services

If possible, co-locate different nodes or application layers within the same data center. Otherwise network latency and cost will be greater.

For example, locate the web application in the same data center as the SQL Database instance that it accesses, rather than in a different data center, or on-premises.

New D-Series of Azure VMs with 60% Faster CPUs, More Memory and Local SSD

Disks

(http://weblogs.asp.net/scottgu/new-d-series-of-azure-vms-with-60-faster-cpus-more-memory-and-local-ssd-disks)

6

Today I’m excited to announce that we just released a new set of VM sizes for Microsoft Azure. These VM sizes are now available to be used immediately by every Azure customer.

The new D-Series of VMs can be used with both Azure Virtual Machines and Azure Cloud Services. In addition to offering faster vCPUs (approximately 60% faster than our A series) and more memory (up to 112 GB), the new VM sizes also all have a local SSD disk (up to 800 GB) to enable much faster IO reads and writes.

The new VM sizes available today include the following:

General Purpose D-Series VMs

Name vCores Memory (GB) Local SSD Disk (GB)

Standard_D1 1 3.5 50

Standard_D2 2 7 100

Standard_D3 4 14 200

Standard_D4 8 28 400

High Memory D-Series VMs

Name vCores Memory (GB) Local SSD Disk (GB)

Standard_D11 2 14 100

Standard_D12 4 28 200

Standard_D13 8 56 400

Standard_D14 16 112 800

For pricing information, please see Virtual Machine Pricing Details.

Local SSD Disk and SQL Server Buffer Pool Extensions

A temporary drive on the VMs (D:\ on Windows, /mnt or /mnt/resource on Linux) is mapped to the local SSDs exposed on the D-Service VMs, and provides a really good option for replicated storage workloads, like MongoDB, or for significantly increasing the performance of SQL Server 2014 by enabling its unique Buffer Pool Extensions (BPE) feature.

7

SQL Server 2014’s Buffer Pool Extensions allows you to extend the SQL Engine Buffer Pool with the memory of local SSD disks to significantly improve the performance of SQL workloads. The Buffer Pool is a global memory resource used to cache data pages for much faster read operations. Without any code changes in your application, you can enable the buffer pool support with the SSDs of the D-Series VMs using a simple T-SQL query with just four lines:

ALTER SERVER CONFIGURATION

SET BUFFER POOL EXTENSION ON

SIZE = <size> [ KB | MB | GB ]

FILENAME = 'D:\SSDCACHE\EXAMPLE.BPE'

No code changes are required in your application, and all write operations will continue to be durably persisted in VM drives persisted in Azure Storage. More details on configuring and using BPE can be found here.

Pre-load required data for complex processing

Typically there may be chances for writing code like given below

void Process(){

//Loop stars here

var data = DBContext.Customers.ToList();

//Loop ends here

}

The problem with the above approach is that, each time the loop executes, it will query data from DB. Each time we call the .ToList() method, EF will send underlying SQL queries to db, which makes DB hits more, and in production environment, it will cause significant performance issue. To resolve this, you can follow another approach which is quite simple. Load the data to c# object and manipulate it from that object. Use Linq data manipulation from stored c# objects. SO the modified code will look like this

8

void Process(){

List<object> listData = DBContext.Customers.ToList(); //Initially load the

data, so db hit occurs only once.

//Loop starting here

var data = listData.SelectAl()...;

//Loop ending here

}

)

Use batch processing

If you application involved processing of data as well as writing to DB, then you

can make use of batch methods, which reduce DB hits

Use Asynchronous processing

If you try to call a select query to retrieve 10,000 records from an Azure SQL, you

would notice that Azure sends “selected data” asynchronously, i.e. first 1000

records, then 1000 records and so on. So for our applications listing/display data

scenarios, you can make the application behave asynchronously, makes user

experience much greater.

SQL Azure Performance:

Scaling Out:

The most dramatic performance improvements achievable in Azure applications come from the scaling out and partitioning of resources. Building scalable applications in Azure requires leveraging the scale-out of resources by their physical partitioning: SQL databases, storage, compute nodes, etc. This partitioning enables parallel execution of application tasks, and is thus the basis for high performance, because Azure has the resources of an entire data center available, and handles the physical partitioning for you. To achieve this level of overall performance requires the use of proper scale-out design patterns.

9

Ensuring maximum scalability: deciding whether, and how to partition your data.

Custom Sharding in SQL Azure and Federations in SQL Azure Database

Auto scaling the SQL Azure: By creating more instances of SQL virtual machine (Same as multiple database instance, which is similar to creating more instances of Web role or worker role)

Premium SQL AZURE, set concurrent request can be more than 180.

10

11

Setting in SQL Azure:

Verify to make sure disk Cache is none for high throughput I/0 operations in

this case.

Make sure data compression is on, compress table and indexes. That way

more data are stored on fewer pages and read I/O operations are faster.

Make sure replication of SQL Azure database is done in same region for

minimum latency.

Use SQL file groups across multiple disks instead of disk striping

Put logs, data and backup on separate disks when doing this we have to

disable geo-replication on storage account for consistency. Because

replication is done asynchronously.

The one storage account IOPS limits are 20,000 times foe 1KB message size

in our case it will be 20,000/1kb per message. Only 500 IOPS PER DISK is

allowed. If it goes more than that we have to add more storage accounts

automatically to avoid throttling in storage account. We should put a

storage throttling alert in azure to see up to what IOPS we go to using

(http://blogs.msdn.com/b/mast/archive/2014/08/02/how-to-monitor-for-

storage-account-throttling.aspx)

12

Monitoring Azure SQL Database Using Dynamic Management Views (http://msdn.microsoft.com/en-us/library/windowsazure/ff394114.aspx)

Microsoft Azure SQL Database partially supports three categories of dynamic management views:

Database-related dynamic management views.

Execution-related dynamic management views.

Transaction-related dynamic management views.

Monitoring Connections

You can use the sys.dm_exec_connections view to retrieve information about the connections established to a specific Azure SQL Database server and the details of

13

each connection. In addition, thesys.dm_exec_sessions view is helpful when retrieving information about all active user connections and internal tasks.

The following query retrieves information on the current connection:

-- monitor connections

SELECT

e.connection_id,

s.session_id,

s.login_name,

s.last_request_end_time,

s.cpu_time

FROM

sys.dm_exec_sessions s

INNER JOIN sys.dm_exec_connections e

ON s.session_id = e.session_id

GO

Monitoring Query Performance

Slow or long running queries can consume significant system resources. This section demonstrates how to use dynamic management views to detect a few common query performance problems. For detailed information, see Troubleshooting Performance Problems in SQL Server 2005 article on Microsoft TechNet.

Finding Top N Queries

The following example returns information about the top five queries ranked by average CPU time. This example aggregates the queries according to their query hash, so that logically equivalent queries are grouped by their cumulative resource consumption.

-- Find top 5queries

SELECT TOP 5 query_stats.query_hash AS "Query Hash",

SUM(query_stats.total_worker_time) / SUM(query_stats.execution_count) AS

"Avg CPU Time",

MIN(query_stats.statement_text) AS "Statement Text"

FROM

(SELECT QS.*,

SUBSTRING(ST.text, (QS.statement_start_offset/2) + 1,

((CASE statement_end_offset

WHEN -1 THEN DATALENGTH(st.text)

ELSE QS.statement_end_offset END

- QS.statement_start_offset)/2) + 1) AS statement_text

FROM sys.dm_exec_query_stats AS QS

CROSS APPLY sys.dm_exec_sql_text(QS.sql_handle) as ST) as query_stats

14

GROUP BY query_stats.query_hash

ORDER BY 2 DESC;

GO

Monitoring Blocked Queries

Slow or long-running queries can contribute to excessive resource consumption and be the consequence of blocked queries. The cause of the blocking can be poor application design, bad query plans, the lack of useful indexes, and so on. You can use the sys.dm_tran_locks view to get information about the current locking activity in your Azure SQL Database. For example code, see sys.dm_tran_locks (Transact-SQL)in SQL Server Books Online.

Monitoring Query Plans

An inefficient query plan also may increase CPU consumption. The following example uses the sys.dm_exec_query_stats view to determine which query uses the most cumulative CPU.

-- Monitor query plans

SELECT

highest_cpu_queries.plan_handle,

highest_cpu_queries.total_worker_time,

q.dbid,

q.objectid,

q.number,

q.encrypted,

q.[text]

FROM

(SELECT TOP 50

qs.plan_handle,

qs.total_worker_time

FROM

sys.dm_exec_query_stats qs

ORDER BY qs.total_worker_time desc) AS highest_cpu_queries

CROSS APPLY sys.dm_exec_sql_text(plan_handle) AS q

ORDER BY highest_cpu_queries.total_worker_time desc

Get SQL Profiler info from SQL Azure

(http://blogs.msdn.com/b/benko/archive/2012/05/19/cloudtip-14-how-do-i-get-

sql-profiler-info-from-sql-azure.aspx)

15

16

17

Analysis Resources and Tools

A number of third-party non-Microsoft tools are available for analyzing Azure performance:

Cerebrata

SQL Server and SQL Database Performance Testing: Enzo SQL Baseline

Other Resources

SQL Database Performance and Elasticity Guide

SQL Database

Storage

Networking

Service Bus

Azure Planning - A Post-decision Guide to Integrate Azure in Your Environment

Tracing:

To see which method is taking time,

We can do following:

In code in receive worker process and

In web.config

Configure the azure site for trace logging

18

Then start stream logging service as follows

Click on logs, Stream logs and see as below

19

Then run the web site code and it will give us where is the most time it is taking

If worker process is crashing, it may cause performance issue, we can find out by

the following process:

20

Open evenlog.xml in your event log folder in azure for the app and see why?

Click on download file after test and see.

Coming soon:

Coming soon in preview are a larger maximum database size (the current limit is 500GB), parallel queries (using multiple threads for query optimization)

There will also be support for in-memory columnstore queries in the premium version of Azure SQL database. Columnstore indexes are a type of in-memory database, enabling much faster queries at the expense of easy updating. They are

21

therefore suitable for large read-only datasets, such as those used by business analytics.