💂🏼 🏀 👔 GraalVM पर एक उपयोगिता विकसित करें 🧑🏾‍🤝‍🧑🏼 🙍🏻 🧛🏿

समस्या का बयान

समय-समय पर, मेरे पास एक स्थानीय नेटवर्क पर फ़ाइलें साझा करने का एक कार्य है, उदाहरण के लिए, एक परियोजना सहयोगी के साथ।

इसके लिए कई समाधान हो सकते हैं - सांबा / एफ़टीपी / एससीपी। आप बस Google ड्राइव जैसी सार्वजनिक जगह पर फ़ाइल अपलोड कर सकते हैं, इसे जीरा में एक कार्य के लिए संलग्न कर सकते हैं, या ईमेल द्वारा भी भेज सकते हैं।

लेकिन यह सब, एक डिग्री या किसी अन्य के लिए, अनम्य है, कहीं न कहीं इसे प्रारंभिक समायोजन की आवश्यकता है और इसकी अपनी सीमाएं हैं (उदाहरण के लिए, अधिकतम निवेश आकार)।

और आप कुछ अधिक हल्का और लचीला चाहते हैं।

मैं लिनक्स में अवसर से हमेशा सुखद आश्चर्यचकित था, उपलब्ध साधनों का उपयोग करके, जल्दी से एक व्यावहारिक समाधान का निर्माण करने के लिए।

कहो, मैंने अक्सर सिस्टम पायथन का उपयोग करके निम्नलिखित एकल-पंक्ति के साथ उपरोक्त कार्य को हल किया है

$ python3 -mhttp.server Serving HTTP on 0.0.0.0 port 8000 ...

यह कमांड वर्तमान फ़ोल्डर में वेब सर्वर शुरू करता है और आपको फाइलों की एक सूची प्राप्त करने और उन्हें वेब इंटरफेस के माध्यम से डाउनलोड करने की अनुमति देता है। इनमें से अधिक चीजों को यहां डंप किया जा सकता है ।

कई असुविधाएँ हैं। अब, एक सहयोगी को डाउनलोड लिंक स्थानांतरित करने के लिए, आपको नेटवर्क पर अपना आईपी पता जानने की आवश्यकता है।

यह कमांड का उपयोग करने के लिए सुविधाजनक है

 $ ifconfig -a

और फिर नेटवर्क इंटरफेस की परिणामी सूची से, उपयुक्त एक का चयन करें और मैन्युअल रूप से http: // IP: 8000 का लिंक लिखें, जिसे आप भेज सकते हैं।

दूसरी असुविधा: यह सर्वर एकल-थ्रेडेड है। इसका मतलब यह है कि जहां आपका एक सहकर्मी फाइल डाउनलोड करता है, वहीं दूसरा भी फाइलों की सूची डाउनलोड नहीं कर पाएगा।

तीसरा, यह अनम्य है। यदि आपको केवल एक फ़ाइल को स्थानांतरित करने की आवश्यकता है, तो यह पूरे फ़ोल्डर को खोल देगा, अर्थात। आपको इस तरह के इशारों का प्रदर्शन करना होगा (और फिर कचरा साफ करना होगा):

 $ mkdir tmp1 $ cp file.zip tmp1 $ cd tmp1 $ python3 -mhttp.server

चौथी असुविधा - एक फ़ोल्डर की संपूर्ण सामग्री को डाउनलोड करने का कोई आसान तरीका नहीं है ।

एक फ़ोल्डर की सामग्री को स्थानांतरित करने के लिए, वे आमतौर पर एक तकनीक का उपयोग करते हैं जिसे टार पाइप कहा जाता है।

वे ऐसा कुछ करते हैं:

 $ ssh user@host 'cd /path/to/source && tar cf - .' | cd /path/to/destination && tar xvf -

अगर अचानक यह स्पष्ट नहीं है, तो मैं बताऊंगा कि यह कैसे काम करता है। tar cf - . कमांड tar cf - . पहला भाग tar cf - . वर्तमान फ़ोल्डर की सामग्री का एक संग्रह बनाता है और मानक आउटपुट को लिखता है। इसके अलावा, यह आउटपुट पाइप के माध्यम से एक सुरक्षित ssh चैनल के माध्यम से एक समान tar xvf - के इनपुट में tar xvf - होता है tar xvf - जो विपरीत प्रक्रिया करता है, अर्थात। मानक इनपुट पढ़ता है और वर्तमान फ़ोल्डर में अनज़िप करता है। वास्तव में, फ़ाइल संग्रह को स्थानांतरित किया जाता है, लेकिन एक मध्यवर्ती फ़ाइल बनाए बिना!

इस दृष्टिकोण की असुविधा भी स्पष्ट है। हमें एक मशीन से दूसरी मशीन तक पहुंच की आवश्यकता है, और यह सामान्य मामले में लगभग कभी नहीं किया गया है।

क्या उपरोक्त सभी को प्राप्त करना संभव है, लेकिन इन वर्णित समस्याओं के बिना?

इसलिए, यह औपचारिक करने का समय है कि हम क्या बनाएंगे:

प्रोग्राम स्थापित करने में आसान (स्टेटिक बाइनरी)
जो आपको सभी सामग्री के साथ एक फ़ाइल और एक फ़ोल्डर दोनों को स्थानांतरित करने की अनुमति देगा
वैकल्पिक संपीड़न के साथ
जो होस्ट को केवल मानक * निक्स टूल (wget / curl / tar) का उपयोग करके फ़ाइल डाउनलोड करने की अनुमति देता है
लॉन्च के तुरंत बाद कार्यक्रम डाउनलोड करने के लिए सटीक आदेश जारी करेगा

निर्णय

JEEConf सम्मेलन में, जिसमें मैंने बहुत पहले भाग नहीं लिया था, ग्रेगल विषय को बार-बार उठाया गया था। विषय नए से बहुत दूर है, लेकिन मेरे लिए अंत में इस जानवर को अपने हाथ से महसूस करना एक ट्रिगर था।

उन लोगों के लिए जो विषय में अभी तक नहीं हैं (क्या वास्तव में ऐसा अभी तक है? ओओ) मुझे आपको याद दिलाना है कि ग्रेवालम ओरेकल से अतिरिक्त सुविधाओं के साथ एक पंप जेवीएम है, जिनमें से सबसे अधिक ध्यान देने योग्य हैं:

पॉलीग्लॉट जेवीएम - जावा, जावास्क्रिप्ट, पायथन, रूबी, आर, आदि को मूल रूप से चलाने की क्षमता। कोड
एओटी संकलन के लिए समर्थन - जावा को मूल बाइनरी में सीधे संकलित करना
एक कम ध्यान देने योग्य, लेकिन बहुत ही शांत विशेषता - C2 संकलक को उसके आगे के विकास के लिए अधिक सुविधाजनक बनाने के लिए C ++ से जावा में फिर से लिखा गया। यह पहले से ही ध्यान देने योग्य परिणाम उत्पन्न कर चुका है। यह संकलक जावा बाइटकोड को मूल कोड में परिवर्तित करने के चरण में बहुत अधिक अनुकूलन करता है। उदाहरण के लिए, यह अधिक प्रभावी ढंग से आवंटन को समाप्त करने में सक्षम है। ट्विटर इस सेटिंग को चालू करके केवल CPU खपत को 11% तक कम करने में सक्षम था, जो उनके पैमाने में संसाधनों (और धन) की ध्यान देने योग्य बचत देता था।

आप ग्रेवाल के विचार को ताज़ा कर सकते हैं, उदाहरण के लिए, इस हब्र-लेख में ।

हम जावा में लिखेंगे, इसलिए हमारे लिए सबसे प्रासंगिक विशेषता एओटी संकलन होगा।

दरअसल, इस जीथूब भंडार में विकास परिणाम प्रस्तुत किया गया है ।

एकल फ़ाइल को स्थानांतरित करने के लिए उपयोग उदाहरण:

 $ serv '/path/to/report.pdf' To download the file please use one of the commands below: curl http://192.168.0.179:17777/dl > 'report.pdf' wget -O- http://192.168.0.179:17777/dl > 'report.pdf' curl http://192.168.0.179:17777/dl?z --compressed > 'report.pdf' wget -O- http://192.168.0.179:17777/dl?z | gunzip > 'report.pdf'

फ़ोल्डर की सामग्री को स्थानांतरित करते समय उपयोग करने का एक उदाहरण (संलग्न फ़ाइलों सहित सभी फाइलें!):

 $ serv '/path/to/folder' To download the files please use one of the commands below. NB! All files will be placed into current folder! curl http://192.168.0.179:17777/dl | tar -xvf - wget -O- http://192.168.0.179:17777/dl | tar -xvf - curl http://192.168.0.179:17777/dl?z | tar -xzvf - wget -O- http://192.168.0.179:17777/dl?z | tar -xzvf -

हाँ, इतना आसान!

कृपया ध्यान दें - प्रोग्राम ही सही आईपी पते को निर्धारित करता है जिस पर फाइलें डाउनलोड के लिए उपलब्ध होंगी।

अवलोकन / विचार

यह स्पष्ट है कि कार्यक्रम बनाने में लक्ष्यों में से एक इसकी कॉम्पैक्टनेस थी। और यहाँ परिणाम है कि प्राप्त किया गया था:

 $ du -hs `which serv` 2.4M /usr/local/bin/serv

अविश्वसनीय रूप से, पूरे जेवीएम, आवेदन कोड के साथ, एक दुखी कुछ मेगाबाइट में फिट होते हैं! बेशक, सब कुछ कुछ गलत है, लेकिन बाद में उस पर और अधिक।

वास्तव में, ग्रेगल कंपाइलर एक बाइनरी पैदा करता है जो आकार में 7 मेगाबाइट से थोड़ा बड़ा होता है। मैंने इसे UPX के साथ कंप्रेस करने का फैसला किया।

यह एक अच्छा विचार था, क्योंकि प्रक्षेपण का समय बहुत ही महत्वहीन होने के बाद से बढ़ा:

असम्बद्ध विकल्प:

 $ time ./build/com.cmlteam.serv.serv -v 0.1 real 0m0.001s user 0m0.001s sys 0m0.000s

संकुचित:

 $ time ./build/serv -v 0.1 real 0m0.021s user 0m0.021s sys 0m0.000s

तुलना के लिए, "पारंपरिक तरीके से" लॉन्च समय:

 $ time java -cp "/home/xonix/proj/serv/target/classes:/home/xonix/.m2/repository/commons-cli/commons-cli/1.4/commons-cli-1.4.jar:/home/xonix/.m2/repository/org/apache/commons/commons-compress/1.18/commons-compress-1.18.jar" com.cmlteam.serv.Serv -v 0.1 real 0m0.040s user 0m0.030s sys 0m0.019s

जैसा कि आप देख सकते हैं, यूपीएक्स संस्करण के मुकाबले दोगुना धीमा है।

सामान्य तौर पर, एक छोटी शुरुआत का समय GraalVM की ताकत में से एक है। यह, साथ ही कम मेमोरी खपत, इस तकनीक के उपयोग के आसपास महत्वपूर्ण उत्साह का कारण बनता है और सर्वर रहित।

मैंने कार्यक्रम के तर्क को यथासंभव कम से कम करने और पुस्तकालयों का न्यूनतम उपयोग करने की कोशिश की। सिद्धांत रूप में, यह दृष्टिकोण आम तौर पर न्यायसंगत है, और इस मामले में मुझे चिंता थी कि तीसरे पक्ष के मावेन निर्भरता को जोड़ने से परिणामस्वरूप प्रोग्राम फ़ाइल का "वजन" काफी होगा।

उदाहरण के लिए, इसलिए, मैंने जावा वेब सर्वर के लिए एक तृतीय-पक्ष निर्भरता का उपयोग नहीं किया (और हर स्वाद और रंग के लिए कई हैं), लेकिन मैंने com.sun.net.httpserver.* से वेब सर्वर के JDK कार्यान्वयन का उपयोग किया com.sun.net.httpserver.* पैकेज। वास्तव में, com.sun.* का उपयोग com.sun.* पैकेज एक com.sun.* माना जाता है, लेकिन मैंने इस मामले में इस अनुमति को माना, क्योंकि मैं मूल कोड में संकलन कर रहा हूं, और इसलिए, जेवीएम के बीच संगतता का कोई सवाल ही नहीं है।

हालाँकि, मेरा डर पूरी तरह से व्यर्थ था। कार्यक्रम में, मैंने सुविधा के लिए दो निर्भरता का उपयोग किया

commons-cli - कमांड लाइन तर्क देने के लिए
commons-compress - एक फ़ोल्डर टारबॉल और वैकल्पिक gzip संपीड़न उत्पन्न करने के लिए

उसी समय, फ़ाइल का आकार बहुत कम बढ़ गया। मैं यह सुझाव देना चाहता हूं कि ग्रेग कंपाइलर सभी प्लग-इन जार-निक्स को निष्पादन योग्य फ़ाइल में नहीं डालने के लिए बहुत स्मार्ट है, लेकिन उनमें से केवल वह कोड जो वास्तव में एप्लिकेशन कोड द्वारा उपयोग किया जाता है।

देशी ग्रेगल कोड में संकलन देशी-छवि उपयोगिता द्वारा किया जाता है । यह उल्लेखनीय है कि यह प्रक्रिया संसाधन-गहन है। कहते हैं, बोर्ड पर इंटेल 7700K सीपीयू के साथ मेरे नहीं-तो-धीमी कॉन्फ़िगरेशन पर, इस प्रक्रिया में 19 सेकंड लगते हैं। इसलिए, मैं सलाह देता हूं कि जब विकसित हो रहा है, तो प्रोग्राम को हमेशा की तरह चलाएं (जावा के माध्यम से), और अंतिम चरण में बाइनरी इकट्ठा करें।

निष्कर्ष

यह प्रयोग, मुझे ऐसा लगता है, बहुत सफल रहा। ग्रेवल टूलकिट का उपयोग करते समय, मैंने किसी भी असंभव या महत्वपूर्ण समस्या का सामना नहीं किया। सब कुछ अनुमानित और stably काम किया। हालांकि, लगभग निश्चित रूप से, सब कुछ इतना सहज नहीं होगा यदि आप इस तरह से कुछ और जटिल बनाने की कोशिश करते हैं, उदाहरण के लिए, स्प्रिंग बूट पर एक आवेदन । फिर भी, कई प्लेटफ़ॉर्म पहले ही प्रस्तुत किए जा चुके हैं जिनमें ग्रेगल के लिए मूल समर्थन घोषित किया गया है। इनमें माइक्रोनॉट , माइक्रोप्रोफाइल , क्वार्कस हैं ।

परियोजना के आगे के विकास के लिए, संस्करण 0.2 के लिए योजनाबद्ध सुधारों की एक सूची पहले से ही तैयार है। इसके अलावा, फिलहाल, अंतिम बाइनरी की विधानसभा केवल लिनक्स x64 के लिए लागू की जाती है। मुझे उम्मीद है कि यह चूक भविष्य में तय हो जाएगी, खासकर जब से ग्रेगल से native-image संकलक मैकओएस और विंडोज का समर्थन करता है। दुर्भाग्य से, यह अभी तक क्रॉस-संकलन का समर्थन नहीं करता है, जो चीजों को बहुत आसान बना सकता है।

मुझे उम्मीद है कि प्रस्तुत उपयोगिता कम से कम किसी सम्मानित हबल समुदाय से उपयोगी होगी। अगर परियोजना में योगदान करना चाहते हैं तो मुझे दोगुना खुशी होगी।

GraalVM पर एक उपयोगिता विकसित करें

समस्या का बयान

निर्णय

अवलोकन / विचार

निष्कर्ष

More articles: