रिग्रेशन का पता लगाने के लिए, प्रोडक्शन के दौरान अपने वेब पेज की मेमोरी के इस्तेमाल को मेज़र करने का तरीका जानें.
ब्राउज़र अपने-आप वेब पेजों की मेमोरी को मैनेज करते हैं. जब भी कोई वेब पेज जब कोई ऑब्जेक्ट बनाया जाता है, तो ब्राउज़र "हुड के नीचे" मेमोरी का एक हिस्सा असाइन करता है से उस ऑब्जेक्ट को स्टोर करें. मेमोरी एक सीमित संसाधन है, इसलिए ब्राउज़र गै़रबेज कलेक्शन, ताकि यह पता लगाया जा सके कि कब किसी ऑब्जेक्ट की ज़रूरत नहीं है और वह कब खाली करना है में मिल सकती है.
हालांकि, यह पता लगाना पूरी तरह कारगर नहीं होता और यह सही तरीके से पहचाने नामुमकिन लगा. इसलिए ब्राउज़र "एक ऑब्जेक्ट" की धारणा का अनुमान लगाते हैं ज़रूरी है" जिनका मतलब है कि "कोई ऑब्जेक्ट ऐक्सेस किया जा सकता है". अगर वेब पेज ऐसा नहीं कर सकता किसी ऑब्जेक्ट तक उसके वैरिएबल और पहुंच वाले अन्य ऑब्जेक्ट के फ़ील्ड के ज़रिए पहुंच सकते हैं, तो ब्राउज़र उस ऑब्जेक्ट पर सुरक्षित रूप से फिर से दावा कर सकता है. इनके बीच का अंतर दो नोशन से मेमोरी लीक होती है. इसका उदाहरण नीचे दिया गया है.
const object = {a: new Array(1000), b: new Array(2000)};
setInterval(() => console.log(object.a), 1000);
यहां अब बड़े अरे b
की ज़रूरत नहीं है, लेकिन ब्राउज़र को
इस पर फिर से दावा करें, क्योंकि इसे अब भी कॉलबैक में object.b
से ऐक्सेस किया जा सकता है. इस प्रकार
बड़े अरे की मेमोरी लीक हो गई है.
मेमोरी लीक वेब पर मौजूद हैं. किसी इवेंट लिसनर का रजिस्ट्रेशन रद्द करना भूलकर, कर्मचारी को बंद किए बिना, iframe से गलती से ऑब्जेक्ट कैप्चर कर लेता है, अरे में ऑब्जेक्ट को इकट्ठा करना वगैरह. अगर किसी वेब पेज में मेमोरी लीक होती है, तो समय के साथ इसकी मेमोरी का इस्तेमाल बढ़ता है और वेब पेज धीरे दिखता है और का इस्तेमाल करने के लिए प्रेरित होते हैं.
इस समस्या को हल करने के लिए, सबसे पहले इसका आकलन करना होता है. नया
performance.measureUserAgentSpecificMemory()
API की मदद से डेवलपर ये काम कर सकते हैं
प्रोडक्शन में वेब पेजों की मेमोरी के इस्तेमाल को मापते हैं और इस तरह मेमोरी का पता लगाते हैं
जो स्थानीय स्तर पर जांच किए जाते हैं.
performance.measureUserAgentSpecificMemory()
, performance.memory
एपीआई के लेगसी एपीआई से किस तरह अलग है?
अगर आपको मौजूदा नॉन-स्टैंडर्ड performance.memory
एपीआई के बारे में जानकारी है, तो
ऐसा हो सकता है कि आप यह जानना चाहें कि नया एपीआई इससे अलग कैसे है. मुख्य अंतर यह है
पुराना एपीआई, JavaScript हीप का साइज़ दिखाता है, जबकि नया एपीआई
वेब पेज में इस्तेमाल की गई मेमोरी का अनुमान लगाता है. यह अंतर बन जाता है
जब Chrome एक ही तरह के कई वेब पेजों को एक साथ शेयर करता है, तो
एक ही वेब पेज के कई इंस्टेंस). ऐसे मामलों में, पुरानी जांच का नतीजा
ऐसा हो सकता है कि एपीआई को मनचाहे तरीके से बंद किया जाए. पुराना एपीआई
खास तौर पर लागू करने से संबंधित शर्तें, जैसे "हीप".
दूसरा अंतर यह है कि नया एपीआई गार्बेज कलेक्शन. यह नतीजों में मौजूद ग़ैर-ज़रूरी आवाज़ों को कम करता है, लेकिन तब तक इंतज़ार करें, जब तक नतीजे नहीं आ जाते. ध्यान दें कि अन्य ब्राउज़र कचरे के कलेक्शन की ज़रूरत के बिना, नए एपीआई को लागू किया जा सकता है.
इस्तेमाल के सुझाए गए उदाहरण
किसी वेब पेज के इस्तेमाल की जानकारी, इवेंट के समय, उपयोगकर्ता की कार्रवाइयों, और गार्बेज कलेक्शन. इसलिए, मेमोरी मेज़रमेंट एपीआई का मकसद प्रोडक्शन से मेमोरी के इस्तेमाल से जुड़ा डेटा इकट्ठा किया जा सकता है. अलग-अलग कॉल के नतीजे कम उपयोगी हैं. इस्तेमाल के उदाहरणों के उदाहरण:
- नई मेमोरी लीक को पकड़ने के लिए वेब पेज का नया वर्शन लॉन्च करने के दौरान रिग्रेशन का पता लगाना.
- नई सुविधा की A/B टेस्टिंग, ताकि मेमोरी के असर का आकलन किया जा सके और मेमोरी में होने वाली गड़बड़ियों का पता लगाया जा सके.
- मेमोरी के इस्तेमाल को सेशन की अवधि से जोड़कर, मेमोरी लीक होने की मौजूदगी या गैर-मौजूदगी की पुष्टि की जा सकती है.
- मेमोरी के इस्तेमाल से पड़ने वाले असर को समझने के लिए, मेमोरी के इस्तेमाल को उपयोगकर्ता मेट्रिक से जोड़ना.
ब्राउज़र के साथ काम करना
ब्राउज़र सहायता
- अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
- अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
- अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
- अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
फ़िलहाल, यह एपीआई सिर्फ़ Chromium पर काम करने वाले ब्राउज़र और Chrome 89 और इसके बाद के वर्शन में काम करता है. कॉन्टेंट बनाने का परिणाम पूरी तरह से लागू करने पर निर्भर होता है, क्योंकि ब्राउज़र में मेमोरी में ऑब्जेक्ट को दर्शाने के अलग-अलग तरीक़े और मेमोरी के इस्तेमाल का अनुमान लगा रहा है. ब्राउज़र कुछ मेमोरी क्षेत्र को यहां से बाहर रख सकते हैं अकाउंटिंग के लिए. इस तरह, नतीजे की तुलना सभी ब्राउज़र पर नहीं की जा सकती. इस बात की तुलना करना कि सिर्फ़ उसी ब्राउज़र के लिए परिणाम.
performance.measureUserAgentSpecificMemory()
का इस्तेमाल करना
सुविधा की पहचान
performance.measureUserAgentSpecificMemory
फ़ंक्शन उपलब्ध नहीं होगा या हो सकता है
अगर प्रोग्राम चलाने का एनवायरमेंट पूरा नहीं होता है, तो SecurityError से जुड़ी गड़बड़ी हो सकती है
क्रॉस-ऑरिजिन जानकारी लीक को रोकने के लिए सुरक्षा से जुड़ी ज़रूरी शर्तें.
यह क्रॉस-ऑरिजिन आइसोलेशन पर निर्भर करता है, जिसे कोई वेब पेज चालू कर सकता है
COOP+COEP हेडर सेट करें.
रनटाइम के दौरान, काम करने वाली सुविधाओं का पता लगाया जा सकता है:
if (!window.crossOriginIsolated) {
console.log('performance.measureUserAgentSpecificMemory() is only available in cross-origin-isolated pages');
} else if (!performance.measureUserAgentSpecificMemory) {
console.log('performance.measureUserAgentSpecificMemory() is not available in this browser');
} else {
let result;
try {
result = await performance.measureUserAgentSpecificMemory();
} catch (error) {
if (error instanceof DOMException && error.name === 'SecurityError') {
console.log('The context is not secure.');
} else {
throw error;
}
}
console.log(result);
}
लोकल टेस्टिंग
ग़ैर-ज़रूरी चीज़ें इकट्ठा करने के दौरान, Chrome मेमोरी की माप करता है. इसका मतलब है कि कि एपीआई, नतीजे में किए गए वादे को तुरंत ठीक नहीं करता है और इसके बजाय इंतज़ार करता है कचरा इकट्ठा करने का फ़ैसला लेने में मदद मिलती है.
एपीआई को कॉल करने से कुछ टाइम आउट के बाद, गै़रबेज कलेक्शन की प्रक्रिया शुरू हो जाती है. इसका मतलब है कि
अभी 20 सेकंड पर सेट है, हालाँकि यह इससे पहले ही हो सकता है. Chrome को
--enable-blink-features='ForceEagerMeasureMemory'
कमांड लाइन फ़्लैग को छोटा किया जाता है
टाइम आउट को शून्य पर सेट करता है और यह लोकल डीबगिंग और टेस्टिंग के लिए काम का होता है.
उदाहरण
हम एपीआई के इस्तेमाल का सुझाव देते हैं कि आप ऐसा ग्लोबल मेमोरी मॉनिटर तय करें जो
पूरे वेब पेज की मेमोरी के इस्तेमाल का सैंपल देता है और नतीजों को सर्वर पर भेजता है
का इस्तेमाल कर सकते हैं. सबसे आसान तरीका है कि समय-समय पर
हर M
मिनट में उदाहरण. हालांकि, इससे डेटा में पूर्वाग्रह होता है, क्योंकि
सैंपल के बीच, मेमोरी में उतार-चढ़ाव देखने को मिल सकता है.
नीचे दिए गए उदाहरण में, पॉइसन प्रोसेस का इस्तेमाल करके, निष्पक्ष मेमोरी का आकलन किया जाता है. यह गारंटी देती है कि सैंपल किसी भी समय समान रूप से घटित होने की संभावना है (डेमो, सोर्स).
सबसे पहले, ऐसा फ़ंक्शन तय करें जो इसका इस्तेमाल करके अगली मेमोरी मेज़रमेंट को शेड्यूल करता है
किसी भी क्रम में लगाए गए इंटरवल के साथ setTimeout()
.
function scheduleMeasurement() {
// Check measurement API is available.
if (!window.crossOriginIsolated) {
console.log('performance.measureUserAgentSpecificMemory() is only available in cross-origin-isolated pages');
console.log('See https://web.dev/coop-coep/ to learn more')
return;
}
if (!performance.measureUserAgentSpecificMemory) {
console.log('performance.measureUserAgentSpecificMemory() is not available in this browser');
return;
}
const interval = measurementInterval();
console.log(`Running next memory measurement in ${Math.round(interval / 1000)} seconds`);
setTimeout(performMeasurement, interval);
}
measurementInterval()
फ़ंक्शन, मिलीसेकंड में रैंडम इंटरवल का हिसाब लगाता है
और हर पांच मिनट में औसतन एक मेज़रमेंट होता है. घातांकीय देखें
डिस्ट्रिब्यूशन का इस्तेमाल करें.
function measurementInterval() {
const MEAN_INTERVAL_IN_MS = 5 * 60 * 1000;
return -Math.log(Math.random()) * MEAN_INTERVAL_IN_MS;
}
आखिर में, एक साथ काम नहीं करने वाला performMeasurement()
फ़ंक्शन, एपीआई को शुरू करता है,
परिणाम और अगले माप को शेड्यूल करता है.
async function performMeasurement() {
// 1. Invoke performance.measureUserAgentSpecificMemory().
let result;
try {
result = await performance.measureUserAgentSpecificMemory();
} catch (error) {
if (error instanceof DOMException && error.name === 'SecurityError') {
console.log('The context is not secure.');
return;
}
// Rethrow other errors.
throw error;
}
// 2. Record the result.
console.log('Memory usage:', result);
// 3. Schedule the next measurement.
scheduleMeasurement();
}
आखिर में, मेज़र करना शुरू करें.
// Start measurements.
scheduleMeasurement();
नतीजा ऐसा दिख सकता है:
// Console output:
{
bytes: 60_100_000,
breakdown: [
{
bytes: 40_000_000,
attribution: [{
url: 'https://example.com/',
scope: 'Window',
}],
types: ['JavaScript']
},
{
bytes: 20_000_000,
attribution: [{
url: 'https://example.com/iframe',
container: {
id: 'iframe-id-attribute',
src: '/iframe',
},
scope: 'Window',
}],
types: ['JavaScript']
},
{
bytes: 100_000,
attribution: [],
types: ['DOM']
},
],
}
मेमोरी के इस्तेमाल का कुल अनुमानित डेटा, bytes
फ़ील्ड में दिखाया जाता है. यह मान है
यह पूरी तरह लागू करने पर निर्भर करता है. साथ ही, इसकी तुलना सभी ब्राउज़र पर नहीं की जा सकती. यह हो सकता है
एक ही ब्राउज़र के अलग-अलग वर्शन के बीच भी बदलाव कर सकते हैं. वैल्यू में ये शामिल हैं
सभी iframe, संबंधित विंडो, और वेब कर्मियों की JavaScript और DOM मेमोरी
मौजूदा प्रक्रिया है.
breakdown
सूची में, इस्तेमाल की गई मेमोरी के बारे में ज़्यादा जानकारी मिलती है. हर
एंट्री, मेमोरी के कुछ हिस्से के बारे में बताती है और उसे
विंडो, iframe, और वर्कर को यूआरएल से पहचाना जा सकता है. types
फ़ील्ड में,
मेमोरी से जुड़े खास मेमोरी टाइप को लागू करने के लिए.
यह ज़रूरी है कि सभी सूचियों को एक सामान्य तरीके से प्रोसेस किया जाए और हार्डकोड न किया जाए
के आकलन के लिए इस्तेमाल किया जाता है. उदाहरण के लिए, कुछ ब्राउज़र में
कोई खाली breakdown
या खाली attribution
देना. अन्य ब्राउज़र हो सकते हैं
attribution
में एक से ज़्यादा एंट्री दिखाएं, जो बताती हैं कि उन्हें अलग नहीं किया जा सकता
इनमें से किस एंट्री में मेमोरी का मालिकाना हक है.
सुझाव/राय दें या शिकायत करें
वेब परफ़ॉर्मेंस कम्यूनिटी ग्रुप और Chrome टीम को
के साथ अपने विचारों और अनुभवों के बारे में जानें
performance.measureUserAgentSpecificMemory()
.
हमें एपीआई के डिज़ाइन के बारे में बताएं
क्या एपीआई के बारे में कुछ ऐसा है जो उम्मीद के मुताबिक काम नहीं करता? या ऐसे हैं क्या प्रॉपर्टी मौजूद नहीं हैं? इस पर, स्पेसिफ़िकेशन से जुड़ी समस्या दर्ज करें performance.measureUserAgentspecificMemory() GitHub रेपो या जोड़ें किसी समस्या के बारे में अपने विचार बताएं.
लागू करने से जुड़ी समस्या की शिकायत करना
क्या आपको Chrome को लागू करने में कोई गड़बड़ी मिली? या, लागू करने पर
क्या यह स्पेसिफ़िकेशन से अलग है? new.crbug.com पर जाकर, गड़बड़ी की शिकायत करें. कृपया
ज़्यादा से ज़्यादा जानकारी दें और जवाब तैयार करने के आसान निर्देश दें
और अपने कॉम्पोनेंट को Blink>PerformanceAPIs
पर सेट कर लिया है.
Glitch, जल्दी और आसान रेप्रस शेयर करने के लिए शानदार काम करता है.
सपोर्ट करें
क्या आपको performance.measureUserAgentSpecificMemory()
का इस्तेमाल करना है? आपका सार्वजनिक समर्थन
Chrome टीम को सुविधाओं को प्राथमिकता देने में सहायता करती है और अन्य ब्राउज़र वेंडर को यह बताती है कि
बेहद ज़रूरी है, ताकि उन्हें उनकी मदद की जा सके. @ChromiumDev को ट्वीट भेजें
और हमें बताएं कि उसका इस्तेमाल कहां और कैसे किया जा रहा है.
मददगार लिंक
- पूरी जानकारी देने वाला वीडियो
- डेमोग्राफ़िक जानकारी | डेमो सोर्स
- गड़बड़ी ट्रैक करना
- ChromeStatus.com एंट्री
- ऑरिजिन ट्रायल एपीआई के बाद हुए बदलाव
- ऑरिजिन ट्रायल पूरा हो चुका है
स्वीकार की गई
एपीआई के डिज़ाइन की समीक्षा करने के लिए, डोमेनिक डेनिकोला, योव वाइस, मथायस बायनेंस का बहुत-बहुत धन्यवाद. और कोड की समीक्षा के लिए डॉमिनिक इन्फ़्युअर, हैनिस पेयर, केंटारो हारा, माइकल लिपॉट्ज़ Chrome में. मैं हर पार्कर, फ़िलिप वाइस, ओल्गा बेलोमेस्निख, मैथ्यू को भी धन्यवाद देता हूं बोलोहान और नील मैके ने लोगों से काफ़ी अहम सुझाव, शिकायत या राय शेयर की. एपीआई को बेहतर बनाया है.