JMH और Maven से JVM परफ़ॉर्मेंस मापना

LogoRRR ने Scala प्रोजेक्ट में Maven के साथ JMH जोड़कर JVM के हॉट पाथ को दोहराए जा सकने वाले ढंग से कैसे मापा और एक अहम कोड पाथ का थ्रूपुट दोगुने से भी अधिक किया।

JMH और Maven से JVM परफ़ॉर्मेंस मापना के लिए प्रमुख चित्र

रिलीज़ 24.3.0 ने LogoRRR के कोडबेस में JMH बेंचमार्किंग का सपोर्ट जोड़ा।

JMH , यानी Java Microbenchmark Harness, JVM पर परफ़ॉर्मेंस मापने का मानक टूल है। बड़ी फ़ाइल प्रोसेस करते समय LogoRRR हर रन में लॉग की अलग-अलग लाइनों पर लाखों बार काम करता है। इसलिए उसके कुछ अंदरूनी लूप वास्तव में परफ़ॉर्मेंस के लिहाज़ से अहम हैं। ऐसे बार-बार चलने वाले कोड पाथ के लिए JMH भरोसेमंद और दोहराए जा सकने वाले माप देता है।

सेटअप

LogoRRR Scala में लिखा गया है, लेकिन बिल्ड के लिए Maven इस्तेमाल करता है। यह मेल कुछ असामान्य है, फिर भी इस प्रोजेक्ट में अच्छी तरह काम करता है। मानक Maven archetype से JMH सेट अप करना सीधा रहा। बेंचमार्क Java में लिखे गए हैं और Scala कोडबेस ऐसे साफ़ entry point देता है जिन्हें वे सीधे कॉल कर सकते हैं।

छोटा और स्वतंत्र उदाहरण चाहिए तो सार्वजनिक jmh-maven-example repository देखें। यह JDK 25, Maven और JMH का सामान्य-purpose, MIT-licensed open-source प्रोजेक्ट है। इसमें LogoRRR का कोई कोड नहीं है। LogoRRR एक अलग application है और open source नहीं है।

नतीजे

काम शुरू करते समय यह मान लिया गया था कि फ़ाइल लोड होने पर बहुत बार कॉल किया जाने वाला एक फ़ंक्शन पहले ही पर्याप्त तेज़ है। JMH के माप ने इस धारणा को गलत साबित किया। माप और optimisation के कई दौरों के बाद उस अहम फ़ंक्शन का थ्रूपुट दोगुने से भी अधिक हो गया। बेंचमार्क का उद्देश्य यही है: अनुमान की जगह डेटा देना।

LogoRRR इस बदलाव से पहले भी बड़ी लॉग फ़ाइलें संभाल सकता था। अब वह उन्हें और तेज़ी से प्रोसेस करता है, और भविष्य की रिलीज़ में regression पकड़ने के लिए मापने की बुनियाद भी मौजूद है।

परफ़ॉर्मेंस के दो अलग प्रमाण

JMH microbenchmarking का टूल है। यह JVM के अलग-थलग, बार-बार चलने वाले hot path को मापता है और उनके बारे में बनी धारणाओं की जाँच करता है। इसके नतीजे diagnosis में काम आते हैं, लेकिन वे पूरे product के अलग-अलग version की तुलना करने वाला release gate नहीं हैं।

इसीलिए LogoRRR हर release candidate और हर stable release के लिए एक अलग performance report भी बनाता है। इसमें implementation से स्वतंत्र product scenario मापे जाते हैं, जैसे फ़ाइल खुलने से view तैयार होने तक और search शुरू होने से नतीजे दिखने तक का समय। ये मेट्रिक अलग-अलग version में तुलना योग्य रहते हैं और CI तथा release pipeline में performance regression रोकने का gate बनते हैं।

Product report और JMH के नतीजे अलग evidence के रूप में रखे जाते हैं। पहला हर रिलीज़ के साथ user experience की रक्षा करता है; दूसरा अहम hot path की परफ़ॉर्मेंस समझने और तकनीकी धारणाओं को जाँचने में मदद करता है।

JMH जैसे टूल बताते हैं कि वास्तव में क्या काम करता है और दोहराए जा सकने वाले नतीजे देते हैं।

फ़ोटो: Pexels पर Nathan Salt