परफ़ॉर्मेंस की जांच करना

Android 8.0 में थ्रूपुट और इंतज़ार का समय. हालांकि, साफ़ तौर पर दिखने वाले परफ़ॉर्मेंस का पता लगाने के कई मामले होते हैं समस्याओं को हल करने में बहुत ज़्यादा समय लग सकता है और इस तरह के नतीजे अक्सर उपलब्ध नहीं है. दी गई परफ़ॉर्मेंस का इस्तेमाल किया जा रहा है होने वाले टेस्ट से डेवलपमेंट के दौरान टेस्ट करना, गंभीर समस्याओं का पता लगाना आसान हो जाता है और उपयोगकर्ता अनुभव को बेहतर बनाने के लिए किया जा सकता है.

परफ़ॉर्मेंस की जांच में ये चार कैटगरी शामिल होती हैं:

• बाइंडर थ्रूपुट (इसमें उपलब्ध है system/libhwbinder/vts/performance/Benchmark_binder.cpp)
• बाइंडर लेटेंसी (इसमें उपलब्ध है frameworks/native/libs/binder/tests/schd-dbg.cpp)
• hwbinder थ्रूपुट (यहां उपलब्ध है system/libhwbinder/vts/performance/Benchmark.cpp)
• hwbinder प्रतीक्षा अवधि (इसमें उपलब्ध है system/libhwbinder/vts/performance/Latency.cpp)

बाइंडर और hwbinder के बारे में

बाइंडर और hwbinder, Android इंटर-प्रोसेस कम्यूनिकेशन (IPC) हैं ऐसी संरचना जो एक ही Linux ड्राइवर शेयर करती हो, लेकिन जिसमें नीचे दी गई चीज़ें हों क्वालिटी में अंतर:

पक्ष	बाइंडर	Hwbinder
मकसद	फ़्रेमवर्क के लिए, अलग-अलग कामों के लिए इस्तेमाल की जाने वाली आईपीसी स्कीम बताना	हार्डवेयर से बातचीत करें
प्रॉपर्टी	Android फ़्रेमवर्क के इस्तेमाल के लिए ऑप्टिमाइज़ किया गया	कम से कम ओवरहेड कम इंतज़ार का समय
फ़ोरग्राउंड/बैकग्राउंड के लिए शेड्यूल करने की नीति बदलें	हां	नहीं
पास होने वाले तर्क	पार्सल ऑब्जेक्ट के साथ काम करने वाले सीरियलाइज़ेशन का इस्तेमाल करता है	स्कैटर बफ़र का इस्तेमाल करता है और डेटा कॉपी करने के लिए ओवरहेड से बचाता है पार्सल को क्रम से लगाना
प्राथमिकता इनहेरिटेंस	नहीं	हां

बाइंडर और hwbinder प्रोसेस

सिस्टम ट्रेस विज़ुअलाइज़र, लेन-देन को इस तरह दिखाता है:

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

पहली इमेज. बाइंडर का सिस्ट्रेस विज़ुअलाइज़ेशन प्रोसेस भी शामिल हैं.

ऊपर दिए गए उदाहरण में:

• चार (4) schd-dbg प्रोसेस, क्लाइंट की प्रोसेस हैं.
• चार (4) बाइंडर प्रोसेस, सर्वर प्रोसेस हैं (नाम इससे शुरू होता है) बाइंडर और क्रम संख्या पर खत्म होता है.
• क्लाइंट प्रोसेस को हमेशा एक सर्वर प्रोसेस के साथ जोड़ा जाता है, जो उसके क्लाइंट से कनेक्ट करने में मदद करता है.
• सभी क्लाइंट-सर्वर प्रोसेस पेयर को कर्नेल की मदद से, अलग से शेड्यूल किया जाता है एक साथ.

सीपीयू 1 में, ओएस कर्नेल, अनुरोध जारी करने के लिए क्लाइंट को एक्ज़ीक्यूट करता है. यह तब जब भी संभव हो, तो सर्वर प्रोसेस को सक्रिय करने के लिए समान CPU का उपयोग करता है, का विकल्प होता है और अनुरोध पूरा होने के बाद संदर्भ वापस स्विच हो जाता है.

