मैं सीजीआई और ईआरबी का उपयोग करके अपनी वेबसाइट बनाने की कोशिश कर रहा था, लेकिन जब मैं वेब पर खोज करता हूं, तो मुझे लगता है कि मुझे हमेशा यह कहना चाहिए कि मुझे हमेशा इस्तेमाल करना चाहिए CGI, और हमेशा उपयोग करें Rack.

मैं समझता हूं कि सीजीआई बहुत रूबी प्रक्रियाओं को फोर्क करेगा, लेकिन अगर मैं उपयोग करता हूं FastCGI, केवल एक सतत प्रक्रिया बनाई जाएगी, और इसे PHP वेबसाइटों द्वारा भी अपनाया जाता है। प्लस FastCGI इंटरफ़ेस केवल एक अनुरोध के लिए एक ऑब्जेक्ट बनाता है और इसमें बहुत अच्छा प्रदर्शन होता है, क्योंकि रैक के विपरीत जो एक बार में 7 ऑब्जेक्ट बनाता है।

क्या कोई विशिष्ट कारण है कि मुझे सीजीआई का उपयोग नहीं करना चाहिए? या यह सिर्फ झूठी धारणा है और सीजीआई / फास्टसीजीआई का उपयोग करना पूरी तरह ठीक है?

उत्तर:

उत्तर № 1 के लिए 1

सीजीआई, जिसके द्वारा मेरा मतलब इंटरफ़ेस और हैसामान्य प्रोग्रामिंग पुस्तकालयों और इसके आसपास के अभ्यास, एक अलग समय में लिखा गया था। यह अनुरोध हैंडलरों का एक दृश्य है जो वेबसर्वर से पर्यावरण चर और मानक I / O धाराओं के माध्यम से जुड़ी अलग प्रक्रियाओं के रूप में है।

यह उस दिन अत्याधुनिक था, जब वास्तव में "वेब ढांचे" और "एम्बेडेड सर्वर मॉड्यूल" नहीं थे जैसा कि हम आज उनके बारे में सोचते हैं। इस प्रकार ...

फिर, सीजीआई मॉडल प्रति कनेक्शन एक नई प्रक्रिया पैदा करता है। प्रक्रियाओं को बढ़ाने के दौरान दर असल इन दिनों सस्ते है, भारी वेब ऐप प्रारंभिक - मॉड्यूल के स्कोर पढ़ने और विश्लेषण करना, डेटाबेस कनेक्शन बनाना आदि - यह काफी महंगा बनाता है।

सीजीआई बहुत कम स्तर (आईएमएचओ) डिजाइन की ओर जाता है

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

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

हां, रैक :: बिल्डर जैसे कुछ कोजीआई के शीर्ष पर लागू किया जा सकता है, लेकिन, यह बिंदु है। इसे "अबास्ट्रक्शन का एक परत होना चाहिए सीजीआई के शीर्ष पर.

सीजीआई को चुपके से खारिज कर दिया जाता है

सीजीआई के बावजूद इसके अंदर पूरी तरह से काम कर रहा हैसीमाएं, सरल और व्यापक रूप से समझने के बावजूद, सीजीआई को अक्सर हाथ से बाहर कर दिया जाता है। अगर आप सीजीआई को जानते हैं तो भी आपको हाथ से बाहर कर दिया जा सकता है।

---

उत्तर № 2 के लिए 1

सीजीआई का उपयोग न करें। कृपया। यह इसके लायक नहीं है। 1 99 0 के दशक में जब कोई भी बेहतर नहीं जानता था तो यह एक अच्छा विचार प्रतीत होता था, लेकिन वह तब था जब स्क्रिप्ट कम थी, विशेष मामलों के लिए प्रयुक्त होता है जैसे प्रपत्र सबमिशन को संभालना, पूरी साइटें नहीं चला रहा।

फास्टसीजीआई एक "बेहतर सीजीआई" का प्रयास है, लेकिन यह अभी भी कई तरीकों से कम है, खासकर क्योंकि आपको अपनी फास्टसीजीआई कार्यकर्ता प्रक्रियाओं का प्रबंधन करना है।

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

