Check lista för prestanda effektivitetPerformance efficiency checklist

Prestanda effektivitet är möjligheten för din arbets belastning att skalas för att uppfylla de krav som ställs på den av användarna på ett effektivt sätt, och är en av grundarna i Microsoft Azure Well-Architected ramverket.Performance efficiency is the ability of your workload to scale to meet the demands placed on it by users in an efficient manner, and is one of the pillars of the Microsoft Azure Well-Architected Framework. Använd den här check listan för att granska program arkitekturen från ett prestanda effektivt syn perspektiv.Use this checklist to review your application architecture from a performance efficiency standpoint.

ProgramdesignApplication design

Partitionera arbets belastningen.Partition the workload. Design delar av processen som ska vara diskreta och desammansättnings bara.Design parts of the process to be discrete and decomposable. Minimera storleken på varje del, samtidigt som du följer de vanliga reglerna för separering av problem och den enskilda ansvars principen.Minimize the size of each part, while following the usual rules for separation of concerns and the single responsibility principle. Detta gör att komponent delar kan distribueras på ett sätt som maximerar användningen av varje beräknings enhet (till exempel en roll eller databas server).This allows the component parts to be distributed in a way that maximizes use of each compute unit (such as a role or database server). Det gör det också enklare att skala programmet genom att lägga till instanser av specifika resurser.It also makes it easier to scale the application by adding instances of specific resources. Överväg att använda en arkitektur för mikrotjänsterför komplexa domäner.For complex domains, consider adopting a microservices architecture.

Design för skalning.Design for scaling. Skalning gör att program kan reagera på varierande belastning genom att öka och minska antalet instanser av roller, köer och andra tjänster som de använder.Scaling allows applications to react to variable load by increasing and decreasing the number of instances of roles, queues, and other services they use. Programmet måste dock vara utformat med detta i åtanke.However, the application must be designed with this in mind. Till exempel måste programmet och de tjänster som används vara tillstånds lösa för att tillåta att begär Anden dirigeras till en instans.For example, the application and the services it uses must be stateless, to allow requests to be routed to any instance. Detta förhindrar även tillägg eller borttagning av vissa instanser från att påverka aktuella användare negativt.This also prevents the addition or removal of specific instances from adversely affecting current users. Du bör också implementera konfiguration eller automatisk identifiering av instanser när de läggs till och tas bort, så att koden i programmet kan utföra den nödvändiga dirigeringen.You should also implement configuration or autodetection of instances as they are added and removed, so that code in the application can perform the necessary routing. Ett webb program kan till exempel använda en uppsättning köer i en Round Robin-metod för att dirigera begär anden till bakgrunds tjänster som körs i arbets roller.For example, a web application might use a set of queues in a round-robin approach to route requests to background services running in worker roles. Webb programmet måste kunna identifiera ändringar i antalet köer, för att kunna dirigera begär Anden och utjämna belastningen på programmet.The web application must be able to detect changes in the number of queues, to successfully route requests and balance the load on the application.

Skala som en enhet.Scale as a unit. Planera för ytterligare resurser för att tillgodose tillväxten.Plan for additional resources to accommodate growth. För varje resurs känner du till de övre skalnings gränserna och använder horisontell partitionering eller diskompositioner för att gå utöver dessa gränser.For each resource, know the upper scaling limits, and use sharding or decomposition to go beyond these limits. Fastställ skalnings enheter för systemet i termer av väldefinierade resurs uppsättningar.Determine the scale units for the system in terms of well-defined sets of resources. Detta gör att det blir enklare att använda skalbarhet och mindre känsligt att påverka programmet genom begränsningar som påverkas av bristande resurser i någon del av det övergripande systemet.This makes applying scale-out operations easier, and less prone to negative impact on the application through limitations imposed by lack of resources in some part of the overall system. Att till exempel lägga till x antal webb- och arbetsroller kan kräva y antal ytterligare köer och z antal lagringskonton för att hantera den extra arbetsbelastning som genererats av rollerna.For example, adding x number of web and worker roles might require y number of additional queues and z number of storage accounts to handle the additional workload generated by the roles. En skalnings enhet kan bestå av x Web-och Worker-roller, y -köer och z Storage-konton.So a scale unit could consist of x web and worker roles, y queues, and z storage accounts. Designa programmet så att det skalas enkelt genom att lägga till en eller flera skalningsenheter.Design the application so that it's easily scaled by adding one or more scale units.

