फास्टसीजीआई वेब सर्वर पर कैसे काम करता है (उदाहरण के लिए अपाचे 2.2+)?

Question

मैंने फास्टसीजीआई (एफसीजीआई-2.4.0) के स्रोतों पर एक नज़र डाली और वास्तव में कांटा का कोई संकेत नहीं है। यदि मैं सही हूं तो वेब सर्वर फास्टसीजीआई मॉड्यूल (इसमें संकलित या एसओ/डीएलएल के रूप में लोड) के लिए एक प्रक्रिया फैलता है और मुख्य सॉकेट (पोर्ट टीसीपी: 80 आमतौर पर) पर नियंत्रण रखता है।

* फास्टसीजीआई मॉड्यूल "लॉक" पर फ़ाइल फ़ाइल लॉक (libfcgi/os_unix.c: 989) का उपयोग करते हुए सॉकेट पूरी फ़ाइल डिस्क्रिप्टर (वास्तव में सुनो सॉकेट) पर; इस तरह जब नए कनेक्शन आय केवल फास्टसीजीआई मॉड्यूल इन प्रक्रियाओं को संसाधित करने में सक्षम है। आने वाली सॉकेट लॉक को HTTP रीक प्रोसेसिंग को सौंपने से ठीक पहले रिलीज़ किया जाता है।

रूप FastCGI मॉड्यूल के रूप में देखा बहु प्रक्रिया/एन FastCGI का धागा (कोई आंतरिक कांटा/pthread_create के उपयोग) मुझे लगता है कई निरंतर कनेक्शन की समवर्ती हैंडलिंग वेब सर्वर (OS_SpawnChild के माध्यम से) से spwaning के माध्यम से प्राप्त किया जाता है नहीं है मॉड्यूल प्रक्रियाओं। यदि हम स्पॉन करते हैं, उदाहरण के लिए, 3 फास्टसीजीआई प्रक्रियाएं (अपाचे 3 x OS_SpawnChild कहते हैं), क्या इसका मतलब यह है कि हम केवल अधिकतम 3 अनुरोधों को समवर्ती रूप से सेवा कर सकते हैं?

ए) क्या फास्टसीजीआई के सही तरीके से काम करने का मेरा दृष्टिकोण है?

बी) ओएस एक नई प्रक्रिया स्थानीय डीबी से कनेक्शन अंडे/बनाने के लिए लागत नगण्य माना जा सकता है, तो एक पुराने जमाने निष्पादन योग्य दृष्टिकोण के खिलाफ FastCGI के फायदे क्या हैं?

धन्यवाद, एमा! :-)

Answer 1

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

Answer 2

सामान्य सीजीआई पर फास्टसीजीआई से गति लाभ यह है कि प्रक्रियाएं लगातार हैं। जैसे यदि आपके पास खोलने के लिए कोई डेटाबेस हैंडल है, तो आप उन्हें एक बार कर सकते हैं। किसी भी कैशिंग के लिए वही।

मुख्य लाभ एक नया PHP/perl/आदि बनाने के लिए नहीं आता है। प्रत्येक बार दुभाषिया, जो एक आश्चर्यजनक समय लेता है।

यदि आप एकाधिक समवर्ती कनेक्शन प्रबंधित करना चाहते हैं, तो आपको फास्टसीजीआई प्रक्रियाओं को चलाने की कई प्रक्रियाएं होनी चाहिए। फास्टसीजीआई किसी भी तरह की विशेष सहमति के माध्यम से अधिक कनेक्शन को संभालने का एक तरीका नहीं है। यह व्यक्तिगत अनुरोधों को तेज़ करने का एक तरीका है, जो बदले में अधिक अनुरोधों को संभालने की अनुमति देगा। लेकिन हाँ आप सही हैं, अधिक समवर्ती अनुरोधों के लिए अधिक प्रक्रियाओं की आवश्यकता होती है।

Answer 3

दरअसल

,

इतनी के रूप में देखा (ए), ठीक है अब क्या है के बारे में (बी)? यदि मैं निष्पादन योग्य (ठीक से संकलित सी/सी ++ प्रोग्राम, पर्ल/php/... जैसी स्क्रिप्ट नहीं) के बारे में बात कर रहा हूं, और यदि हम प्रक्रिया स्पैन लागत और डीबी नई कनेक्शन लागत को नगण्य मानते हैं, तो यह दृष्टिकोण (फास्टसीजीआई) है सादे CGI निष्पादन योग्य की तुलना में केवल छोटे लाभ की तरह?

मेरा मतलब है कि लिनक्स एक प्रक्रिया (फोर्किंग) में बहुत तेजी से चल रहा है और यदि डीबी स्थानीय रूप से चल रहा है (उदाहरण के लिए एक ही मेजबान MySQL), तो एक नया निष्पादन योग्य शुरू करने और डीबी से कनेक्ट करने में लगने वाला समय है व्यावहारिक रूप से 0. इस मामले में, व्याख्या किए जाने के लिए कुछ भी नहीं, केवल अपाचे सी/सी ++ मॉड्यूल इससे भी तेज होगा।

फास्टसीजीआई दृष्टिकोण का उपयोग करके आप मेम लीक के लिए और भी कमजोर होते हैं क्योंकि प्रक्रिया हर बार फोर्क/पुनरारंभ नहीं होती है ...इस बिंदु पर, यदि आपको सी/सी ++ में अपना सीजीआई विकसित करना बेहतर होगा तो पुराने स्कूल सीजीआई और/या अपाचे सी/सी ++ मॉड्यूल का उपयोग सीधे बेहतर नहीं होगा?

फिर से, मैं स्क्रिप्ट्स (perl/php/...) के बारे में बात नहीं कर रहा हूं, मैं संकलित सीजीआई के बारे में बात कर रहा हूं।

धन्यवाद, चीयर्स, एमा! :-)

Answer 4

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

यह महत्वपूर्ण है जब आपके पास बहुत कम है।