PHP मरने के लिए बनी है

डिस्क्लेमर : मेरे पीछे दस साल से अधिक PHP का विकास है। मैंने इसका उपयोग तब शुरू किया जब PHP4 सिर्फ एक बच्चा था, और PHP5 सिर्फ Zend का सपना था। उसकी मदद से, मैंने बहुत कुछ किया, मैं उससे प्यार करता था, शापित था और बिना शर्म के, उसे बढ़ता और विकसित होते देखता था। मैं अभी भी कुछ विरासत में मिली परियोजनाओं में इसका उपयोग करता हूं, लेकिन मैं अब इसका उपयोग नहीं करना पसंद करता हूं। मैं यह भी नोट करना चाहता हूं कि मैं लेख में उल्लिखित रूपरेखा या उपकरण के रचनाकारों के साथ सहयोग नहीं करता हूं।

टीएल; डीआर (अंग्रेजी बहुत लंबी; पढ़ी नहीं गई। इसलिए, विशेष रूप से, वे कहते हैं कि जब आप पूरी तरह से पढ़ने के लिए बहुत आलसी होते हैं - लगभग प्रति।): यदि आपकी परियोजना पृष्ठभूमि प्रक्रियाओं (पृष्ठभूमि सेवाओं, डेमॉन) के कार्यों पर आधारित है। ।) PHP से बचें।

मेरी राय में, ज्यादातर मामलों में, PHP नफरत करने वालों को एक बहुत महत्वपूर्ण बिंदु याद आती है: PHP को मरने के लिए बनाया गया था । इसका मतलब यह नहीं है कि प्रोग्रामिंग भाषा के बजाय एक सक्षम (कुछ हद तक) गायब हो जाएगी; इसका सिर्फ इतना अर्थ है कि आपका PHP कोड हमेशा के लिए नहीं चल सकता है। वर्तमान में, 2000 में पहली आधिकारिक रिलीज के 13 साल बाद , यह विचार अभी भी मुझे काफी उचित लगता है।

एक मरने वाले कार्यक्रम का मॉडल

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

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

अब वेबसाइट ही नहीं

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

चलो इस क्षण को छोड़ दें। अब हम एक वास्तविक और जटिल आवेदन लिख रहे हैं। जटिलता के साथ, प्रोग्राम कोड की मात्रा बढ़ रही है। मान लीजिए कि आप एक बहुत सक्षम प्रोग्रामर हैं। आप PHP 5.x और आधुनिक प्रोग्रामिंग विधियों का उपयोग कर रहे हैं। सब कुछ इंटरफेस और कक्षाओं में बहुत सार है। आप जानते हैं कि मौजूदा पुस्तकालयों के साथ क्या करना है। अब, आप अपने स्वयं के ORM मॉडल, तृतीय-पक्ष कोड, विकसित इंटरफ़ेस पर निर्भर हो सकते हैं, शायद आपका क्लाइंट API तृतीय-पक्ष REST इंटरफेस आदि के लिए कार्य करता है। सब कुछ PHP में लिखा है।

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

इंटरएक्टिव कॉल करें

उपरोक्त वर्णित चीजों का सबसे खराब क्रियान्वयन, हालांकि, काफी परिचित लग सकता है: इससे कोई फर्क नहीं पड़ता कि PHP या चुने हुए ढांचे की आवश्यकता है - निश्चित रूप से, $ 5 प्रति माह की मेजबानी में आपके पास SSH पहुंच, क्रोन उपयोगिता या एक समान उपकरण नहीं है।

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

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

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

राक्षसों को समन करो

वास्तविक दुःस्वप्न तब शुरू होता है जब राक्षसों या अधिक कठिन प्रक्रियाओं का निर्माण सही समाधान लगता है। पुष्टि में WebSocket कनेक्शन स्थापित करना और बनाए रखना या निर्माता-उपभोक्ता घटक बनाना शामिल हो सकते हैं।

लेकिन PHP आपको नीचा दिखाएगी।

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

बेशक, "आपकी स्मृति को बर्बाद न करें" के संदर्भ में सुधार थे, लेकिन वे पर्याप्त नहीं थे। जैसे ही जटिलता बढ़ती है या भार बढ़ता है, सब कुछ टूट जाता है। निम्नलिखित कोड स्निपेट पर विचार करें:

class FOO {
    public $f;
}

class BAR {
    public $f;
}

while(1) {
    $a = new FOO();
    $b = new BAR();
    $a->f = $b;
    $b->f = $a;
    print "Memory usage: " . number_format(memory_get_usage(true)) . " bytes\n";
    unset($a);
    unset($b);
}

, , , . , PHP , , , , unset().

. , , , . , , , : ORM. , , , , . , . , … , ? PHP , , , , , PHP .

, PHP, : ( ) . (Garbage collection — .) PHP 5.3 . : «, ?». 2009 , . ? . , PHP , , , . PHP, — .

. PHP , :

Fatal error: Exception thrown without a stack frame in Unknown on line 0

? , . 0 PHP-. , , . , PHP. , , : , , . .

, . . PHP , . .

? , PHP — web- ( «yes, i'm a hyred keyboard» — . .) — . , ; , , , , . , , PHP , . , , .

Python, virtualenv, Flask, Supervisor Gunicorn. , , — -. , . : ? , Python . , . , . , PHP .

, . , memory_limit . cron, shell- UNIX. PHP web-, — . , , , , , , , . , 30- .

, , , - PHP. , , , PHP 5.4 PHP 5.5 .

, .

HN Reddit.