Undvik klient tillhörighet.Avoid client affinity. Om möjligt bör du kontrol lera att programmet inte kräver tillhörighet.Where possible, ensure that the application does not require affinity. Begär Anden kan därför dirigeras till vilken instans som helst, och antalet instanser är irrelevant.Requests can thus be routed to any instance, and the number of instances is irrelevant. Detta förhindrar också att du kan lagra, hämta och underhålla statusinformation för varje användare.This also avoids the overhead of storing, retrieving, and maintaining state information for each user.

Dra nytta av funktioner för automatisk skalning av plattform.Take advantage of platform autoscaling features. Om värd plattformen har stöd för en funktion för automatisk skalning, till exempel Azure Autoscale, föredrar du den för anpassade eller tredje parts mekanismer, om inte den inbyggda mekanismen inte uppfyller dina krav.Where the hosting platform supports an autoscaling capability, such as Azure Autoscale, prefer it to custom or third-party mechanisms unless the built-in mechanism can't fulfill your requirements. Använd schemalagda skalnings regler där det är möjligt att se till att resurserna är tillgängliga utan start fördröjning, men Lägg till reaktive rad autoskalning i reglerna där det är lämpligt att hantera oväntade förändringar i efter frågan.Use scheduled scaling rules where possible to ensure resources are available without a start-up delay, but add reactive autoscaling to the rules where appropriate to cope with unexpected changes in demand. Du kan använda åtgärderna för automatisk skalning i den klassiska distributions modellen för att justera autoskalning och lägga till anpassade räknare i regler.You can use the autoscaling operations in the classic deployment model to adjust autoscaling, and to add custom counters to rules. Mer information finns i rikt linjer för automatisk skalning.For more information, see Auto-scaling guidance.

Avlasta processor intensiva och I/O-intensiva uppgifter som bakgrunds aktiviteter.Offload CPU-intensive and I/O-intensive tasks as background tasks. Om en begäran till en tjänst förväntas ta lång tid att köra eller absorbera avsevärda resurser avlastar du bearbetningen för begäran till en separat aktivitet.If a request to a service is expected to take a long time to run or absorb considerable resources, offload the processing for this request to a separate task. Använd arbets roller eller bakgrunds jobb (beroende på värd plattform) för att utföra dessa uppgifter.Use worker roles or background jobs (depending on the hosting platform) to execute these tasks. Den här strategin gör att tjänsten kan fortsätta att ta emot ytterligare förfrågningar och fortsätta att svara.This strategy enables the service to continue receiving further requests and remain responsive. Mer information finns i rikt linjer för bakgrunds jobb.For more information, see Background jobs guidance.

Distribuera arbets belastningen för bakgrunds aktiviteter.Distribute the workload for background tasks. Om det finns många bakgrunds aktiviteter, eller om uppgifterna kräver avsevärd tid eller resurser, sprider du arbetet över flera beräknings enheter (till exempel arbets roller eller bakgrunds jobb).Where there are many background tasks, or the tasks require considerable time or resources, spread the work across multiple compute units (such as worker roles or background jobs). En möjlig lösning finns i mönstret för konkurrerande konsumenter.For one possible solution, see the Competing Consumers pattern.