थ्रूपुट बनाम इंतज़ार का समय

सही ट्रांज़ैक्शन में, जहां क्लाइंट और सर्वर की प्रोसेस आपस में बदल जाती है बिना किसी रुकावट के, थ्रूपुट और लेटेंसी टेस्ट से आपको ज़्यादा अलग-अलग मैसेज. हालांकि, जब ओएस कर्नेल किसी रुकावट के अनुरोध (आईआरक्यू) को हैंडल कर रहा हो हार्डवेयर से लेकर, लॉक का इंतज़ार करना या किसी मैसेज को हैंडल न करने का विकल्प चुनना तो एक इंतज़ार का समय बुलबुला बन सकता है.

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

दूसरी इमेज. अंतर की वजह से, इंतज़ार का समय दिखाने वाला बबल डेटा ट्रांसफ़र और इंतज़ार का समय.

थ्रूपुट टेस्ट, अलग-अलग तरीकों से कई ट्रांज़ैक्शन जनरेट करता है पेलोड के साइज़, जो नियमित लेन-देन के समय का अच्छा अनुमान देते हैं ( के उदाहरण) और बाइंडर की ओर से हासिल किए जा सकने वाले ज़्यादा से ज़्यादा थ्रूपुट को हासिल किया जा सकता है.

वहीं दूसरी ओर, इंतज़ार का समय कम करने के लिए पेलोड पर कोई कार्रवाई नहीं करता सामान्य लेन-देन का समय. हम बाइंडर का अनुमान लगाने के लिए लेन-देन के समय का इस्तेमाल कर सकते हैं सबसे खराब स्थिति के आंकड़े बनाने के लिए, और वे लेन-देन जिनके इंतज़ार का समय तय समयसीमा को पूरा करता है.

प्राथमिकता में बदलाव करने की सुविधा को मैनेज करना

प्राथमिकता व्युत्क्रम तब होता है जब ज़्यादा प्राथमिकता वाला थ्रेड तार्किक रूप से होता है कम प्राथमिकता वाली थ्रेड का इंतज़ार कर रहे हैं. रीयल-टाइम (RT) ऐप्लिकेशन में एक प्राथमिकता व्युत्क्रमण समस्या:

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

तीसरी इमेज. रीयल-टाइम में प्राथमिकता व्युत्क्रमण ऐप्लिकेशन चुनें.

Linux कंप्लीटली फ़ेयर शेड्यूलर (सीएफ़एस) शेड्यूलिंग का इस्तेमाल करते समय, हमेशा थ्रेड तब भी चल सकता है, जब दूसरे थ्रेड की प्राथमिकता ज़्यादा होती है. इस वजह से, सीएफ़एस शेड्यूलिंग वाले ऐप्लिकेशन, प्राथमिकता में बदलाव को उम्मीद के मुताबिक मैनेज करते हैं न कि समस्या की तरह. ऐसे मामलों में जहां Android फ़्रेमवर्क को आरटी शेड्यूलिंग की ज़रूरत होती है हालांकि, ज़्यादा प्राथमिकता वाले थ्रेड के अधिकार की गारंटी के लिए, प्राथमिकता बदलने की सुविधा को हल करना ज़रूरी है.

बाइंडर लेन-देन के दौरान प्राथमिकता बदलने का उदाहरण (आरटी थ्रेड यह है बाइंडर थ्रेड का इंतज़ार करते समय, दूसरे सीएफ़एस थ्रेड से लॉजिकल तरीके से ब्लॉक किया गया सेवा):

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

चौथी इमेज. प्राथमिकता व्युत्क्रम, रीयल-टाइम ब्लॉक किया गया थ्रेड.

रुकावटों से बचने के लिए, प्रायॉरिटी इनहेरिटेंस का इस्तेमाल किया जा सकता है, ताकि जल्द ही किसी आरटी क्लाइंट से अनुरोध करने पर, बाइंडर थ्रेड को आरटी थ्रेड में जोड़ा जाता है. ध्यान रखें कि आरटी शेड्यूलिंग में सीमित संसाधन होते हैं और इसका इस्तेमाल किया जाना चाहिए करते हैं. n सीपीयू वाले सिस्टम में, मौजूदा आरटी की ज़्यादा से ज़्यादा संख्या थ्रेड n भी है; अतिरिक्त आरटी थ्रेड को इंतज़ार करना पड़ सकता है (और इसलिए समय सीमा पूरी नहीं हो पाती है) अगर सभी सीपीयू अन्य आरटी थ्रेड से लिए जाते हैं.

