ಸ್ಟೇಜಿಂಗ್ನಲ್ಲಿ ಸುಗಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ API, ನೈಜ ಟ್ರಾಫಿಕ್ ಬಂದ ತಕ್ಷಣ ಕುಸಿಯಬಹುದು. ಈ ವೈಫಲ್ಯವು ಅಪರೂಪಕ್ಕೆ ಮಾತ್ರ ನಾಟಕೀಯವಾಗಿರುತ್ತದೆ. ಇದು ಸಾವಿರ ಸಣ್ಣ ಗಾಯಗಳಿಂದ ಉಂಟಾಗುವ ಸಾವಿನಂತೆ. ಇಲ್ಲಿ ಒಂದು ಬ್ಲಾಕ್ ಆದ ಥ್ರೆಡ್ (thread). ಅಲ್ಲಿ ಒಂದು ಅನಗತ್ಯ ಕ್ವೆರಿ (query). ಕಡಿಮೆ ಲೋಡ್ ಇದ್ದಾಗ, ಈ ಸಣ್ಣ ಅಸಮರ್ಥತೆಗಳು ಅಡಗಿರುತ್ತವೆ. ಪ್ರೊಡಕ್ಷನ್ ಒತ್ತಡದ ಅಡಿಯಲ್ಲಿ, ಅವು ಥ್ರೆಡ್ ಪೂಲ್ ಸ್ಟಾರ್ವೇಶನ್ (thread pool starvation), ಡೇಟಾಬೇಸ್ ಚೋಕಿಂಗ್ (database choking) ಮತ್ತು ಬಳಕೆದಾರರ ವಿಶ್ವಾಸವನ್ನು ಹಾಳುಮಾಡುವ ಪ್ರತಿಕ್ರಿಯೆ ಸಮಯಗಳಾಗಿ (response times) ಪರಿಣಮಿಸುತ್ತವೆ. ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಟ್ಯೂನಿಂಗ್ ಎಂದರೆ ಒಂದು ಮ್ಯಾಜಿಕ್ ಪರಿಹಾರವನ್ನು ಹುಡುಕುವುದಲ್ಲ. ಇದು ಪ್ರತಿಯೊಂದು ಪದರವು ಥ್ರೆಡ್ಗಳು, ಮೆಮೊರಿ ಮತ್ತು ಡೇಟಾಬೇಸ್ ಕನೆಕ್ಷನ್ಗಳ ಕೊರತೆಯನ್ನು ಗೌರವಿಸುವ ವ್ಯವಸ್ಥೆಯನ್ನು ನಿರ್ಮಿಸುವುದರ ಬಗ್ಗೆಯಾಗಿದೆ. ನೀವು ಆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೀಮಿತ ಎಂದು ಪರಿಗಣಿಸಿದಾಗ, ನೀವು ವ್ಯತ್ಯಯಗಳಿಗೆ (outages) ಪ್ರತಿಕ್ರಿಯಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ, ಅವುಗಳನ್ನು ತಡೆಯಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ.
Sync-over-Async ನಿಮ್ಮನ್ನು ನಾಶಪಡಿಸುವ ಮುನ್ನವೇ ಅದನ್ನು ಕೊಲ್ಲಿ
ಹೆಚ್ಚಿನ ಟ್ರಾಫಿಕ್ ಇರುವ ASP.NET Core ಅಪ್ಲಿಕೇಶನ್ಗಳಲ್ಲಿ ಅತ್ಯಂತ ವಿನಾಶಕಾರಿ ಮಾದರಿ ಎಂದರೆ sync-over-async. ಯಾರಾದರೂ ಅಸynchronೋ (asynchronous) ಮೆಥಡ್ ಮೇಲೆ .Result ಅಥವಾ .Wait() ಅನ್ನು ಕರೆಯುವಾಗ ನೀವು ಇದನ್ನು ನೋಡಬಹುದು, ಏಕೆಂದರೆ ಅವರಿಗೆ ತಕ್ಷಣವೇ ಮೌಲ್ಯದ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ಅವರು ಕಾಲ್ ಸ್ಟ್ಯಾಕ್ ಅನ್ನು (call stack) ಮರುರೂಪಿಸಲು (refactor) ಇಷ್ಟಪಡುವುದಿಲ್ಲ. ಆ ನಿರ್ಧಾರವು ಕರೆಯುವ ಥ್ರೆಡ್ ಅನ್ನು ಬ್ಲಾಕ್ ಮಾಡುತ್ತದೆ. ಥ್ರೆಡ್ ಸುಮ್ಮನೆ ಕುಳಿತಿರುತ್ತದೆ, ಬೇರೆಡೆ ಈಗಾಗಲೇ ನಡೆಯುತ್ತಿರುವ ಕೆಲಸಕ್ಕಾಗಿ ಕಾಯುತ್ತದೆ, ಆದರೆ ರನ್ಟೈಮ್ (runtime) ಅದನ್ನು ಮತ್ತೊಂದು ವಿನಂತಿಗಾಗಿ ಮರುಬಳಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.
ಸಾಕಷ್ಟು ವಿನಂತಿಗಳು ಹೀಗೆ ಮಾಡಿದಾಗ, ಥ್ರೆಡ್ ಪೂಲ್ ಖಾಲಿಯಾಗುತ್ತದೆ (starves). ಪ್ರೊಸೆಸರ್ಗಳು ಕಾರ್ಯನಿರತವಾಗಿಲ್ಲದ ಕಾರಣ ನಿಮ್ಮ CPU ಗ್ರಾಫ್ ಆರೋಗ್ಯಕರವಾಗಿ ಕಾಣಿಸಬಹುದು, ಆದರೂ ನಿಮ್ಮ લેಟೆನ್ಸಿ (latency) ವಿಪರೀತವಾಗಿ ಹೆಚ್ಚಾಗುತ್ತದೆ. ವಿನಂತಿಗಳು ಸಾಲಿನಲ್ಲಿ ನಿಲ್ಲುತ್ತವೆ, ಎಂದಿಗೂ ಬಿಡುಗಡೆಯಾಗದ ಥ್ರೆಡ್ಗಳಿಗಾಗಿ ಕಾಯುತ್ತವೆ. ಇದಕ್ಕೆ ಪರಿಹಾರವು ತಾಂತ್ರಿಕವಾಗಿದೆ ಆದರೆ ಶಿಸ್ತನ್ನು ಬಯಸುತ್ತದೆ: ಕಾಲ್ ಸ್ಟ್ಯಾಕ್ನ ಉದ್ದಕ್ಕೂ await ಬಳಸಿ. ಒಂದು ಮೆಥಡ್ ಅಸynchronೋ (async) API ಅನ್ನು ಕರೆಯುತ್ತಿದ್ದರೆ, ಅದು ಸ್ವತಃ ಅಸynchronೋ ಆಗಿರಲೇಬೇಕು. ಇಲ್ಲಿ ಯಾವುದೇ ಶಾರ್ಟ್ಕಟ್ಗಳಿಲ್ಲ. ನೀವು ತೆಗೆದುಹಾಕುವ ಪ್ರತಿಯೊಂದು ಸಿಂಕ್ರೋನಸ್ (synchronous) ಅಡಚಣೆಯು ನೈಜ ಟ್ರಾಫಿಕ್ಗಾಗಿ ಹೆಚ್ಚಿನ ಅವಕಾಶವನ್ನು (headroom) ಒದಗಿಸುತ್ತದೆ.
ಡಿಸ್ಕನೆಕ್ಟ್ ಆದ ಕ್ಲೈಂಟ್ಗಳ ಮೇಲೆ ಕೆಲಸವನ್ನು ವ್ಯರ್ಥ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸಿ
ಕ್ಲೈಂಟ್ಗಳು ಡಿಸ್ಕನೆಕ್ಟ್ ಆಗುತ್ತಾರೆ. ಬ್ರೌಸರ್ಗಳು ಟ್ಯಾಬ್ಗಳನ್ನು ಮುಚ್ಚುತ್ತವೆ. ಮೊಬೈಲ್ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಸಿಗ್ನಲ್ ಕಳೆದುಕೊಳ್ಳುತ್ತವೆ. ಕ್ಲೈಂಟ್ ಹೋಗಿದ್ದಾನೆ ಎಂದು ನಿಮ್ಮ ಸರ್ವರ್ಗೆ ತಿಳಿಯದಿದ್ದರೆ, ಅದು ಡೇಟಾಬೇಸ್ ಕ್ವೆರಿಗಳನ್ನು ಚಲಾಯಿಸುವುದು, JSON ಪಾರ್ಸ್ ಮಾಡುವುದು ಮತ್ತು ಯಾರೂ ಸ್ವೀಕರಿಸದ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಥ್ರೆಡ್ಗಳನ್ನು ವ್ಯರ್ಥ ಮಾಡುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ. ಇದನ್ನು ಬೆಂಬಲಿಸುವ ಪ್ರತಿಯೊಂದು ಅಸynchronೋ (async) ಆಪರೇಷನ್ಗೆ CancellationToken ಅನ್ನು ವರ್ಗಾಯಿಸಿ. ಅಂದರೆ Entity Framework ಕ್ವೆರಿಗಳು, HttpClient ನೊಂದಿಗೆ ಮಾಡುವ HTTP ಕರೆಗಳು ಮತ್ತು ಯಾವುದೇ ದೀರ್ಘಾವಧಿಯ ಬ್ಯಾಕ್ಗ್ರೌಂಡ್ ಕೆಲಸಗಳು.
ಕನೆಕ್ಷನ್ ಕಡಿತಗೊಂಡಾಗ, ಟೋಕನ್ ರದ್ದತೆಯನ್ನು (cancellation) ಪ್ರಚೋದಿಸುತ್ತದೆ ಮತ್ತು ಕೆಲಸ ತಕ್ಷಣವೇ ನಿಲ್ಲುತ್ತದೆ. ಇದು ಡೇಟಾಬೇಸ್ CPU ಸೈಕಲ್ಗಳನ್ನು ಉಳಿಸುತ್ತದೆ ಮತ್ತು ಥ್ರೆಡ್ಗಳನ್ನು ವೇಗವಾಗಿ ಪೂಲ್ಗೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಇದು ಮೆಥಡ್ ಸಿಗ್ನೇಚರ್ಗಳಲ್ಲಿ (method signatures) ಮಾಡುವ ಸಣ್ಣ ಬದಲಾವಣೆಯಾಗಿದ್ದು, ಲೋಡ್ ಇದ್ದಾಗ ಹೆಚ್ಚಿನ ಪ್ರಯೋಜನ ನೀಡುತ್ತದೆ.
ಬದಲಾಗದ ವಿಷಯಗಳನ್ನು ಕ್ಯಾಶ್ (Cache) ಮಾಡಿ
ನಿಮ್ಮ ಪ್ರಾಡಕ್ಟ್ ಕ್ಯಾಟಲಾಗ್ ಪ್ರತಿಯೊಂದು ವಿನಂತಿಯ ನಡುವೆ ಬದಲಾಗುವುದಿಲ್ಲ. ನಿಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್ ಫ್ಲಾಗ್ಗಳು ಖಂಡಿತವಾಗಿಯೂ ಬದಲಾಗುವುದಿಲ್ಲ. ಆದರೂ ಅನೇಕ APIಗಳು ಒಂದೇ ಸ್ಟ್ಯಾಟಿಕ್ ಡೇಟಾಕ್ಕಾಗಿ ಪದೇ ಪದೇ ಡೇಟಾಬೇಸ್ಗೆ ವಿನಂತಿ ಮಾಡುತ್ತವೆ. ASP.NET Core ನಲ್ಲಿನ ಔಟ್ಪುಟ್ ಕ್ಯಾಶಿಂಗ್ (Output caching) ನಿಮಗೆ ರೆಂಡರ್ ಮಾಡಿದ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸಂಗ್ರಹಿಸಲು ಮತ್ತು ನಿಮ್ಮ ಕಂಟ್ರೋಲರ್ಗಳು ಅಥವಾ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಮತ್ತೆ ಮುಟ್ಟದೆ ನೇರವಾಗಿ ಮೆಮೊರಿಯಿಂದ ಅವುಗಳನ್ನು ನೀಡಲು ಅನುಮತಿಸುತ್ತದೆ.
ಟ್ಯಾಗ್-ಆಧಾರಿತ ಇನ್ವ್ಯಾಲಿಡೇಶನ್ (tag-based invalidation) ಅನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಬಳಸಿ. ನೀವು ಉತ್ಪನ್ನವನ್ನು ಅಪ್ಡೇಟ್ ಮಾಡಿದಾಗ, ಆ ವರ್ಗ ಅಥವಾ ಐಟಂಗೆ ಸಂಬಂಧಿಸಿದ ಟ್ಯಾಗ್ ಅನ್ನು ಮಾತ್ರ ಇನ್ವ್ಯಾಲಿಡೇಟ್ ಮಾಡಿ. ನೀವು ಇಡೀ ಕ್ಯಾಶ್ ಅನ್ನು ಫ್ಲಶ್ (flush) ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಇದು ನಿಮ್ಮ ಕ್ಯಾಶ್ ಹಿಟ್ ರೇಶಿಯೊವನ್ನು (cache hit ratio) ಹೆಚ್ಚಾಗಿ ಮತ್ತು ನಿಮ್ಮ ಡೇಟಾಬೇಸ್ ಕ್ವೆರಿ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆಯಾಗಿರಿಸುತ್ತದೆ.
ಮೊದಲು ನಿಮ್ಮ ಡೇಟಾ ಅಕ್ಸೆಸ್ ಅನ್ನು ಸರಿಪಡಿಸಿ
ಹೆಚ್ಚಿನ APIಗಳಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಕರೆಗಳು ವಿನಂತಿಯ ಸಮಯದ ಬಹುಪಾಲು ಭಾಗವನ್ನು ಬಳಸುತ್ತವೆ. ನೀವು ಬೇರೆ ಯಾವುದನ್ನಾದರೂ ಆಪ್ಟಿಮೈಸ್ (optimise) ಮಾಡುವ ಮೊದಲು, ಇಲ್ಲಿ ಗಮನಿಸಿ.
ನೀವು ಡೇಟಾವನ್ನು ಕೇವಲ ಪ್ರದರ್ಶಿಸಲು ಮಾತ್ರ ಕ್ವೆರಿ ಮಾಡುತ್ತಿದ್ದರೆ ಮತ್ತು ಅದನ್ನು ಎಂದಿಗೂ ಅಪ್ಡೇಟ್ ಮಾಡಲು ಯೋಜಿಸದಿದ್ದರೆ, ನಿಮ್ಮ Entity Framework ಕ್ವೆರಿಗಳಿಗೆ AsNoTracking() ಅನ್ನು ಸೇರಿಸಿ. EF Core ಚೇಂಜ್ ಟ್ರ್ಯಾಕಿಂಗ್ (change tracking) ಮತ್ತು ಸ್ನ್ಯಾಪ್ಶಾಟ್ ರಚನೆಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.