ਇੱਕ API ਜੋ staging ਵਿੱਚ ਸੁਚਾਰੂ ਰੂਪ ਵਿੱਚ ਚੱਲਦੀ ਹੈ, ਅਸਲ traffic ਆਉਣ 'ਤੇ ਟੁੱਟ ਸਕਦੀ ਹੈ। ਅਸਫਲਤਾ ਸ਼ਾਇਦ ਹੀ ਕਦੇ ਡਰਾਉਣੀ ਹੁੰਦੀ ਹੈ। ਇਹ ਹਜ਼ਾਰਾਂ ਛੋਟੀਆਂ-ਛੋਟੀਆਂ ਕਮੀਆਂ ਕਾਰਨ ਹੋਣ ਵਾਲੀ ਮੌਤ ਵਾਂਗ ਹੈ। ਇੱਥੇ ਇੱਕ blocked thread। ਉੱਥੇ ਇੱਕ ਵਾਧੂ query। ਹਲਕੇ load ਦੇ ਹੇਠਾਂ, ਇਹ ਛੋਟੀਆਂ ਅਕੁਸ਼ਲਤਾਵਾਂ ਲੁਕੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ। ਪਰ production ਦੇ ਦਬਾਅ ਹੇਠ, ਇਹ thread pool starvation, database choking, ਅਤੇ ਅਜਿਹੇ response times ਵਿੱਚ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ ਜੋ ਉਪਭੋਗਤਾ ਦੇ ਭਰੋਸੇ ਨੂੰ ਤਬਾਹ ਕਰ ਦਿੰਦੇ ਹਨ। Performance tuning ਦਾ ਮਤਲਬ ਕੋਈ ਇੱਕ ਜਾਦੂਈ ਹੱਲ ਲੱਭਣਾ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਅਜਿਹਾ ਸਿਸਟਮ ਬਣਾਉਣ ਬਾਰੇ ਹੈ ਜਿੱਥੇ ਹਰ layer threads, memory, ਅਤੇ database connections ਦੀ ਸੀਮਾ ਦਾ ਸਤਿਕਾਰ ਕਰਦੀ ਹੋਵੇ। ਜਦੋਂ ਤੁਸੀਂ ਉਹਨਾਂ resources ਨੂੰ ਸੀਮਤ ਮੰਨਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ outages 'ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਰੋਕਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ।

Sync-over-Async ਨੂੰ ਆਪਣੇ ਆਪ ਨੂੰ ਖ਼ਤਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਖ਼ਤਮ ਕਰੋ

ਉੱਚ-traffic ਵਾਲੀਆਂ ASP.NET Core applications ਵਿੱਚ ਸਭ ਤੋਂ ਵਿਨਾਸ਼ਕਾਰੀ pattern sync-over-async ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਉਦੋਂ ਦੇਖਦੇ ਹੋ ਜਦੋਂ ਕੋਈ asynchronous method 'ਤੇ .Result ਜਾਂ .Wait() ਕਾਲ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਉਸੇ ਸਮੇਂ value ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਉਹ call stack ਨੂੰ refactor ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ। ਉਹ ਫੈਸਲਾ calling thread ਨੂੰ block ਕਰ ਦਿੰਦਾ ਹੈ। thread ਵਿਹਲਾ ਬੈਠ ਜਾਂਦਾ ਹੈ, ਉਸ ਕੰਮ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ ਜੋ ਪਹਿਲਾਂ ਹੀ ਕਿਤੇ ਹੋਰ ਹੋ ਰਿਹਾ ਹੈ, ਪਰ runtime ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ request ਲਈ ਦੁਬਾਰਾ ਵਰਤ ਨਹੀਂ ਸਕਦਾ।

ਜਦੋਂ ਕਾਫ਼ੀ requests ਅਜਿਹਾ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ thread pool starvation ਹੋ ਜਾਂਦੀ ਹੈ। ਤੁਹਾਡਾ CPU graph ਸਿਹਤਮੰਦ ਲੱਗਦਾ ਹੈ ਕਿਉਂਕਿ processors ਵਿਅਸਤ ਨਹੀਂ ਹੁੰਦੇ, ਫਿਰ ਵੀ ਤੁਹਾਡੀ latency ਬਹੁਤ ਵੱਧ ਜਾਂਦੀ ਹੈ। Requests ਕਤਾਰ ਵਿੱਚ ਲੱਗ ਜਾਂਦੀਆਂ ਹਨ, ਉਹਨਾਂ threads ਦੀ ਉਡੀਕ ਕਰਦੀਆਂ ਹਨ ਜੋ ਕਦੇ ਖਾਲੀ ਨਹੀਂ ਹੋਣਗੇ। ਇਸਦਾ ਹੱਲ ਮਕੈਨੀਕਲ ਹੈ ਪਰ ਇਸ ਲਈ ਅਨੁਸ਼ਾਸਨ ਦੀ ਲੋੜ ਹੈ: call stack ਦੇ ਉੱਪਰ ਤੱਕ await ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਕੋਈ method ਇੱਕ async API ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਖੁਦ ਵੀ async ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇੱਥੇ ਕੋਈ ਸ਼ਾਰਟਕੱਟ ਨਹੀਂ ਹਨ। ਤੁਹਾਡੇ ਦੁਆਰਾ ਹਟਾਇਆ ਗਿਆ ਹਰ synchronous blockage ਅਸਲ traffic ਲਈ ਜਗ੍ਹਾ ਬਣਾਉਂਦਾ ਹੈ।