प्राथमिकता में बदलाव की सभी संभावित समस्याओं को हल करने के लिए, प्राथमिकता का इस्तेमाल किया जा सकता है बाइंडर और hwbinder, दोनों के लिए इनहेरिटेंस. हालांकि, बाइंडर का काफ़ी इस्तेमाल होता है बाइंडर ट्रांज़ैक्शन के लिए, प्रायॉरिटी इनहेरिटेंस चालू करने से आरटी थ्रेड से सिस्टम को स्पैम के तौर पर मार्क करना.

थ्रूपुट टेस्ट चलाना

थ्रूपुट टेस्ट, binder/hwbinder ट्रांज़ैक्शन थ्रूपुट के हिसाब से किया जाता है. तय सीमा में यह एक ऐसे सिस्टम पर काम करता है जो ओवरलोड नहीं होता, लेकिन लेटेंसी बबल काफ़ी कम बार दिखते हैं और उनका असर को खत्म किया जा सकता है, बशर्ते बार-बार दोहराए जाने की संख्या काफ़ी ज़्यादा हो.

• बाइंडर थ्रूपुट टेस्ट system/libhwbinder/vts/performance/Benchmark_binder.cpp.
• hwbinder थ्रूपुट टेस्ट इसमें है system/libhwbinder/vts/performance/Benchmark.cpp.

परीक्षण के नतीजे

अलग-अलग पेलोड का इस्तेमाल करके किए गए लेन-देन के लिए, थ्रूपुट टेस्ट के नतीजों का उदाहरण आकार:

Benchmark                      Time          CPU           Iterations
---------------------------------------------------------------------
BM_sendVec_binderize/4         70302 ns      32820 ns      21054
BM_sendVec_binderize/8         69974 ns      32700 ns      21296
BM_sendVec_binderize/16        70079 ns      32750 ns      21365
BM_sendVec_binderize/32        69907 ns      32686 ns      21310
BM_sendVec_binderize/64        70338 ns      32810 ns      21398
BM_sendVec_binderize/128       70012 ns      32768 ns      21377
BM_sendVec_binderize/256       69836 ns      32740 ns      21329
BM_sendVec_binderize/512       69986 ns      32830 ns      21296
BM_sendVec_binderize/1024      69714 ns      32757 ns      21319
BM_sendVec_binderize/2k        75002 ns      34520 ns      20305
BM_sendVec_binderize/4k        81955 ns      39116 ns      17895
BM_sendVec_binderize/8k        95316 ns      45710 ns      15350
BM_sendVec_binderize/16k      112751 ns      54417 ns      12679
BM_sendVec_binderize/32k      146642 ns      71339 ns       9901
BM_sendVec_binderize/64k      214796 ns     104665 ns       6495

• समय, रीयल टाइम में मेज़र की गई दोतरफ़ा यात्रा में हुई देरी को दिखाता है.
• सीपीयू से, इकट्ठा किए गए उस समय की जानकारी मिलती है जो सीपीयू को शेड्यूल करने के लिए शेड्यूल किया जाता है का विकल्प चुना गया है.
• इटरेशन से पता चलता है कि टेस्ट फ़ंक्शन कितनी बार ट्रिगर हुआ लागू किया गया.

उदाहरण के लिए, 8-बाइट वाले पेलोड के लिए:

BM_sendVec_binderize/8         69974 ns      32700 ns      21296

... बाइंडर से मिलने वाली ज़्यादा से ज़्यादा थ्रूपुट वैल्यू का हिसाब इस तरह से लगाया जाता है:

8-बाइट पेलोड के साथ MAX थ्रूपुट = (8 * 21296)/69974 ~= 2.423 b/ns ~= 2.268 जीबी/सेकंड

परीक्षण के विकल्प

