Design Azure applications for efficiency
Making choices that effect performance efficiency is critical to application design. For additional related topics, see the Design scalable Azure applications article in the Performance efficiency pillar.
Reduce response time with asynchronous programming
The time for the caller to receive a response could range from milliseconds to minutes. During that time, the thread is held by the process until the response comes back, or if an exception happens. This is inefficient because it means that no other requests can be processed during the time waiting for a response. An example when multiple requests in flight is inefficient is a bank account. In this situation, only one resource can operate on the request at the same time. Another example is when connection pools can't be shared, and then all of the requests need separate connections to complete.
Asynchronous programming is an alternative approach. It enables a remote service to be executed without waiting and blocking resources on the client. This is a critical pattern for enabling cloud scalable software and is available in most modern programming languages and platforms.
There are many ways to inject asynchronous programming into an application design. For APIs and services that work across the internet, consider using the Asynchronous Request-Reply pattern. When writing code, remote calls can be asynchronously executed using built-in language constructs like async/await in .NET C#. Review a language construct example. .NET has other built-in platform support for asynchronous programming with task and event based asynchronous patterns.
Process faster by queuing and batching requests
Similar to asynchronous programming, queuing services has long been used as a scalable mechanism to hand off processing work to a service. Highly scalable queuing services are natively supported in Azure. The queue is a storage buffer located between the caller and the processing service. It takes requests, stores them in a buffer, and queues the requests to provide services around the reliable delivery and management of the queued data.
Using a queue is often the best way to hand off work to a processor service. The processor service receives work by listening on a queue and dequeuing messages. If items to be processed enter too quickly, the queuing service will keep them in the queue until the processing service has available resources and asks for a new work item (message). By leveraging the dynamic nature of Azure Functions, the processor service can easily autoscale on demand as the queue builds up to meet the intake pressure. Developing processor logic with Azure Functions to run task logic from a queue is a common, scalable, and cost effective way to using queuing between a client and a processor.
Azure provides some native first-party queueing services with Azure Storage Queues (simple queuing service based on Azure Storage) and Azure Service Bus (message broker service supporting transactions and reduced latency). Many other third-party options are also available through Azure Marketplace.
To learn more about queue-based Load Leveling, see Queue-based Load Leveling pattern. To compare and contrast queues, see Storage queues and Service Bus queues - compared and contrasted.
Optimize with data compression
A well-known optimization best practice for scaling is to use a compression strategy to compress and bundle web pages or API responses. The idea is to shrink the data returned from a page or API back to the browser or client app. Compressing the data returned to clients optimizes network traffic and accelerates the application. Azure Front Door can perform file compression, and .NET has built-in framework support for this technique with GZip compression. For more information, see Response compression in ASP.NET Core.
Improve scalability with session affinity
If an application is stateful, meaning that data or state will be stored locally in the instance of the application, it may increase the performance of your application, if you enable session affinity. When session affinity is enabled, subsequent requests to the application will be directed to the same server that processed the first request. If session affinity is not enabled, subsequent requests would be directed to the next available server depending on the load balancing rules. Session affinity allows the instance to have some persistent or cached data/context, which can speed subsequent requests. However, if your application does not store large amounts of state or cached data in memory, session affinity might decrease your throughput because one host could get overloaded with requests, while others are dormant.
Tip
Migrate an Azure Cloud Services application to Azure Service Fabric describes best practices about stateless services for an application that is migrated from old Azure Cloud Services to Azure Service Fabric.
Run background jobs to meet integration needs
Many types of applications require background tasks that run independently of the user interface (UI). Examples include batch jobs, intensive processing tasks, and long-running processes such as workflows. Background jobs can be executed without requiring user interaction. The application can start the job and then continue to process interactive requests from users. To learn more, see Background jobs.
Background tasks must offer sufficient performance to ensure they do not block the application, or cause inconsistencies due to delayed operation when the system is under load. Typically, performance is improved by scaling the compute instances that host the background tasks. For a list of considerations, see Scaling and performance considerations.
Logic Apps is a serverless consumption (pay-per-use) service that enables a vast set of out-of-the-box ready-to-use connectors and a long-running workflow engine to enable cloud-native integration needs quickly. Logic Apps is flexible enough for scenarios like running tasks/jobs, advanced scheduling, and triggering. Logic Apps also has advanced hosting options to allow it to run within enterprise restricted cloud environments. Logic Apps can be combined with all other Azure services to complement one another, or it can be used independently.
Like all serverless services, Logic Apps doesn't require VM instances to be purchased, enabled, and scaled up and down. Instead, Logic Apps scale automatically on serverless PaaS provided instances, and a consumer only pays based on usage.
Next steps
Povratne informacije
Pošalјite i prikažite povratne informacije za