वेबसाइट
साइट प्रदर्शन और APM
Application Performance Monitoring tells you where your site's time actually goes: response time percentiles, the slowest URLs, the slowest database queries, and how hard PHP is working. This guide…
Application Performance Monitoring आपको बताता है कि आपकी साइट का समय वास्तव में कहाँ जाता है: response time percentiles, सबसे धीमे URLs, सबसे धीमी database queries, और PHP कितनी मेहनत कर रहा है। यह गाइड APM को सक्षम करने, प्रत्येक पैनल को पढ़ने और यह दिखाता है कि इस पर कार्य करने को कवर करती है।
KPanel में APM कहाँ है
- KPanel में साइन इन करें।
- बाईं ओर की साइडबार में Websites पर क्लिक करें, फिर साइट पर क्लिक करें।
- साइट के टैब स्ट्रिप में, WordPress खोलें, फिर APM।
सीधा पता /websites/<site-id>/performance है।
APM एक प्लान entitlement है। यह Managed WordPress Pro के साथ शामिल है। किसी भी अन्य प्लान पर पृष्ठ एक upgrade पैनल दिखाता है जो dashboards के बजाय APM को समझाता है। यदि आप वह पैनल देखते हैं, तो यह सुविधा आपकी वर्तमान प्लान पर उपलब्ध नहीं है, बंद नहीं है।
APM को चालू करना
APM तब तक बंद है जब तक आप इसे सक्षम न करें। एक eligible प्लान पर पृष्ठ एक Application Performance Monitoring कार्ड दिखाता है एक Enable APM बटन के साथ।
इसे सक्षम करने से PHP worker स्तर पर एक lightweight access log और एक slow-request tracker जोड़ता है। यह आपके पृष्ठों में कुछ भी inject नहीं करता है और किसी visitor के request में कोई काम नहीं जोड़ता है, इसलिए इसे स्थायी रूप से चालू रखना सुरक्षित है।
एक बार सक्षम होने के बाद पृष्ठ एक APM Active pill दिखाता है जिस तारीख को यह चालू किया गया था, एक Refresh बटन, और एक Disable APM बटन। Metrics केवल वास्तविक traffic के आने के बाद दिखाई देते हैं, इसलिए एक शांत साइट कुछ समय के लिए Waiting for requests दिखाती है।
Response Times
पहला कार्ड पिछले घंटे से चार आंकड़े रखता है, इसके header में request count और capture time के साथ।
| Metric | इसका अर्थ है |
|---|---|
| Median (P50) | आधे requests इससे तेज़ थे |
| P95 | 95 percent requests इससे तेज़ थे |
| P99 | 99 percent requests इससे तेज़ थे |
| 5xx Error Rate | उन requests का हिस्सा जो server error से विफल रहे |
प्रत्येक टाइल रंग-कोडित है ताकि आप thresholds जाने बिना state को पढ़ सकें।
Percentiles को एक साथ पढ़ें, अलग से नहीं। एक अच्छा median एक भयानक P95 के साथ मतलब है कि अधिकांश requests ठीक हैं और एक अल्पसंख्यक painful हैं, जो एक धीमे पृष्ठ, एक धीमी query, या एक cache का classic signature है जो कुछ URLs पर misses करता है। एक बुरा median का अर्थ है कि पूरी साइट धीमी है और कारण आमतौर पर structural होता है: एक undersized plan, एक heavy theme, या caching जो बंद है।
5xx error rate वह एक आंकड़ा है जो zero होना चाहिए। zero से ऊपर कुछ भी sustained मतलब है कि visitors failures देख रहे हैं।
PHP Workers
PHP Workers कार्ड तीन नंबर दिखाता है:
- Active Workers: कितनी PHP processes वर्तमान में requests को handle कर रही हैं।
- Slow Requests: requests जो slow-request threshold को पार करते हैं और logged किए गए थे।
- Total Handled: pool शुरू होने के बाद से स्वीकृत connections।
Active workers एक saturation signal है। यदि यह सामान्य traffic के दौरान अपनी ceiling के पास pinned बैठा है, तो requests PHP के पीछे queue में हैं, और ऊपर पृष्ठ पर प्रत्येक response time आंशिक रूप से queue time है। यह एक capacity problem है, code problem नहीं, और समाधान एक बड़ी plan या प्रति request कम काम है।
एक climbing slow-request count एक stable request volume के साथ मतलब है कि कुछ expensive बन गया है।
Slowest Endpoints
यह कार्ड आपके slowest URLs को P95 response time के अनुसार सूचीबद्ध करता है, प्रत्येक एक bar, P95 milliseconds में, और इसे कितनी बार calls मिले। रंग सबसे बुरे offenders को चिह्नित करता है।
इसे एक leaderboard के रूप में नहीं, एक shortlist के रूप में पढ़ें। जो आप चाहते हैं वह slow और frequently called का intersection है: एक पृष्ठ जो चार सेकंड लेता है और दिन में दो बार hit होता है, वह एक से बहुत कम मायने रखता है जो 900 milliseconds लेता है और दस हज़ार बार hit होता है।
Common culprits:
- Search pages जो एक index के बिना scan करते हैं।
- Category और archive listings जो प्रति request बड़े queries बनाते हैं।
- Cart, checkout और account pages, जो कभी cached नहीं होते क्योंकि वे per-visitor होते हैं। Site Caching देखें कि कौन से paths design के अनुसार cache को bypass करते हैं।
- Admin URLs, जो हमेशा dynamic होते हैं।
- कुछ भी जो request के अंदर एक external API को call कर रहा है, जहाँ आप किसी और के server को measure कर रहे हैं।
Slow Queries
Slow Queries कार्ड database queries को सूचीबद्ध करता है जो औसतन 100 milliseconds से अधिक हैं, database के अपने performance data से लिए गए। प्रत्येक row average time, maximum time, call count, और normalised query text दिखाता है।
Query text एक digest है, literal values हटाए गए हैं, इसलिए विभिन्न parameters के साथ एक ही query एक row में groups करता है। यही है जो call count को meaningful बनाता है।
Slow queries को ठीक करना आमतौर पर तीन चीजों में से एक है: एक index जोड़ना जिसकी query को ज़रूरत है, query को कितनी बार चलाता है यह कम करना इसके result को cache करके, या plugin को हटाना जो इसे generate करता है। एक बहुत ही high call count और एक moderate average के साथ एक query अक्सर एक एकल dramatic outlier की तुलना में aggregate में बदतर होता है।
यदि endpoints और queries दोनों lists खाली आते हैं, तो कार्ड कहता है कि no slow requests detected, जिसका अर्थ है कि पिछले घंटे में सबकुछ normal thresholds के अंदर था।
APM को अच्छी तरह उपयोग करना
एक baseline लें। जब साइट healthy हो तब नंबर देखें, ताकि आप जान सकें कि normal कैसा दिखता है। 700 milliseconds का P95 तब तक कुछ नहीं मायने रखता जब तक आप न जानते हों कि यह 300 होता था।
एक बार में एक चीज़ बदलें। एक cache सक्षम करें, refresh करें, और तुलना करें। एक suspect plugin को deactivate करें, refresh करें, और तुलना करें। Batched changes आपको कोई signal नहीं देते हैं।
Deliberately refresh करें। Refresh बटन demand पर metrics को फिर से पढ़ता है। आंकड़े पिछले घंटे को cover करते हैं, इसलिए परिवर्तन को judge करने से पहले इसे थोड़ा समय दें।
APM के बाहर भी देखें। APM आपके application को measure करता है। यदि समस्या network या edge में है code के बजाय, तो Site Traffic Analytics और Site Uptime Monitoring इसे दिखाएंगे।
समस्या निवारण
पृष्ठ एक upgrade पैनल दिखाता है। APM Managed WordPress Pro के साथ शामिल है। अन्य plans पर यह उपलब्ध नहीं है।
APM चालू है लेकिन कोई metrics नहीं हैं। अभी traffic नहीं। Metrics तब दिखाई देते हैं जब साइट को requests मिलते हैं।
Response times APM में ठीक हैं लेकिन साइट धीमी लगती है। APM केवल server-side time को measure करता है। ब्राउज़र में images download करने, JavaScript चलाने, और fonts loading में बिताया गया समय यहाँ invisible है। यदि server time अच्छा है और पृष्ठ अभी भी धीमा लगता है, तो समस्या front end में है या जो आप ब्राउज़र को fetch करने के लिए कह रहे हैं उसमें है।
P95 एक plugin update के बाद बदतर हो गया। Slowest endpoints list देखें, फिर slow queries list। एक plugin जो हर page load में एक query जोड़ता है दोनों में दिखाई देगा।
हर समय सबकुछ धीमा है। पहले PHP workers में saturation के लिए check करें। यदि workers pinned हैं, तो किसी भी चीज़ को optimize करने से पहले capacity जोड़ें या प्रति request work कम करें।
Errors zero से ऊपर। इन्हें milliseconds के बाद करने से पहले ठीक करें। अपने logs के साथ शुरुआत करें, और साइट के Error pages टैब पर Troubleshoot with Kora बटन का उपयोग करें, जो Kora से आपने error logs और हाल की failures को पढ़ने के लिए कहता है। Custom Error Pages देखें।
संबंधित पृष्ठ
- Site Caching आमतौर पर WordPress साइट के लिए सबसे बड़ा single win है।
- Site Security एक ही साइट पर vulnerability और malware scanning के लिए।
- Taking a Backup plugins को हटाना शुरू करने से पहले।