Överväg att flytta till en delad – ingen arkitektur.Consider moving toward a shared-nothing architecture. En delad – Nothing-arkitektur använder oberoende, oberoende noder som inte har någon enskild punkt i konkurrens (till exempel delade tjänster eller lagring).A shared-nothing architecture uses independent, self-sufficient nodes that have no single point of contention (such as shared services or storage). I teorin kan ett sådant system skalas nästan oändligt.In theory, such a system can scale almost indefinitely. Även om en helt delad – Nothing-metod inte är praktisk för de flesta program, kan det ge möjligheter till design för bättre skalbarhet.While a fully shared-nothing approach is generally not practical for most applications, it may provide opportunities to design for better scalability. Undvik till exempel användningen av sessionstillstånd på Server sidan, klient tillhörighet och data partitionering är användbara exempel på att flytta till en delad-Nothing-arkitektur.For example, avoiding the use of server-side session state, client affinity, and data partitioning are good examples of moving toward a shared-nothing architecture.

DatahanteringData management

Använd data partitionering.Use data partitioning. Dela upp data över flera databaser och databas servrar eller utforma programmet för att använda data lagrings tjänster som kan tillhandahålla den här partitioneringen transparent (exempel är Azure SQL Database Elastic Database och Azure Table Storage).Divide the data across multiple databases and database servers, or design the application to use data storage services that can provide this partitioning transparently (examples include Azure SQL Database Elastic Database, and Azure Table storage). Den här metoden kan bidra till att maximera prestanda och möjliggöra enklare skalning.This approach can help to maximize performance and allow easier scaling. Det finns olika partitionerings metoder, som horisontellt, vertikalt och funktionellt.There are different partitioning techniques, such as horizontal, vertical, and functional. Du kan använda en kombination av dessa för att uppnå maximal nytta av ökad frågeresultat, enklare skalbarhet, mer flexibel hantering, bättre tillgänglighet och för att matcha den typ av lagring till data som den kommer att innehålla.You can use a combination of these to achieve maximum benefit from increased query performance, simpler scalability, more flexible management, better availability, and to match the type of store to the data it will hold. Överväg också att använda olika typer av data lager för olika typer av data, genom att välja olika typer baserat på hur bra de är optimerade för den aktuella data typen.Also, consider using different types of data store for different types of data, choosing the types based on how well they are optimized for the specific type of data. Detta kan vara att använda Table Storage, en dokument databas eller ett data lager i en kolumn serie, i stället för, eller och, en Relations databas.This may include using table storage, a document database, or a column-family data store, instead of, or as well as, a relational database. Mer information finns i rikt linjer för data partitionering.For more information, see Data partitioning guidance.

Design för eventuell konsekvens.Design for eventual consistency. Eventuell konsekvens förbättrar skalbarheten genom att minska eller ta bort den tid som krävs för att synkronisera relaterade data partitioner över flera butiker.Eventual consistency improves scalability by reducing or removing the time needed to synchronize related data partitioned across multiple stores. Kostnaden är att data inte alltid är konsekventa när de läses, och vissa Skriv åtgärder kan orsaka konflikter.The cost is that data is not always consistent when it is read, and some write operations may cause conflicts. Eventuell konsekvens är idealisk för situationer där samma data läses ofta men skrivs sällan.Eventual consistency is ideal for situations where the same data is read frequently but written infrequently. Mer information finns i introduktionen till data konsekvens.For more information, see the Data Consistency Primer.

Minska samtals samverkan mellan komponenter och tjänster.Reduce chatty interactions between components and services. Undvik att utforma interaktioner där ett program krävs för att göra flera anrop till en tjänst (var och en returnerar en liten mängd data) i stället för ett enda anrop som kan returnera alla data.Avoid designing interactions in which an application is required to make multiple calls to a service (each of which returns a small amount of data), rather than a single call that can return all of the data. När det är möjligt kan du kombinera flera relaterade åtgärder i en enda begäran när anropet är till en tjänst eller komponent som har märkbar svars tid.Where possible, combine several related operations into a single request when the call is to a service or component that has noticeable latency. Detta gör det enklare att övervaka prestanda och optimera komplexa åtgärder.This makes it easier to monitor performance and optimize complex operations. Du kan till exempel använda lagrade procedurer i databaser för att kapsla in komplex logik och minska antalet tur och inläsningar och resurs låsning.For example, use stored procedures in databases to encapsulate complex logic, and reduce the number of round trips and resource locking.

Använd köer för att utjämna belastningen för data skrivningar med hög hastighet.Use queues to level the load for high velocity data writes. Överspänningar i efter frågan för en tjänst kan överbelasta tjänsten och orsaka eskalering av fel.Surges in demand for a service can overwhelm that service and cause escalating failures. För att förhindra detta bör du överväga att implementera mönstret för köade belastnings nivåer.To prevent this, consider implementing the Queue-Based Load Leveling pattern. Använd en kö som fungerar som en buffert mellan en aktivitet och en tjänst som den anropar.Use a queue that acts as a buffer between a task and a service that it invokes. Detta kan utjämna tillfälliga belastningar som annars kan orsaka att tjänsten Miss lyckas eller att tids gränsen för aktiviteten upphör att fungera.This can smooth intermittent heavy loads that may otherwise cause the service to fail or the task to time out.

Minimera belastningen på data lagret.Minimize the load on the data store. Data lagret är ofta en bearbetnings Flask hals, en kostsam resurs och är ofta inte lätt att skala ut. Ta bort logik (till exempel att bearbeta XML-dokument eller JSON-objekt) från data lagret, och utför bearbetningen i programmet.The data store is commonly a processing bottleneck, a costly resource, and often not easy to scale out. Where possible, remove logic (such as processing XML documents or JSON objects) from the data store, and perform processing within the application. I stället för att skicka XML till databasen (förutom som en ogenomskinlig sträng för lagring), serialisera eller deserialisera XML-koden i program lagret och skicka den i ett formulär som är internt i data lagret.For example, instead of passing XML to the database (other than as an opaque string for storage), serialize or deserialize the XML within the application layer and pass it in a form that is native to the data store. Det är vanligt vis mycket enklare att skala ut programmet än data lagret, så du bör försöka göra så mycket som möjligt av beräknings intensiva bearbetningen i programmet.It's typically much easier to scale out the application than the data store, so you should attempt to do as much of the compute-intensive processing as possible within the application.

Minimera mängden data som hämtas.Minimize the volume of data retrieved. Hämta bara de data du behöver genom att ange kolumner och använda kriterier för att välja rader.Retrieve only the data you require by specifying columns and using criteria to select rows. Använd tabell värdes parametrar och lämplig isolerings nivå.Make use of table value parameters and the appropriate isolation level. Använd mekanismer som entiteter-taggar för att undvika att hämta data i onödan.Use mechanisms like entity tags to avoid retrieving data unnecessarily.

Använd cachelagring i aggressivt.Aggressively use caching. Använd cachelagring där det är möjligt för att minska belastningen på resurser och tjänster som genererar eller levererar data.Use caching wherever possible to reduce the load on resources and services that generate or deliver data. Cachelagring är vanligt vis lämpligt för data som är relativt statiska eller som kräver avsevärd bearbetning för att få.Caching is typically suited to data that is relatively static, or that requires considerable processing to obtain. Cachelagring bör ske på alla nivåer där det är lämpligt i varje lager i programmet, inklusive generering av data åtkomst och användar gränssnitt.Caching should occur at all levels where appropriate in each layer of the application, including data access and user interface generation. Mer information finns i Vägledning om cachelagring.For more information, see the Caching Guidance.

Hantera data tillväxt och kvarhållning.Handle data growth and retention. Mängden data som lagras av ett program växer med tiden.The amount of data stored by an application grows over time. Den här tillväxten ökar lagrings kostnaderna samt svars tid vid åtkomst till data, vilket påverkar programmets data flöde och prestanda.This growth increases storage costs as well as latency when accessing the data, affecting application throughput and performance. Det kan vara möjligt att regelbundet arkivera en del gamla data som inte längre används eller flytta data som sällan används till långsiktig lagring och som är mer kostnads effektivt, även om åtkomst fördröjningen är högre.It may be possible to periodically archive some of the old data that is no longer accessed, or move data that is rarely accessed into long-term storage that is more cost efficient, even if the access latency is higher.

Optimera dataöverföring objekt (DTO) med ett effektivt binärt format.Optimize Data Transfer Objects (DTOs) using an efficient binary format. DTO skickas mellan lagren i ett program flera gånger.DTOs are passed between the layers of an application many times. Att minimera storleken minskar belastningen på resurser och nätverket.Minimizing the size reduces the load on resources and the network. Du kan dock balansera besparingarna med behovet av att konvertera data till rätt format på varje plats där den används.However, balance the savings with the overhead of converting the data to the required format in each location where it is used. Använd ett format som har maximalt interoperabilitet för att möjliggöra enkel åter användning av en komponent.Adopt a format that has the maximum interoperability to enable easy reuse of a component.

Ange cache-kontroll.Set cache control. Utforma och konfigurera programmet till att använda cachelagring av utdata eller fragmentering av fragment, där det är möjligt, för att minimera bearbetnings belastningen.Design and configure the application to use output caching or fragment caching where possible, to minimize processing load.

Aktivera cachelagring på klient sidan.Enable client side caching. Webb program bör aktivera cacheinställningar för det innehåll som kan cachelagras.Web applications should enable cache settings on the content that can be cached. Detta är vanligt vis inaktiverat som standard.This is commonly disabled by default. Konfigurera servern så att den levererar lämpliga Cache Control-huvuden för att tillåta cachelagring av innehåll på proxyservrar och klienter.Configure the server to deliver the appropriate cache control headers to enable caching of content on proxy servers and clients.

Använd Azure Blob Storage och Azure-Content Delivery Network för att minska belastningen på programmet.Use Azure blob storage and the Azure Content Delivery Network to reduce the load on the application. Överväg att lagra statiskt eller relativt statiskt offentligt innehåll, till exempel bilder, resurser, skript och formatmallar, i Blob Storage.Consider storing static or relatively static public content, such as images, resources, scripts, and style sheets, in blob storage. Den här metoden avläser programmet av belastningen som orsakas av dynamiskt genererat innehåll för varje begäran.This approach relieves the application of the load caused by dynamically generating this content for each request. Överväg också att använda Content Delivery Network för att cachelagra innehållet och leverera det till klienter.Additionally, consider using the Content Delivery Network to cache this content and deliver it to clients. Att använda Content Delivery Network kan förbättra prestandan på klienten eftersom innehållet levereras från det geografiskt närmaste data centret som innehåller ett Content Delivery Network cacheminne.Using the Content Delivery Network can improve performance at the client because the content is delivered from the geographically closest datacenter that contains a Content Delivery Network cache. Mer information finns i Content Delivery Network rikt linjer.For more information, see the Content Delivery Network Guidance.

Optimera och finjustera SQL-frågor och index.Optimize and tune SQL queries and indexes. Vissa T-SQL-uttryck eller-konstruktioner kan ha en negativ effekt på prestanda som kan minskas genom att optimera koden i en lagrad procedur.Some T-SQL statements or constructs may have an adverse effect on performance that can be reduced by optimizing the code in a stored procedure. Undvik till exempel att konvertera datetime -typer till en varchar innan du jämför med ett datetime -värde.For example, avoid converting datetime types to a varchar before comparing with a datetime literal value. Använd funktionen för datum/tid-jämförelser i stället.Use date/time comparison functions instead. Brist på lämpliga index kan också göra frågekörningen.Lack of appropriate indexes can also slow query execution. Om du använder ett ramverk för objekt/Relations mappning kan du förstå hur det fungerar och hur det kan påverka prestandan för data åtkomst skiktet.If you use an object/relational mapping framework, understand how it works and how it may affect performance of the data access layer. Mer information finns i fråga-justering.For more information, see Query Tuning.

Överväg att avnormalisera data.Consider denormalizing data. Data normalisering bidrar till att undvika duplicering och inkonsekvens.Data normalization helps to avoid duplication and inconsistency. Men att behålla flera index, kontrol lera referens integritet, utföra flera åtkomst till små delar av data och koppla tabeller för att sätta samman data på ett sätt som kan påverka prestandan.However, maintaining multiple indexes, checking for referential integrity, performing multiple accesses to small chunks of data, and joining tables to reassemble the data imposes an overhead that can affect performance. Överväg om några ytterligare lagrings volymer och duplicering är acceptabla för att minska belastningen på data lagret.Consider if some additional storage volume and duplication is acceptable in order to reduce the load on the data store. Överväg också om själva programmet (som vanligt vis är enklare att skala) kan förlita sig på att ta över uppgifter som att hantera referens integritet för att minska belastningen på data lagret.Also consider if the application itself (which is typically easier to scale) can be relied on to take over tasks such as managing referential integrity in order to reduce the load on the data store. Mer information finns i rikt linjer för data partitionering.For more information, see Data partitioning guidance.

ImplementeringImplementation

Granska prestanda antimönster.Review the performance antipatterns. Se prestanda antimönster för moln program för vanliga metoder som kan orsaka skalbarhets problem när ett program är under tryck.See Performance antipatterns for cloud applications for common practices that are likely to cause scalability problems when an application is under pressure.

Använd asynkrona anrop.Use asynchronous calls. Använd asynkron kod när det är möjligt vid åtkomst till resurser eller tjänster som kan begränsas av I/O eller nätverks bandbredd eller som har en märkbar svars tid för att undvika låsning av anrops tråden.Use asynchronous code wherever possible when accessing resources or services that may be limited by I/O or network bandwidth, or that have a noticeable latency, in order to avoid locking the calling thread.

Undvik att låsa resurser och Använd en optimistisk metod i stället.Avoid locking resources, and use an optimistic approach instead. Lås aldrig åtkomst till resurser som lagring eller andra tjänster som har märkbar svars tid, eftersom detta är en primär orsak till dåliga prestanda.Never lock access to resources such as storage or other services that have noticeable latency, because this is a primary cause of poor performance. Använd alltid bästa metoder för att hantera samtidiga åtgärder, till exempel att skriva till lagring.Always use optimistic approaches to managing concurrent operations, such as writing to storage. Använd funktionerna i lagrings lagret för att hantera konflikter.Use features of the storage layer to manage conflicts. I distribuerade program kan data vara inkonsekventa.In distributed applications, data may be only eventually consistent.

Komprimera mycket komprimerbara data över hög latens, nätverk med liten bandbredd.Compress highly compressible data over high latency, low bandwidth networks. I de flesta fall i ett webb program är den största mängden data som genereras av programmet och skickas över nätverket HTTP-svar till klient begär Anden.In the majority of cases in a web application, the largest volume of data generated by the application and passed over the network is HTTP responses to client requests. HTTP-komprimering kan minska detta avsevärt, särskilt för statiskt innehåll.HTTP compression can reduce this considerably, especially for static content. Detta kan minska kostnaderna och minska belastningen på nätverket, men om du komprimerar dynamiskt innehåll används en instort större belastning på servern.This can reduce cost as well as reducing the load on the network, though compressing dynamic content does apply a fractionally higher load on the server. I andra, mer generaliserade miljöer, kan data komprimeringen minska mängden data som överförs och minimera överförings tiden och kostnaderna, men komprimerings-och avkomprimerings processerna medför kostnader.In other, more generalized environments, data compression can reduce the volume of data transmitted and minimize transfer time and costs, but the compression and decompression processes incur overhead. Därför bör komprimering endast användas när det finns en påvisbar vinst i prestanda.As such, compression should only be used when there is a demonstrable gain in performance. Andra metoder för serialisering, till exempel JSON-eller Binary-kodningar, kan minska nytto lastens storlek samtidigt som prestanda försämras, medan XML ökar förmodligen.Other serialization methods, such as JSON or binary encodings, may reduce the payload size while having less impact on performance, whereas XML is likely to increase it.

Minimera tiden som anslutningar och resurser används.Minimize the time that connections and resources are in use. Underhåll bara anslutningar och resurser så länge du behöver använda dem.Maintain connections and resources only for as long as you need to use them. Öppna till exempel anslutningar så sent som möjligt och Tillåt att de returneras till anslutningspoolen så snart som möjligt.For example, open connections as late as possible, and allow them to be returned to the connection pool as soon as possible. Få resurser så sent som möjligt och ta bort dem så snart som möjligt.Acquire resources as late as possible, and dispose of them as soon as possible.

Minimera antalet anslutningar som krävs.Minimize the number of connections required. Tjänst anslutningar absorberade resurser.Service connections absorb resources. Begränsa det antal som krävs och se till att befintliga anslutningar återanvänds närhelst det är möjligt.Limit the number that are required and ensure that existing connections are reused whenever possible. När du har utfört autentisering använder du till exempel personifiering om det är lämpligt för att köra kod som en speciell identitet.For example, after performing authentication, use impersonation where appropriate to run code as a specific identity. Detta kan hjälpa till att utnyttja anslutningspoolen på bästa sätt genom att återanvända anslutningar.This can help to make best use of the connection pool by reusing connections.

Anteckning

API: er för vissa tjänster återanvänder automatiskt anslutningar, förutsatt att de tjänstspecifika rikt linjerna följs.APIs for some services automatically reuse connections, provided service-specific guidelines are followed. Det är viktigt att du förstår de villkor som möjliggör åter användning av anslutningar för varje tjänst som används av programmet.It's important that you understand the conditions that enable connection reuse for each service that your application uses.

Skicka begär anden i batchar för att optimera användningen av nätverket.Send requests in batches to optimize network use. Till exempel skicka och läsa meddelanden i batchar vid åtkomst till en kö och utföra flera läsningar eller skrivningar som en batch vid åtkomst till lagring eller cache.For example, send and read messages in batches when accessing a queue, and perform multiple reads or writes as a batch when accessing storage or a cache. Detta kan hjälpa till att maximera effektiviteten hos tjänsterna och data lager genom att minska antalet samtal i nätverket.This can help to maximize efficiency of the services and data stores by reducing the number of calls across the network.

Undvik ett krav för att lagra sessionstillstånd på Server sidan där det är möjligt.Avoid a requirement to store server-side session state where possible. Hantering av sessionstillstånd på Server sidan kräver vanligt vis klient tillhörighet (det vill säga routning varje begäran till samma Server instans), vilket påverkar systemets möjlighet att skala.Server-side session state management typically requires client affinity (that is, routing each request to the same server instance), which affects the ability of the system to scale. Vi rekommenderar att du utformar klienter för att vara tillstånds lösa med avseende på de servrar som de använder.Ideally, you should design clients to be stateless with respect to the servers that they use. Men om programmet måste underhålla sessionstillstånd, lagra känsliga data eller stora volymer av per klient data i en distribuerad cache på Server sidan som alla instanser av programmet kan komma åt.However, if the application must maintain session state, store sensitive data or large volumes of per-client data in a distributed server-side cache that all instances of the application can access.

Optimera tabell lagrings scheman.Optimize table storage schemas. När du använder tabell arkiv som kräver att tabell-och kolumn namn skickas och bearbetas med varje fråga, till exempel Azure Table Storage, bör du överväga att använda kortare namn för att minska den här omkostnaderna.When using table stores that require the table and column names to be passed and processed with every query, such as Azure table storage, consider using shorter names to reduce this overhead. Du kan dock inte offra läsbarhet eller hanterbarhet med hjälp av alltför kompakta namn.However, do not sacrifice readability or manageability by using overly compact names.