मुझे नहीं पता कि जब आप कहते हैं कि रैक "एक बार में 7 ऑब्जेक्ट्स" बनाता है, तब तक इसका मतलब यह नहीं है कि 7 अलग-अलग रैक प्रक्रियाएं किसी भी तरह चल रही हैं या आपने अपने कार्यान्वयन में गलती की है।

मैं एक उदाहरण के बारे में नहीं सोच सकता जहां सीजीआई रैक समकक्ष से बेहतर होगा।

---

जवाब के लिए 0 № 3

वास्तव में सीजीआई, रैक इत्यादि के बारे में बहुत भ्रम मौजूद है। जैसा कि मैंने वर्णन किया है यहाँ, रैक एक एपीआई है, और फास्टसीजीआई एक प्रोटोकॉल है। सीजीआई भी एक प्रोटोकॉल है, लेकिन इसके संकीर्ण अर्थ में भी एक कार्यान्वयन है, और जो भी आप बोल रहे हैं उसके लिए फास्टसीजीआई जैसी ही बात नहीं है। तो चलो पृष्ठभूमि से शुरू करें।

90 के दशक के शुरुआती दिनों में, वेब सर्वर बस पढ़ते थेडिस्क से फ़ाइलें (एचटीएमएल, छवियों, जो कुछ भी) और उन्हें क्लाइंट को भेजा। लोगों ने अनुरोध के समय कुछ प्रसंस्करण करना शुरू कर दिया, और शुरुआती समाधान जो एक कार्यक्रम चलाया गया था, वह प्रोग्राम को पढ़ने के बजाए क्लाइंट को वापस भेजा गया परिणाम उत्पन्न करेगा। इसके लिए "प्रोटोकॉल" वेब सर्वर को एक यूआरएल दिया जाना था जिसे इसे प्रोग्राम के रूप में निष्पादित करने के लिए कॉन्फ़िगर किया गया था (उदा। /cgi-bin/my-script), जहां वेब सर्वर एक सेट स्थापित करेगाअनुरोध के बारे में विभिन्न जानकारी के साथ पर्यावरण चर के मानक और मानक इनपुट पर अनुरोध के शरीर के साथ कार्यक्रम चलाते हैं। इसे "कॉमन गेटवे इंटरफ़ेस। "

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

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

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

• Apache में PHP को एम्बेड किया गया है, ताकि "अपाचे सर्वर कोड" केवल "PHP सर्वर कोड" को कॉल कर सके जो कि एक ही प्रक्रिया का हिस्सा है; और

• अपाचे को बिल्कुल नहीं चलाएं, लेकिन वेब सर्वर रूबी (या पायथन, या जो कुछ भी) में लिखा जाए और अधिक रूबी कोड लोड करें और चलाएं जिसे अनुरोध को संभालने के लिए कस्टम लिखा गया है।

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

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

तो क्या आप "सीजीआई, फास्टसीजीआई, दूसरे का उपयोग कर रहे हैंइंटर-प्रोसेस प्रोटोकॉल, या इंट्रा-प्रोसेस प्रोटोकॉल, कोई फर्क नहीं पड़ता; आप रैक का उपयोग करने वाले किसी भी व्यक्ति को तब तक कर सकते हैं जब तक कि सर्वर इसके बारे में जानता हो या उस प्रक्रिया से बात कर रहा हो जो सीजीआई, फास्टसीजीआई या जो भी हो और उस अनुरोध के आधार पर रैक-अनुरूप कोड को समझ सके।

इसलिए:

प्रदर्शन स्केलिंग के लिए, आप निश्चित रूप से CGI का उपयोग नहीं करना चाहते हैं; आप फास्टसीजीआई, एक समान प्रोटोकॉल (जैसे कि टॉमकैट वन) का उपयोग करना चाहते हैं, या सीधे कोड की कॉलिंग इन-प्रोसेसिंग करना चाहते हैं।

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

---