# Performance की आदतें — .NET Core: वेब API बनाएँ, टेस्ट करें और शिप करें

Source: https://www.geekswithgeeks.com/hi/dotnet-core/ship-performance

> Async I/O, response caching और compression लगाएँ और optimise करने से पहले मापें।

## पहले मापें

ज़्यादातर धीमी APIs database या remote call की वजह से धीमी होती हैं, C# की वजह से नहीं। N+1 queries ठीक करें, indexes जोड़ें, हर जगह async रखें, और उसके बाद ही caching सोचें। बिना मापे अंदाज़ा लगाना समय बर्बाद करता है।

## Output caching और compression

ज़्यादा पढ़े जाने वाले, कम बदलने वाले endpoint को 30 सेकंड cache करें और responses compress करें। User-विशिष्ट डेटा को साझा key पर कभी cache न करें।

```csharp
builder.Services.AddOutputCache();
builder.Services.AddResponseCompression();

var app = builder.Build();
app.UseResponseCompression();
app.UseOutputCache();

app.MapGet("/catalog", () => Catalog.LoadAll())
   .CacheOutput(p => p.Expire(TimeSpan.FromSeconds(30)));
```

## Health checks उपयोग करें

लोड बैलेंसर और Kubernetes जान सकें कि आपका ऐप ज़िंदा है, इसके लिए `app.MapHealthChecks("/healthz")` map करें। Structured logging और metrics (OpenTelemetry) जोड़ें ताकि users के बताने से पहले आप समस्या देख सकें।

**Quiz:** धीमे endpoint में caching जोड़ने से पहले क्या करना चाहिए?

- [ ] उसे किसी और भाषा में दोबारा लिखें
- [ ] Logging बंद करें
- [ ] और middleware जोड़ें
- [x] असली bottleneck खोजने के लिए मापें

*Answer:* असली bottleneck खोजने के लिए मापें. Profiling या query logs आम तौर पर असली कारण दिखाते हैं, जैसे N+1 query, जिसे caching सिर्फ़ छिपाएगी।