Skapa resurs beroenden under distributionen eller när programmet startas.Create resource dependencies during deployment or at application startup. Undvik upprepade anrop till metoder som testar förekomsten av en resurs och skapa sedan resursen om den inte finns.Avoid repeated calls to methods that test the existence of a resource and then create the resource if it does not exist. Metoder som CloudTable. CreateIfNotExists och CloudQueue. CreateIfNotExists i Azure Storage klient bibliotek följer det här mönstret.Methods such as CloudTable.CreateIfNotExists and CloudQueue.CreateIfNotExists in the Azure Storage Client Library follow this pattern. Dessa metoder kan medföra avsevärda kostnader om de anropas före varje åtkomst till en lagrings tabell eller lagrings kö.These methods can impose considerable overhead if they are invoked before each access to a storage table or storage queue. I ställetInstead:

  • Skapa de resurser som krävs när programmet distribueras eller första gången den startas (ett enda anrop till CreateIfNotExists för varje resurs i Start koden för en webb-eller arbets roll är acceptabel).Create the required resources when the application is deployed, or when it first starts (a single call to CreateIfNotExists for each resource in the startup code for a web or worker role is acceptable). Men se till att hantera undantag som kan uppstå om din kod försöker komma åt en resurs som inte finns.However, be sure to handle exceptions that may arise if your code attempts to access a resource that doesn't exist. I dessa fall ska du logga undantaget och eventuellt varna en operator som en resurs saknas.In these situations, you should log the exception, and possibly alert an operator that a resource is missing.
  • Under vissa omständigheter kan det vara lämpligt att skapa den resurs som saknas som en del av koden för undantags hantering.Under some circumstances, it may be appropriate to create the missing resource as part of the exception handling code. Men du bör använda den här metoden med försiktighet när resursen inte är tillgänglig kan vara en indikation på ett programmerings fel (t. ex. ett felstavat resurs namn) eller något annat problem på infrastruktur nivå.But you should adopt this approach with caution as the non-existence of the resource might be indicative of a programming error (a misspelled resource name for example), or some other infrastructure-level issue.

Använd lätta ramverk.Use lightweight frameworks. Välj noggrant de API: er och ramverk som du använder för att minimera resursanvändningen, körnings tiden och den övergripande belastningen på programmet.Carefully choose the APIs and frameworks you use to minimize resource usage, execution time, and overall load on the application. Om du till exempel använder webb-API för att hantera tjänst begär Anden kan du minska programmets storlek och öka körnings hastigheten, men det kanske inte är lämpligt för avancerade scenarier där ytterligare funktioner i Windows Communication Foundation krävs.For example, using Web API to handle service requests can reduce the application footprint and increase execution speed, but it may not be suitable for advanced scenarios where the additional capabilities of Windows Communication Foundation are required.

Överväg att minimera antalet tjänst konton.Consider minimizing the number of service accounts. Du kan till exempel använda ett speciellt konto för att få åtkomst till resurser eller tjänster som har en gräns för anslutningar, eller utföra bättre där färre anslutningar bevaras.For example, use a specific account to access resources or services that impose a limit on connections, or perform better where fewer connections are maintained. Den här metoden är vanlig för tjänster som databaser, men det kan påverka möjligheten att korrekt granska åtgärder på grund av personifieringen av den ursprungliga användaren.This approach is common for services such as databases, but it can affect the ability to accurately audit operations due to the impersonation of the original user.

Genomför prestanda profilering och belastnings testning under utvecklingen, som en del av test rutinerna och före den slutliga versionen för att säkerställa att programmet presterar och skalar efter behov.Carry out performance profiling and load testing during development, as part of test routines, and before final release to ensure the application performs and scales as required. Den här testningen bör ske på samma typ av maskin vara som produktions plattformen, och med samma typ och kvantiteter data och användar belastning som uppstår i produktionen.This testing should occur on the same type of hardware as the production platform, and with the same types and quantities of data and user load as it will encounter in production. Mer information finns i testa prestanda för en moln tjänst.For more information, see Testing the performance of a cloud service.