2017 की शुरुआत से, हमारी छोटी टीम C ++ एप्लिकेशन में HTTP सर्वर को एम्बेड करने के लिए Restinio OpenSource लाइब्रेरी विकसित कर रही है। हमारे महान आश्चर्य के लिए, समय-समय पर हमें श्रेणी से प्रश्न मिलते हैं "और एक एम्बेडेड सी ++ HTTP सर्वर की आवश्यकता क्यों हो सकती है?" दुर्भाग्य से, सरल प्रश्न उत्तर देने में सबसे कठिन हैं। कभी-कभी सबसे अच्छा जवाब नमूना कोड होता है।

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

यह डेमो प्रोजेक्ट उस में अच्छा है, सबसे पहले, इसे C या C ++ (इस मामले में, ImageMagick) में सही कोड लिखने और काम करने के लिए लंबे समय से एकीकरण की आवश्यकता है। इसलिए, यह स्पष्ट होना चाहिए कि C ++ एप्लिकेशन में HTTP सर्वर को एम्बेड करने के लिए यह क्यों समझ में आता है।

और दूसरी बात, इस मामले में, अनुरोधों के अतुल्यकालिक प्रसंस्करण की आवश्यकता होती है ताकि HTTP सर्वर अवरुद्ध न हो, जबकि छवि को बढ़ाया जा रहा है (और यह सैकड़ों मिलीसेकंड या सेकंड भी ले सकता है)। और हमने Restinio के विकास को ठीक से शुरू किया क्योंकि हम विशेष रूप से अतुल्यकालिक अनुरोध प्रसंस्करण पर ध्यान केंद्रित किए बिना एक समझदार C ++ एम्बेडेड सर्वर नहीं पा सके।

हमने श्रिम्प पर कार्य को चलने के लिए बनाया है: पहले, सबसे सरल संस्करण बनाया गया था और वर्णित किया गया था, जिसने केवल चित्रों को बढ़ाया। फिर हमने पहले संस्करण की कई कमियों को ठीक किया और दूसरे लेख में इसका वर्णन किया । अंत में, हम एक बार फिर झींगा की कार्यक्षमता का विस्तार करने के लिए चारों ओर हो गए: छवियों के एक प्रारूप से दूसरे स्वरूप में रूपांतरण जोड़ा गया। यह कैसे किया गया और इस लेख में चर्चा की जाएगी।

लक्ष्य-प्रारूप का समर्थन

इसलिए, चिंराट के अगले संस्करण में, हमने एक अलग प्रारूप में स्केल की गई तस्वीर देने की क्षमता को जोड़ा। इसलिए, यदि आप फॉर्म का एक झींगा अनुरोध जारी करते हैं:

curl "http://localhost:8080/my_picture.jpg?op=resize&max=1920" 

तब चिंराट छवि को उसी JPG प्रारूप में मूल छवि के रूप में प्रस्तुत करेगा।

लेकिन यदि आप URL में लक्ष्य-प्रारूप पैरामीटर जोड़ते हैं, तो चिंराट छवि को निर्दिष्ट लक्ष्य प्रारूप में बदल देता है। उदाहरण के लिए:

 curl "http://localhost:8080/my_picture.jpg?op=resize&max=1920&target-format=webp" 

इस स्थिति में, चिंराट वेब प्रारूप में छवि को प्रस्तुत करेगा।

अपडेट की गई चिंराट पाँच छवि स्वरूपों का समर्थन करती है: jpg, png, gif, webp और heic (HEIF के रूप में भी जाना जाता है)। आप एक विशेष वेब पेज पर विभिन्न प्रारूपों के साथ प्रयोग कर सकते हैं:



(इस पृष्ठ पर सामान्य प्रारूप का चयन करने का कोई तरीका नहीं है, क्योंकि साधारण डेस्कटॉप ब्राउज़र डिफ़ॉल्ट रूप से इस प्रारूप का समर्थन नहीं करते हैं)।

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

ImageMagick को विभिन्न स्वरूपों को समझना चाहिए

ImageMagick इनकोडिंग / डिकोडिंग इमेज के लिए बाहरी लाइब्रेरीज़ का उपयोग करता है: libjpeg, libpng, libgif, आदि। ImageMagick कॉन्फ़िगर और निर्मित होने से पहले इन पुस्तकालयों को सिस्टम पर स्थापित किया जाना चाहिए।

WebM और heic स्वरूपों का समर्थन करने के लिए ImageMagick के लिए भी यही बात होनी चाहिए: सबसे पहले आपको libwebp और libheif को बनाने और स्थापित करने की आवश्यकता है, फिर ImageMagick को कॉन्फ़िगर और इंस्टॉल करें। और अगर सब कुछ libwebp के साथ सरल है, तो libheif के आसपास मुझे एक नखरे के साथ नृत्य करना पड़ा। यद्यपि कुछ समय के बाद, आखिरकार सब कुछ इकट्ठा हो गया और काम किया, यह पहले से ही स्पष्ट नहीं था: आपको एक नखरे का सहारा क्यों लेना पड़ा, सब कुछ तुच्छ प्रतीत होता है? ;)

सामान्य तौर पर, यदि कोई हेक और इमेज मैजिक के साथ दोस्त बनाना चाहता है, तो आपको इंस्टॉल करना होगा:

• videolan.org से x265 ;
• libde265 ;
• libheif ।

यह इस क्रम में है (आपको nasm को स्थापित करना पड़ सकता है ताकि x265 अधिकतम गति से काम करे)। फिर, ./configure कमांड जारी करते समय, ImageMagick को .he फ़ाइलों का समर्थन करने के लिए आवश्यक सभी चीज़ों को खोजने में सक्षम होगा।

आने वाले अनुरोधों की क्वेरी स्ट्रिंग में लक्ष्य-प्रारूप के लिए समर्थन

जब हमने वेब और विषम प्रारूपों के साथ ImageMagick मित्र बनाए, तो यह झींगा कोड को संशोधित करने का समय है। सबसे पहले, हमें सीखने की ज़रूरत है कि आने वाले HTTP अनुरोधों में लक्ष्य-प्रारूप तर्क को कैसे पहचाना जाए।

Restinio के दृष्टिकोण से, यह बिल्कुल समस्या नहीं है। खैर, एक और तर्क क्वेरी स्ट्रिंग में दिखाई दिया, तो क्या? लेकिन झींगा के दृष्टिकोण से, स्थिति कुछ अधिक जटिल हो गई, इसलिए HTTP अनुरोध को पार्स करने के लिए जिम्मेदार फ़ंक्शन का कोड अधिक जटिल हो गया।

तथ्य यह है कि इससे पहले कि केवल दो स्थितियों में अंतर करना आवश्यक था:

• किसी अन्य पैरामीटर के बिना "/filename.ext" फॉर्म का अनुरोध आया। तो आपको बस फ़ाइल "filename.ext" देने की आवश्यकता है जैसा कि यह है;
• एक अनुरोध "/filename.ext?op=resize & ..." फ़ॉर्म में आया था। इस मामले में, आपको फ़ाइल "filename.ext" से छवि को स्केल करने की आवश्यकता है।

लेकिन लक्ष्य-प्रारूप जोड़ने के बाद, हमें चार स्थितियों में अंतर करना होगा:

• किसी अन्य पैरामीटर के बिना "/filename.ext" फॉर्म का अनुरोध आया। इसलिए आपको फ़ाइल को "फ़ाइलनाम। टेक्स्ट" देने की आवश्यकता है क्योंकि यह स्केलिंग के बिना और दूसरे प्रारूप में ट्रांसकोडिंग के बिना है;
• किसी अन्य मापदंडों के बिना "/filename.ext?target-format=fmt" फॉर्म का अनुरोध आया। इसका मतलब है कि फ़ाइल से एक छवि "फ़ाइलनाम। कस्टम" और इसे मूल आकारों को संरक्षित करते हुए प्रारूप "एफटीएम" में ट्रांसकोड करें;
• एक अनुरोध "/filename.ext?op=resize & ..." फ़ॉर्म का आया था, लेकिन लक्ष्य-स्वरूप के बिना। इस मामले में, आपको फ़ाइल से फ़ाइल नाम स्केल करने की आवश्यकता है। फ़ाइल नाम और इसे मूल प्रारूप में दें;
• एक अनुरोध "/filename.ext?op=resize&...&target-format=fmm" के रूप में आया। इस स्थिति में, आपको स्केलिंग करने की आवश्यकता है, और फिर परिणाम को "fmt" प्रारूप में ट्रांसकोड करें।

परिणामस्वरूप, क्वेरी मापदंडों को निर्धारित करने के लिए फ़ंक्शन ने निम्न रूप लिया:

 void add_transform_op_handler( const app_params_t & app_params, http_req_router_t & router, so_5::mbox_t req_handler_mbox ) { router.http_get( R"(/:path(.*)\.:ext(.{3,4}))", restinio::path2regex::options_t{}.strict( true ), [req_handler_mbox, &app_params]( auto req, auto params ) { if( has_illegal_path_components( req->header().path() ) ) { //     . return do_400_response( std::move( req ) ); } //   . const auto qp = restinio::parse_query( req->header().query() ); const auto target_format = qp.get_param( "target-format"sv ); //        // .   target-format,    //   .   target-format  // ,    ,  //    . const auto image_format = try_detect_target_image_format( params[ "ext" ], target_format ); if( !image_format ) { //     .   . return do_400_response( std::move( req ) ); } if( !qp.size() ) { //    ,    . return serve_as_regular_file( app_params.m_storage.m_root_dir, std::move( req ), *image_format ); } const auto operation = qp.get_param( "op"sv ); if( operation && "resize"sv != *operation ) { //    ,     resize. return do_400_response( std::move( req ) ); } if( !operation && !target_format ) { //      op=resize, //   target-format=something. return do_400_response( std::move( req ) ); } handle_resize_op_request( req_handler_mbox, *image_format, qp, std::move( req ) ); return restinio::request_accepted(); } ); } 

झींगा के पिछले संस्करण में, जहां आपको छवि को ट्रांसकोड करने की आवश्यकता नहीं थी, अनुरोध पैरामीटर के साथ काम करना थोड़ा आसान था ।

लक्ष्य-स्वरूप के अनुरूप कतार और छवि कैश का अनुरोध करें

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

जब छवि रूपांतरण का अनुरोध आता है, तो यह पता चल सकता है कि इस तरह के मापदंडों के साथ समाप्त छवि पहले से ही कैश में है। इस मामले में, आपको कुछ भी करने की आवश्यकता नहीं है, बस प्रतिसाद में कैश से छवि भेजें। यदि तस्वीर को रूपांतरित करने की आवश्यकता है, तो यह पता चल सकता है कि इस समय कोई भी मुफ्त कर्मचारी नहीं हैं और आपको तब तक इंतजार करने की आवश्यकता है जब तक कि यह दिखाई न दे। ऐसा करने के लिए, अनुरोध जानकारी कतार में होनी चाहिए। लेकिन एक ही समय में, अनुरोधों की विशिष्टता की जांच करना आवश्यक है - अगर हमारे पास प्रसंस्करण के लिए तीन समान अनुरोध हैं (यानी, हमें उसी छवि को उसी तरह से बदलने की आवश्यकता है), तो हमें केवल एक बार छवि को संसाधित करना चाहिए, और प्रतिक्रिया में प्रसंस्करण का परिणाम देना चाहिए। इन तीन अनुरोधों के लिए। यानी प्रतीक्षा कतार में, समान अनुरोधों को समूहीकृत किया जाना चाहिए।

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

• सबसे पहले, लक्ष्य छवि प्रारूप (यानी, मूल छवि jpg में हो सकती है, और परिणामी छवि png में हो सकती है);
• दूसरे, यह तथ्य कि तस्वीर को स्केल करना आवश्यक नहीं है। यह उस स्थिति में होता है जहां ग्राहक केवल छवि को एक प्रारूप से दूसरे प्रारूप में बदलने का आदेश देता है, लेकिन छवि के मूल आकार के साथ।

मुझे कहना होगा कि यहाँ हम किसी भी तरह का अनुकूलन करने की कोशिश किए बिना, सबसे सरल रास्ते पर चले गए। उदाहरण के लिए, कोई दो कैश बनाने की कोशिश कर सकता है: एक छवियों को मूल प्रारूप में संग्रहीत करेगा, लेकिन वांछित आकार में स्केल किया जाएगा, और दूसरे में, स्केल की गई छवियां लक्ष्य प्रारूप में परिवर्तित हो जाएंगी।

ऐसे दोहरे कैशिंग की आवश्यकता क्यों होगी? तथ्य यह है कि जब चित्रों को रूपांतरित किया जाता है, तो समय में दो सबसे महंगे ऑपरेशन आकार बदल रहे हैं और चित्र को लक्ष्य प्रारूप में क्रमबद्ध कर रहे हैं। इसलिए, यदि हमें example.jpg चित्र को चौड़ाई में 1920 के आकार में बदलने और इसे वेब स्वरूप में बदलने का अनुरोध प्राप्त हुआ, तो हम अपनी मेमोरी में दो छवियों को संग्रहीत कर सकते हैं: example_1920px_width.jpg और example_1920px_width.webp। जब हम दूसरा अनुरोध प्राप्त करते हैं तो हम एक example_1920px_width.webp तस्वीर देंगे। लेकिन उदाहरण_1920px_width.jpg चित्र का उपयोग किया जा सकता है, जब उदाहरण के लिए स्केलिंग के लिए अनुरोध प्राप्त करते हैं। उदाहरण के लिए चौड़ाई में 1920 के आकार के लिए और इसे विषम प्रारूप में बदल दें। हम आकार बदलने वाले ऑपरेशन को छोड़ सकते हैं और केवल प्रारूप रूपांतरण कर सकते हैं (यानी, समाप्त छवि उदाहरण_1920px_width.jpg को विषम प्रारूप में ट्रांसकोड किया जाएगा)।

एक और संभावित अवसर: जब कोई आकार किसी चित्र को किसी अन्य प्रारूप में बिना आकार परिवर्तन के ट्रांसकोड करने के लिए आता है, तो आप छवि के वास्तविक आकार को निर्धारित कर सकते हैं और समग्र कुंजी के अंदर इस आकार का उपयोग कर सकते हैं। उदाहरण के लिए, example.jpg का आकार 3000x2000 पिक्सेल है। यदि हम अगली बार ऊँचाई पर 2000px उदाहरण के लिए एक अनुरोध प्राप्त करते हैं, तो हम तुरंत यह निर्धारित कर सकते हैं कि हमारे पास पहले से ही इस आकार में एक चित्र है।

सिद्धांत रूप में, ये सभी विचार ध्यान देने योग्य हैं। लेकिन व्यावहारिक दृष्टिकोण से, यह स्पष्ट नहीं है कि घटनाओं के इस तरह के विकास की संभावना कितनी अधिक है। यानी कितनी बार हम उदाहरण के लिए स्केलिंग के लिए एक अनुरोध प्राप्त करेंगे। उदाहरण के लिए 1920px वेब के लिए रूपांतरण के साथ, और फिर उसी छवि के समान स्केलिंग के लिए एक अनुरोध, लेकिन पीएनजी में रूपांतरण के साथ? कोई वास्तविक आँकड़े नहीं कहना मुश्किल है। इसलिए, हमने अपने डेमो प्रोजेक्ट में अपने जीवन को जटिल नहीं बनाने का फैसला किया, लेकिन सबसे सरल मार्ग के साथ पहले जाने के लिए। इस उम्मीद के साथ कि यदि किसी को अधिक उन्नत कैशिंग योजनाओं की आवश्यकता है, तो इसे बाद में जोड़ा जा सकता है, वास्तविक से शुरू, काल्पनिक नहीं, चिंराट का उपयोग करने के लिए परिदृश्य।

नतीजतन, चिंराट के अद्यतन संस्करण में, हमने कुंजी को थोड़ा विस्तारित किया, इसे जोड़ने के लिए भी इस तरह के एक पैरामीटर के रूप में लक्ष्य प्रारूप है:

 class resize_request_key_t { std::string m_path; image_format_t m_format; resize_params_t m_params; public: resize_request_key_t( std::string path, image_format_t format, resize_params_t params ) : m_path{ std::move(path) } , m_format{ format } , m_params{ params } {} [[nodiscard]] bool operator<(const resize_request_key_t & o ) const noexcept { return std::tie( m_path, m_format, m_params ) < std::tie( o.m_path, o.m_format, o.m_params ); } [[nodiscard]] const std::string & path() const noexcept { return m_path; } [[nodiscard]] image_format_t format() const noexcept { return m_format; } [[nodiscard]] resize_params_t params() const noexcept { return m_params; } }; 

यानी उदाहरण के लिए उदाहरण के लिए अनुरोध करें। पीजीई में रूपांतरण के साथ 1920px तक का आकार एक ही आकार परिवर्तन से भिन्न होता है, लेकिन वेब या हेक के रूपांतरण के साथ।

लेकिन मुख्य फोकस resize_params_t वर्ग के नए कार्यान्वयन में छिपा है , जो स्केलिंग छवि के नए आकारों को निर्धारित करता है। पहले, इस वर्ग ने तीन विकल्पों का समर्थन किया था: केवल चौड़ाई निर्धारित की गई थी, केवल ऊँचाई निर्धारित की गई थी, या लंबी तरफ सेट की गई थी (ऊँचाई या चौड़ाई वर्तमान छवि आकार द्वारा निर्धारित की गई है)। तदनुसार, resize_params_t :: value () विधि ने हमेशा कुछ वास्तविक मान लौटाया ( resize_params_t :: मोड () विधि) द्वारा क्या मान निर्धारित किया गया था।

लेकिन नई झींगा में, एक और मोड जोड़ा गया था - Keep_original, जिसका अर्थ है कि स्केलिंग का प्रदर्शन नहीं किया गया है और चित्र अपने मूल आकार में प्रदान किया गया है। इस मोड का समर्थन करने के लिए, resize_params_t को कुछ परिवर्तन करने थे। सबसे पहले, अब resize_params_t :: make () विधि निर्धारित करती है कि क्या Keep_original मोड का उपयोग किया जाता है (यह माना जाता है कि इस मोड का उपयोग किया जाता है यदि आवक अनुरोध के क्वेरी स्ट्रिंग में कोई भी चौड़ाई, ऊंचाई और अधिकतम पैरामीटर नहीं है)। इसने हमें handle_resize_op_request () फ़ंक्शन को फिर से लिखने की अनुमति नहीं दी, जो तस्वीर को निष्पादित करने के अनुरोध को आगे बढ़ाता है।

दूसरे, resize_params_t :: value () विधि को अब हमेशा नहीं कहा जा सकता है, लेकिन केवल जब स्केलिंग मोड Keep_original से भिन्न होता है।

लेकिन सबसे महत्वपूर्ण बात यह है कि resize_params_t :: ऑपरेटर <() यह काम करना जारी रखा जैसा कि यह इरादा था।

A_transform_manager में इन सभी परिवर्तनों के लिए धन्यवाद, स्केल की गई छवि कैश और प्रतीक्षा अनुरोधों की कतार समान बनी हुई है। लेकिन अब, इन डेटा संरचनाओं में विभिन्न प्रश्नों के बारे में जानकारी संग्रहीत है। तो, कुंजी {"example.jpg", "jpg", Keep_original} दोनों कुंजी {"example.jpg", "png", keep_original} और कुंजी {"example .jpg", "jpg", चौड़ाई से भिन्न होंगे। = 1920px}।

यह पता चला है कि resize_params_t और resize_params_key_t जैसे सरल डेटा संरचनाओं की परिभाषा के साथ थोड़ा खराब हो गया है, हम अधिक जटिल संरचनाओं को बदलने से बचते हैं जैसे कि परिणामस्वरूप छवियों की कैश और प्रतीक्षा अनुरोधों की कतार।

A_transformer में लक्ष्य-स्वरूप के लिए समर्थन

खैर, लक्ष्य-प्रारूप का समर्थन करने में अंतिम चरण a_transformer एजेंट के तर्क का विस्तार करना है ताकि चित्र, संभवतः पहले से ही स्केल किया गया हो, फिर लक्ष्य प्रारूप में परिवर्तित हो जाए।

ऐसा करने के लिए यह सबसे आसान हो गया, जिसकी आवश्यकता थी वह था कि a_transform_t :: handle_resize_request () विधि के कोड का विस्तार करना:

 [[nodiscard]] a_transform_manager_t::resize_result_t::result_t a_transformer_t::handle_resize_request( const transform::resize_request_key_t & key ) { try { m_logger->trace( "transformation started; request_key={}", key ); auto image = load_image( key.path() ); const auto resize_duration = measure_duration( [&]{ //       //    keep_original. if( transform::resize_params_t::mode_t::keep_original != key.params().mode() ) { transform::resize( key.params(), total_pixel_count, image ); } } ); m_logger->debug( "resize finished; request_key={}, time={}ms", key, std::chrono::duration_cast<std::chrono::milliseconds>( resize_duration).count() ); image.magick( magick_from_image_format( key.format() ) ); datasizable_blob_shared_ptr_t blob; const auto serialize_duration = measure_duration( [&] { blob = make_blob( image ); } ); m_logger->debug( "serialization finished; request_key={}, time={}ms", key, std::chrono::duration_cast<std::chrono::milliseconds>( serialize_duration).count() ); return a_transform_manager_t::successful_resize_t{ std::move(blob), std::chrono::duration_cast<std::chrono::microseconds>( resize_duration), std::chrono::duration_cast<std::chrono::microseconds>( serialize_duration) }; } catch( const std::exception & x ) { return a_transform_manager_t::failed_resize_t{ x.what() }; } } 

पिछले संस्करण की तुलना में , दो मौलिक जोड़ हैं।

सबसे पहले, आकार बदलने के बाद वास्तव में जादू image.magick () विधि को कॉल करना। यह विधि ImageMagick परिणामी छवि प्रारूप को बताती है। उसी समय, मेमोरी में छवि का प्रतिनिधित्व नहीं बदलता है - इमेजमैजिक इसे स्टोर करना जारी रखता है क्योंकि यह इसे सूट करता है। लेकिन फिर मैजिक () विधि द्वारा निर्धारित मूल्य को इमेज :: राइट () के बाद के कॉल के दौरान ध्यान में रखा जाएगा।

दूसरे, अद्यतन संस्करण उस समय को रिकॉर्ड करता है जो छवि को निर्दिष्ट प्रारूप में क्रमबद्ध करने में लेता है। चिंराट का नया संस्करण अब स्केलिंग पर खर्च किए गए समय को अलग करता है, और लक्ष्य प्रारूप को परिवर्तित करने में लगने वाला समय।

बाकी एजेंट a_transformer_t ने कोई परिवर्तन नहीं किया है।

ImageMagick समानांतरकरण

डिफ़ॉल्ट रूप से, ImageMagic OpenMP समर्थन के साथ बनाया गया है। यानी ImageMagick प्रदर्शन करने वाली छवियों पर संचालन को समानांतर करना संभव है। आप परिवेश चर MAGICK_THREAD_LIMIT का उपयोग करके इस मामले में ImageMagick का उपयोग करने वाले वर्कफ़्लो की संख्या को नियंत्रित कर सकते हैं।

उदाहरण के लिए, मेरे परीक्षण मशीन पर MAGICK_THREAD_LIMIT = 1 के साथ (यानी, वास्तविक समानांतर के बिना), मुझे निम्नलिखित परिणाम मिलते हैं:

 curl "http://localhost:8080/DSC08084.jpg?op=resize&max=2400" -v > /dev/null > GET /DSC08084.jpg?op=resize&max=2400 HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 200 OK < Connection: keep-alive < Content-Length: 2043917 < Server: Shrimp draft server < Date: Wed, 15 Aug 2018 11:51:24 GMT < Last-Modified: Wed, 15 Aug 2018 11:51:24 GMT < Access-Control-Allow-Origin: * < Access-Control-Expose-Headers: Shrimp-Processing-Time, Shrimp-Resize-Time, Shrimp-Encoding-Time, Shrimp-Image-Src < Content-Type: image/jpeg < Shrimp-Image-Src: transform < Shrimp-Processing-Time: 1323 < Shrimp-Resize-Time: 1086.72 < Shrimp-Encoding-Time: 236.276 

आकार बदलने के लिए बिताया गया समय चिंराट-आकार-समय शीर्षक में दर्शाया गया है। इस मामले में, यह 1086.72ms है।

लेकिन अगर आप एक ही मशीन पर MAGICK_THREAD_LIMIT = 3 सेट करते हैं और झींगा चलाते हैं, तो हमें अलग-अलग मूल्य मिलते हैं:

 curl "http://localhost:8080/DSC08084.jpg?op=resize&max=2400" -v > /dev/null > GET /DSC08084.jpg?op=resize&max=2400 HTTP/1.1 > Host: localhost:8080 > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 200 OK < Connection: keep-alive < Content-Length: 2043917 < Server: Shrimp draft server < Date: Wed, 15 Aug 2018 11:53:49 GMT < Last-Modified: Wed, 15 Aug 2018 11:53:49 GMT < Access-Control-Allow-Origin: * < Access-Control-Expose-Headers: Shrimp-Processing-Time, Shrimp-Resize-Time, Shrimp-Encoding-Time, Shrimp-Image-Src < Content-Type: image/jpeg < Shrimp-Image-Src: transform < Shrimp-Processing-Time: 779.901 < Shrimp-Resize-Time: 558.246 < Shrimp-Encoding-Time: 221.655 

यानी आकार बदलने का समय घटाकर 558.25ms कर दिया गया।

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

 SHRIMP_IO_THREADS=1 \ SHRIMP_WORKER_THREADS=3 \ MAGICK_THREAD_LIMIT=4 \ shrimp.app -p 8080 -i ... 

या उदाहरण के लिए कमांड लाइन तर्कों के माध्यम से:

 MAGICK_THREAD_LIMIT=4 \ shrimp.app -p 8080 -i ... --io-threads 1 --worker-threads 4 

कमांड लाइन के माध्यम से निर्दिष्ट मूल्यों की एक उच्च प्राथमिकता है।

इस बात पर जोर दिया जाना चाहिए कि MAGICK_THREAD_LIMIT केवल उन ऑपरेशनों को प्रभावित करता है जो ImageMagick स्वयं करता है। उदाहरण के लिए, आकार बदलने का काम ImageMagick द्वारा किया जाता है। लेकिन एक प्रारूप से दूसरे ImageMagick में रूपांतरण बाहरी पुस्तकालयों को दर्शाता है। और इन बाहरी पुस्तकालयों के संचालन को कैसे समानांतर किया जाता है यह एक अलग मुद्दा है जो हमें समझ में नहीं आया।

निष्कर्ष

शायद, चिंराट के इस संस्करण में, हम अपने डेमो प्रोजेक्ट को एक स्वीकार्य स्थिति में लाए। जो लोग देखना और प्रयोग करना चाहते हैं वे बिटबिकेट या गीथहब पर श्रिम्प के स्रोत ग्रंथों को पा सकते हैं। अपने प्रयोगों के लिए झींगा बनाने के लिए आप वहां डॉकरीफाइल भी पा सकते हैं।

सामान्य तौर पर, हमने अपने लक्ष्यों को प्राप्त कर लिया है जिसे हम इस डेमो प्रोजेक्ट को शुरू करके खुद को निर्धारित करते हैं। रेस्टिनियो और सोबिजाइज़र दोनों के आगे के विकास के लिए कई विचार प्रकट हुए, और उनमें से कुछ ने पहले ही अपना अवतार पाया है। इसलिए, चाहे चिंराट कहीं और विकसित होगा पूरी तरह से सवालों और इच्छाओं पर निर्भर करता है। यदि हैं, तो झींगा का विस्तार हो सकता है। यदि नहीं, तो श्रिम्प एक डेमो प्रोजेक्ट और Restinio और SObjectizer के नए संस्करणों के साथ प्रयोग करने के लिए एक प्रशिक्षण ग्राउंड रहेगा।

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