Azure Applications Performance Tips and Tricks

1. [TYPE THE COMPANY NAME]
Azure Application
Performance Guide
Need to check matrix
Bhonhariya, Salim(Cloud Architect)
1/9/2015
Al rights reserved

2. 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

3. 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”

4. 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

5. 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.

6. 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)

7. 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.

8. 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:SSDCACHEEXAMPLE.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

9. 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.

10. 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.

11. 10

12. 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)

13. 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

14. 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

15. 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)

16. 15

17. 16

18. 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

19. 18
Then start stream logging service as follows
Click on logs, Stream logs and see as below

20. 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:

21. 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

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