.json में नतीजे पाने के लिए, इसकी मदद से जांच करें --benchmark_format=json आर्ग्युमेंट:

libhwbinder_benchmark --benchmark_format=json
{
  "context": {
    "date": "2017-05-17 08:32:47",
    "num_cpus": 4,
    "mhz_per_cpu": 19,
    "cpu_scaling_enabled": true,
    "library_build_type": "release"
  },
  "benchmarks": [
    {
      "name": "BM_sendVec_binderize/4",
      "iterations": 32342,
      "real_time": 47809,
      "cpu_time": 21906,
      "time_unit": "ns"
    },
   ….
}

इंतज़ार के समय की जांच करना

इंतज़ार के समय की जांच से यह पता चलता है कि क्लाइंट के काम शुरू करने में कितना समय लगता है ट्रांज़ैक्शन शुरू करते समय, हैंडलिंग के लिए सर्वर प्रोसेस पर जाएं और तो आपको नतीजा मिल जाएगा. यह टेस्ट ऐसे खराब शेड्यूलर व्यवहार की भी जांच करता है जो लेन-देन में लगने वाले समय पर बुरा असर डाल सकता है. जैसे, शेड्यूलर इनहेरिटेंस के लिए सहायता करता है या सिंक फ़्लैग का पालन करता है.

• बाइंडर लेटेंसी टेस्ट frameworks/native/libs/binder/tests/schd-dbg.cpp.
• hwbinder इंतज़ार अवधि परीक्षण system/libhwbinder/vts/performance/Latency.cpp.

परीक्षण के नतीजे

नतीजे (.json में) औसत/सबसे अच्छे/सबसे खराब इंतज़ार के समय और तय नहीं हो पाया.

परीक्षण के विकल्प

इंतज़ार के समय की जांच में ये विकल्प इस्तेमाल किए जाते हैं:

निर्देश	ब्यौरा
-i value	दोहराव की संख्या बताएं.
-pair value	प्रोसेस पेयर की संख्या बताएं.
-deadline_us 2500	समयसीमा के बारे में हमें बताएं.
-v	ज़्यादा शब्दों में (डीबग करना) आउटपुट पाएं.
-trace	समयसीमा खत्म होने पर ट्रेस को रोकें.

नीचे दिए गए सेक्शन में, हर विकल्प के बारे में बताया गया है. साथ ही, विकल्प और उनके इस्तेमाल के बारे में बताया गया है उदाहरण के तौर पर दिए गए नतीजे.

बार-बार इस्तेमाल करने की सुविधा चुनें

बड़ी संख्या में बार-बार दोहराने और वर्बोस आउटपुट को बंद करने का उदाहरण:

libhwbinder_latency -i 5000 -pair 3
{
"cfg":{"pair":3,"iterations":5000,"deadline_us":2500},
"P0":{"SYNC":"GOOD","S":9352,"I":10000,"R":0.9352,
  "other_ms":{ "avg":0.2 , "wst":2.8 , "bst":0.053, "miss":2, "meetR":0.9996},
  "fifo_ms": { "avg":0.16, "wst":1.5 , "bst":0.067, "miss":0, "meetR":1}
},
"P1":{"SYNC":"GOOD","S":9334,"I":10000,"R":0.9334,
  "other_ms":{ "avg":0.19, "wst":2.9 , "bst":0.055, "miss":2, "meetR":0.9996},
  "fifo_ms": { "avg":0.16, "wst":3.1 , "bst":0.066, "miss":1, "meetR":0.9998}
},
"P2":{"SYNC":"GOOD","S":9369,"I":10000,"R":0.9369,
  "other_ms":{ "avg":0.19, "wst":4.8 , "bst":0.055, "miss":6, "meetR":0.9988},
  "fifo_ms": { "avg":0.15, "wst":1.8 , "bst":0.067, "miss":0, "meetR":1}
},
"inheritance": "PASS"
}

जांच के इन नतीजों में यह जानकारी दिखती है:

"pair":3

क्लाइंट और सर्वर की एक जोड़ी बनाता है.

"iterations": 5000

इसमें 5,000 बार इस्तेमाल किए जा सकते हैं.

"deadline_us":2500

तय समयसीमा 2,500 हमसे (2.5 मि॰से॰) है; ज़्यादातर लेन-देन इस लक्ष्य को पूरा कर सकते हैं वैल्यू.

"I": 10000

एक टेस्ट में दो (2) लेन-देन शामिल होते हैं:

• सामान्य प्राथमिकता के हिसाब से एक लेन-देन (CFS other)
• रीयल टाइम प्राथमिकता के हिसाब से एक लेन-देन (RT-fifo)

5,000 बार-बार बदलने का मतलब है, कुल 10,000 लेन-देन.

"S": 9352

9352 लेन-देन एक ही सीपीयू में सिंक किए जाते हैं.

"R": 0.9352

इससे पता चलता है कि क्लाइंट और सर्वर को एक साथ किस अनुपात में सिंक किया गया है एक ही सीपीयू है.

"other_ms":{ "avg":0.2 , "wst":2.8 , "bst":0.053, "miss":2, "meetR":0.9996}

औसत (avg), सबसे खराब (wst), और सबसे अच्छा स्कोर (bst) केस, सामान्य प्रायॉरिटी कॉलर की ओर से जारी किए गए सभी लेन-देन के लिए है. दो लेन-देन miss करने की आखिरी तारीख है, जिससे ग्राहकों को मिलने वाले रेवेन्यू का अनुपात तय होता है (meetR) 0.9996.

"fifo_ms": { "avg":0.16, "wst":1.5 , "bst":0.067, "miss":0, "meetR":1}

other_ms के समान, लेकिन के साथ क्लाइंट के जारी किए गए लेन-देन के लिए rt_fifo प्राथमिकता. यह संभव है (लेकिन ज़रूरी नहीं है) कि fifo_ms के लिए, other_ms की तुलना में बेहतर नतीजा मिला है. साथ ही, यह भी कम है avg और wst की वैल्यू और meetR से ज़्यादा वैल्यू (बैकग्राउंड में लोड होने की वजह से, यह अंतर और ज़्यादा हो सकता है).

ध्यान दें: बैकग्राउंड लोड होने से, ऐप्लिकेशन के रेंडर होने में लगने वाले समय पर असर पड़ सकता है इंतज़ार का समय की जांच में other_ms टपल का डेटा दिखता है. सिर्फ़ बैकग्राउंड लोड होने पर, fifo_ms मिलते-जुलते नतीजे दिखा सकता है RT-fifo से कम प्राथमिकता.

पेयर की वैल्यू बताएं

हर क्लाइंट प्रोसेस को एक ऐसी सर्वर प्रोसेस से जोड़ा जाता है जो क्लाइंट के लिए खास तौर पर बनी होती है, और हर जोड़ी को किसी भी सीपीयू के लिए, अलग से शेड्यूल किया जा सकता है. हालांकि, सीपीयू से माइग्रेशन किसी लेन-देन के दौरान तब तक नहीं होना चाहिए, जब तक कि SYNC फ़्लैग honor.

पक्का करें कि सिस्टम ओवरलोड न हो! अगर लोड होने में ज़्यादा समय लग रहा है, तो सिस्टम में उम्मीद है, ओवरलोडेड सिस्टम के लिए जांच के नतीजे काम के नहीं हैं जानकारी. ज़्यादा दबाव वाले सिस्टम की जांच करने के लिए, -pair #cpu-1 या -pair #cpu का इस्तेमाल सावधानी से करें. इसका उपयोग करके परीक्षण करना n > #cpu के साथ -pair n ओवरलोड हो जाता है जो काम की नहीं है.

आखिरी तारीख से जुड़ी वैल्यू बताना

बड़े पैमाने पर उपयोगकर्ता की स्थिति की जांच करने के बाद (इंतज़ार के समय की जांच को क्वालीफ़ाइंग प्रॉडक्ट), हमने तय किया है कि शर्तों को पूरा करने की समयसीमा 2.5 मि॰से॰ है. नए के लिए ज़्यादा ज़रूरतों वाले ऐप्लिकेशन (जैसे कि 1,000 फ़ोटो/सेकंड), यह आखिरी तारीख की वैल्यू बदल जाएगी.

वर्बोस आउटपुट की जानकारी दें

-v विकल्प का इस्तेमाल करने पर, वर्बोस आउटपुट दिखता है. उदाहरण:

libhwbinder_latency -i 1 -v

--------------------------------------------------
service      pid: 8674 tid: 8674 cpu: 1
SCHED_OTHER 0
--------------------------------------------------
main         pid: 8673 tid: 8673 cpu: 1

--------------------------------------------------
client       pid: 8677 tid: 8677 cpu: 0
SCHED_OTHER 0

--------------------------------------------------
fifo-caller  pid: 8677 tid: 8678 cpu: 0
SCHED_FIFO  99

--------------------------------------------------
hwbinder     pid: 8674 tid: 8676 cpu: 0
???         99
--------------------------------------------------
other-caller pid: 8677 tid: 8677 cpu: 0
SCHED_OTHER 0

--------------------------------------------------
hwbinder     pid: 8674 tid: 8676 cpu: 0
SCHED_OTHER 0

• सेवा थ्रेड को इसकी मदद से बनाया जाता है: SCHED_OTHER प्राथमिकता और pid 8674 के साथ CPU:1 में चलाएं.
• इसके बाद, पहला ट्रांज़ैक्शन fifo-caller. इस लेन-देन की सेवा देने के लिए, hwbinder सर्वर (pid: 8674 tid: 8676) की प्राथमिकता 99 है और इसे मार्क भी करता है कुछ समय के लिए शेड्यूलिंग क्लास के साथ (??? के तौर पर प्रिंट किया हुआ). शेड्यूलर इसके बाद सर्वर प्रोसेस को CPU:0 में डालता है और उसे वाला सीपीयू होना चाहिए.
• दूसरा लेन-देन करने वाले (कॉलर) ने SCHED_OTHER प्राथमिकता. सर्वर खुद को डाउनग्रेड करता है और SCHED_OTHER प्राथमिकता वाला कॉलर.

डीबग करने के लिए ट्रेस का इस्तेमाल करें

इंतज़ार के समय से जुड़ी समस्याओं को डीबग करने के लिए, -trace विकल्प तय किया जा सकता है. टास्क कब शुरू होगा इसका इस्तेमाल किया जाता है, तो इंतज़ार का समय खराब होने पर ट्रेसलॉग रिकॉर्डिंग को रोक देता है इंतज़ार के समय का पता चलता है. उदाहरण:

atrace --async_start -b 8000 -c sched idle workq binder_driver sync freq
libhwbinder_latency -deadline_us 50000 -trace -i 50000 -pair 3
deadline triggered: halt ∓ stop trace
log:/sys/kernel/debug/tracing/trace

नीचे दिए गए कॉम्पोनेंट, इंतज़ार के समय पर असर डाल सकते हैं:

• Android बिल्ड मोड. आम तौर पर, Eng मोड इससे धीमा होता है उपयोगकर्ता डीबग मोड.
• फ़्रेमवर्क. फ़्रेमवर्क सेवा का इस्तेमाल कैसे किया जाता है बाइंडर को कॉन्फ़िगर करने के लिए ioctl?
• बाइंडर ड्राइवर. क्या ड्राइवर, गड़बड़ी की पूरी जानकारी देता है लॉक कर रहे हैं? क्या इसमें परफ़ॉर्मेंस को बदलने वाले सभी पैच शामिल हैं?
• Kernel वर्शन. कर्नेल की रीयल-टाइम क्षमता जितनी बेहतर होगी बेहतर नतीजे मिलते हैं.
• Kernel कॉन्फ़िगरेशन. क्या कर्नेल कॉन्फ़िगरेशन में यह शामिल है DEBUG कॉन्फ़िगरेशन, जैसे कि DEBUG_PREEMPT और DEBUG_SPIN_LOCK?
• केरल शेड्यूलर. क्या कर्नेल में एनर्जी-अवेयर है शेड्यूलर (ईएएस) या हेट्रोजेनस मल्टी-प्रोसेसिंग (एचएमपी) शेड्यूलर? कोई भी कर्नेल करें ड्राइवर (cpu-freq ड्राइवर, cpu-idle ड्राइवर, cpu-hotplug वगैरह) से शेड्यूलर पर असर पड़ता है?