Disconnected Clients 'ਤੇ ਕੰਮ ਬਰਬਾਦ ਕਰਨਾ ਬੰਦ ਕਰੋ

Clients disconnect ਹੋ ਜਾਂਦੇ ਹਨ। Browsers tabs ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਨ। Mobile apps signal ਗੁਆ ਲੈਂਦੀਆਂ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੇ server ਨੂੰ ਪਤਾ ਨਹੀਂ ਹੈ ਕਿ client ਚਲਾ ਗਿਆ ਹੈ, ਤਾਂ ਇਹ database queries ਚਲਾਉਂਦਾ ਰਹਿੰਦਾ ਹੈ, JSON parse ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਅਜਿਹੇ response 'ਤੇ threads ਬਰਬਾਦ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਜੋ ਕੋਈ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰੇਗਾ। ਹਰ ਉਸ async operation ਵਿੱਚ CancellationToken pass ਕਰੋ ਜੋ ਇਸਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ Entity Framework queries, HttpClient ਨਾਲ HTTP calls, ਅਤੇ ਕੋਈ ਵੀ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲਾ background work।

ਜਦੋਂ connection ਡਿੱਗਦਾ ਹੈ, ਤਾਂ token cancellation ਨੂੰ trigger ਕਰਦਾ ਹੈ, ਅਤੇ ਕੰਮ ਤੁਰੰਤ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਇਹ database CPU cycles ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ threads ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ pool ਵਿੱਚ ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ। ਇਹ method signatures ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਬਦਲਾਅ ਹੈ ਜੋ load ਦੇ ਹੇਠਾਂ ਫਾਇਦੇਮੰਦ ਸਾਬਤ ਹੁੰਦਾ ਹੈ।

ਜੋ ਬਦਲਦਾ ਨਹੀਂ ਹੈ ਉਸਨੂੰ Cache ਕਰੋ

ਤੁਹਾਡਾ product catalog ਸ਼ਾਇਦ ਹਰ request ਦੇ ਵਿਚਕਾਰ ਨਹੀਂ ਬਦਲਦਾ। ਤੁਹਾਡੇ configuration flags ਤਾਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਨਹੀਂ ਬਦਲਦੇ। ਫਿਰ ਵੀ ਬਹੁਤ ਸਾਰੀਆਂ APIs ਇੱਕੋ ਸਟੈਟਿਕ ਡੇਟਾ ਲਈ ਵਾਰ-ਵਾਰ database ਨੂੰ hit ਕਰਦੀਆਂ ਹਨ। ASP.NET Core ਵਿੱਚ output caching ਤੁਹਾਨੂੰ rendered responses ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ਆਪਣੇ controllers ਜਾਂ database ਨੂੰ ਦੁਬਾਰਾ ਛੂਹੇ ਬਿਨਾਂ ਸਿੱਧੇ memory ਤੋਂ ਉਹਨਾਂ ਨੂੰ ਸੇਵਾ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ।

Tag-based invalidation ਦੀ ਵਰਤੋਂ ਧਿਆਨ ਨਾਲ ਕਰੋ। ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ product ਨੂੰ update ਕਰਦੇ ਹੋ, ਤਾਂ ਸਿਰਫ਼ ਉਸ category ਜਾਂ item ਨਾਲ ਜੁੜੇ tag ਨੂੰ invalidate ਕਰੋ। ਤੁਹਾਨੂੰ ਪੂਰੇ cache ਨੂੰ flush ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਤੁਹਾਡੇ cache hit ratio ਨੂੰ ਉੱਚਾ ਅਤੇ database query count ਨੂੰ ਘੱਟ ਰੱਖਦਾ ਹੈ।

ਪਹਿਲਾਂ ਆਪਣੇ Data Access ਨੂੰ ਠੀਕ ਕਰੋ

ਜ਼ਿਆਦਾਤਰ APIs ਵਿੱਚ database calls request ਦੇ ਸਮੇਂ ਦਾ ਵੱਡਾ ਹਿੱਸਾ ਵਰਤਦੀਆਂ ਹਨ। ਕੁਝ ਵੀ ਹੋਰ optimize ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਇੱਥੇ ਦੇਖੋ।

ਜੇਕਰ ਤੁਸੀਂ ਡੇਟਾ ਨੂੰ ਸਿਰਫ਼ ਦਿਖਾਉਣ ਲਈ query ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਕਦੇ update ਕਰਨ ਦੀ ਯੋਜਨਾ ਨਹੀਂ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਆਪਣੀਆਂ Entity Framework queries ਵਿੱਚ AsNoTracking() ਲਗਾਓ। EF Core change tracking ਅਤੇ snapshot creation ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ।