2013-06-07 5 views
15

लघु संस्करण:पर्ल "ऐप सर्वर" (mod_perl प्रतिस्थापन) का मूल्यांकन करने के लिए मुझे किन मापदंडों का उपयोग करना चाहिए?

क्या मानदंड मैं एक पर्ल "अनुप्रयोग सर्वर" के लिए संभव उम्मीदवारों का मूल्यांकन करने का उपयोग करना चाहिए (मोड-पर्ल प्रतिस्थापन)?

हम जो की लागत के बिना (एक सेवा के रूप में) बार-बार विभिन्न पर्ल कार्यक्रमों को क्रियान्वित करने की अनुमति देगा ढांचे के कुछ प्रकार के लिए देख रहे हैं:

  1. फिर से launcing प्रत्येक निष्पादन प्रति एक बार पर्ल दुभाषिया

  2. लदान/पर्ल मॉड्यूल संकलन एक बार निष्पादन प्रति

(जो दोनों के लाभ है कि चल mod_ हैं पर्ल प्रदान करता है)

नोट्स:

  • हम ऐसी गहरी अपाचे एकीकरण के रूप में बहुत ज्यादा मोड-पर्ल द्वारा प्रदान किसी भी अतिरिक्त लाभ, के बारे में बहुत ज्यादा नहीं देखभाल करते हैं।

  • यह एक शुद्ध ऐप सर्वर होगा, जिसका अर्थ है कि किसी भी वेब विशिष्ट कार्यक्षमता की आवश्यकता नहीं है (यदि कोई ऐप सर्वर इसे प्रदान करता है तो यह कोई समस्या नहीं है, केवल इसकी आवश्यकता नहीं होगी)।

  • हम निश्चित रूप से स्पष्ट मानदंड (कच्ची गति, उत्पादन-तैयार स्थिरता, सक्रिय विकास, ओएस पर चलाने की क्षमता) पर विचार करेंगे। मुझे जो दिलचस्पी है वह कम छोटी और सूक्ष्म चीजें हैं जिन्हें हम ऐसे ढांचे/सर्वर से चाह सकते हैं।

पृष्ठभूमि:

$ काम में शक्तियों का फैसला किया है कि वे एक मौजूदा स्थिति बदलना चाहते हैं (सरल webapps Embperl में विकसित और अपाचे/मोड-पर्ल के माध्यम से स्थापित किया जा रहा)।

निर्णय (घर से उगाए गए) एमवीसी सिस्टम का उपयोग करने के लिए किया गया था जिसमें दृश्य के लिए जावा स्प्रिंग फ्रंट एंड होगा; और नियंत्रक प्रति-एप सेवाओं के लिए बैक-एंड सेवा अनुरोधों को निष्पादित करेगा जो मॉडल कर्तव्यों का पालन करते हैं (इसके विवरण पर लटका नहीं है - यह मुख्य प्रश्न के लिए बहुत प्रासंगिक नहीं है)।

बैक-एंड सेवाओं के लिए विकल्पों में से एक पर्ल है, ताकि हम अपने सभी मौजूदा पर्ल आईपी (पुस्तकालय, वेबएप बैकएंड कोड) का आगे बढ़ सकें, और जावा को 100% पोर्ट नहीं करना पड़े।

संक्षेप में:

| View | Model/app | Model loaded/executed by:       | 
================================================================================ 
OLD | Empberl | Model.pm | mod_perl has Model.pm loaded, called from view.epl | 
NEW | Java | Model.pm | perl generic_model.pl -model Model (does "require") | 
================================================================================ 

अब, जो थोड़ी देर के लिए पर्ल वेब विकास किया था आप में से जो, तुरंत नए डिजाइन के साथ सबसे स्पष्ट समस्या देखेंगे:

| Perl interpreter starts | Perl modules are loaded and compiled | 
======================================================================= 
OLD | Once per mod_perl thread | Once per mod_perl thread 
NEW | Once per EVERY! request | Once per EVERY! request    | 
======================================================================= 

दूसरे शब्दों में , नए मॉडल में, हम के पास लगातार सर्वर साइड ऐप कंटेनर के रूप में mod_perl द्वारा प्रदान किए गए किसी भी प्रदर्शन लाभ नहीं है !!!

इसलिए, हम एक ही फ़ंक्शन की सेवा के लिए संभावित ऐप कंटेनर देख रहे हैं।

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

+0

जावा और पर्ल भागों को एक-दूसरे से बात करने के लिए किस प्रोटोकॉल का उपयोग किया जाएगा? – innaM

+0

लेकिन क्या आप "' apache mod_perl''' पर्यावरण (या पीएसजीआई) में सेवाओं को चलाने के लिए केवल अपनी शुरुआत के "समांतरता" को नहीं रख सकते हैं और उन सभी से अपनी नई जावा स्विंग चीज़ से बात कर सकते हैं? क्या वह बहुत धीमा है? कम से कम '' 'perl''' दुभाषिया चल रहा है और प्रतीक्षा और तैयार है। –

+0

क्षमा करें मेरा मतलब था कि मेरी पिछली टिप्पणी आपके साइड नोट के संबंध में एक और प्रश्न/प्रतिक्रिया होगी। क्या आपने इस '' _ mod_perl''' ऐप कंटेनर दृष्टिकोण का परीक्षण किया है? ऐसा लगता है कि www.apache.org इस तरह से अपनी मेलिंग सूची डिलीवरी को संभालने में मदद के लिए '' 'Qpsmtpd''' चलाता है या चलाता है (** यानी ** एक apache' '_ mod_perl''' उदाहरण में एक एसएमटीपी सेवा के रूप में एम्बेडेड)। तो '' apache''' और '' 'mod_perl''' ..." वे सिर्फ वेब के लिए नहीं हैं ":-) –

उत्तर

5

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

जब से तुम एक बाधा है, शायद अल्पावधि में सबसे अच्छा तरीका के रूप में "ट्वीट्स" (यानी "जनशक्ति") का उल्लेख एक अलग apache स्थापित करने के लिए है इस तरह से (चूंकि वे पहले से ही इस तरह से चलते हैं, क्या यह सही है?)। आखिरकार, apache (और mod_perl) अच्छी तरह से ज्ञात, युद्ध परीक्षण, और बेहद tweakable और विन्यास योग्य हैं। तैनाती विकल्प बहुत लचीले (एक ही मशीन, विभिन्न मशीनें, फेलओवर, भार संतुलन, बादल, स्थानीय, वीएम) हैं और इनका भी अच्छी तरह से परीक्षण किया गया है।

एक बार जब आप इसे चलाते हैं तो आप apache के बिना अपने अनुप्रयोगों और सेवाओं को जादुई रूप से डिमोनिज़ करने के लिए विभिन्न "कम जनशक्ति आवश्यक" दृष्टिकोणों के साथ प्रयोग करना शुरू कर सकते हैं। Plack और Starman का उल्लेख किया गया है, Mojolicious:: एक और ढांचा है जो JSON websockets आदि (और Plack) के साथ काम करने में सक्षम है। इन्हें भी अच्छी तरह से परीक्षण किया गया है लेकिन शायद mod_perl और अपाचे से कम परिचित हैं। फिर भी यदि आप एक पर्ल की दुकान हैं तो आपको इन "आधुनिक" उपकरणों के साथ काम करने में कठिनाई नहीं होनी चाहिए। एक दिन, यदि आप अधिक संसाधन के साथ समाप्त होते हैं, तो आप अपनी सभी पीएलएल आधारित सेवाओं के लिए एक परिष्कृत नेटवर्क प्लेटफॉर्म तैयार कर सकते हैं और सीपीएएन पर POE, Plack जैसे सभी ठंडा "नया" (या कम से कम mod_perl) का उपयोग कर सकते हैं, आदि। आप अपनी व्यावसायिक समस्या को हल करते समय शांत सामान विकसित करने में बहुत मज़ेदार हो सकते हैं।

मेरे पहले टिप्पणी को स्पष्ट करने के लिए: Ubic (MetaCPAN पर Ubic देखें) daemonize (और इस प्रकार precompile) कर सकते हैं अपने perl उपकरण और कुछ की निगरानी और सुविधाएं हैं उनकी ढांचे के साथ मुक्त करने के लिए आते हैं प्रदान करता है। PlackUbic::Service::Plack नामक उपयोग के लिए डिज़ाइन किया गया एक यूबिक मॉड्यूल उपलब्ध है। अपने और अपने आप में यूबीआईसी आपके नए जावा/स्विंग एप्लिकेशन के लिए अपने पर्ल अनुप्रयोगों से बात करने के लिए एक आसान समाधान प्रदान नहीं करता है, लेकिन यह आपके द्वारा आने वाले किसी भी समाधान को प्रबंधित/निगरानी करने में सहायता कर सकता है।

शुभकामनाएँ और मज़े करें!

+1

"अगर वे कुशलता से" deemonized "हो सकता है।" - वे नहीं कर सकते हैं (कारण तकनीकी नहीं हैं, लेकिन जनशक्ति की आवश्यकताएं डिमन्स लिखने और परीक्षण करने के लिए आवश्यक हैं), अन्यथा हमें ऐप सर्वर की आवश्यकता नहीं होगी, जाहिर है :) – DVK

+0

ध्यान दें कि [यूबीआईसी] (https://metacpan.org/ रिलीज/उबिक) आप बहुत कुछ भी "डिमनीकरण" कर सकते हैं (जैसा कि आप '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' '' मैं इसे स्पष्ट करने के लिए अपना उत्तर संपादित करूंगा। प्रति अनुरोध शुरू करने या '' __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ लेकिन यह उपयोगी बनाने के लिए हमें यह जानना होगा कि आप कैसे वेब सेवा और बैकएंड एक दूसरे के साथ संवाद करने की योजना बना रहे हैं। @Miguel नोट्स के रूप में यह JSON का उपयोग करना काफी आसान होगा। –

7

Starman एक उच्च प्रदर्शन प्रीफ़ोरिंग पीएसजीआई/प्लेक वेब सर्वर है जिसका उपयोग उस संदर्भ में किया जा सकता है। एक आरईएसटी एप्लीकेशन बनाना आसान है जो स्टेटलेस जेएसओएन ऑब्जेक्ट्स (यह एक साधारण उपयोग केस है) परोसता है।

Starman एक उत्पादन के लिए तैयार सर्वर है और यह एक रिवर्स प्रॉक्सी (this SO question may helps you), के लिए स्केलिंग प्रयोजनों

1

आप HTTP::Daemon का उपयोग कर एक सरल डेमॉन बना सकते हैं के पीछे Starman उदाहरणों का एक सेट स्थापित करने के लिए वास्तव में आसान है, और सभी के लिए है बाद में आपके कोड के आवश्यक हिस्सों को संकलित करने के लाभ (require), या पहले से ही, डिमन शुरू होने से पहले।

संबंधित मुद्दे

 संबंधित मुद्दे