Drupal से Yii में अपग्रेड करने के 7 कारण

आई लव ड्रुपल पर आधारित।
JiLiZART के अनुरोध पर प्रकाशित (अनुवाद, जैसा कि मैं इसे समझता हूं, उसे भी)।
मूल: erickennedy.org



लेख एक वर्ष पहले दिनांकित किया गया है, ताकि अनुवाद में समय सीमा बच जाए


Drupal 7 को जल्द ही रिलीज़ किया जाएगा, इसलिए कई संगठनों को यह तय करना होगा कि क्या उन्हें Drupal 5 से अपग्रेड करना चाहिए या 6. Drupal अच्छा है यदि आप बहुत सारी साइट बनाते हैं और आपको जल्दी और बिना बहुत कोड लिखे नई साइट्स बनाने की आवश्यकता होती है, या यदि आपको बस ज़रूरत है स्टेरॉयड ब्लॉग।

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

मैं साइट का तकनीकी निदेशक हूं, जो 30 अप्रैल 2010 को Drupal से Yii में बदल गया था। उस समय, जब हम सिर्फ स्थानांतरण की चर्चा कर रहे थे, तो सही जानकारी प्राप्त करना मुश्किल था, Yii के बारे में किताबें भी नहीं थीं। Drupal से Yii में स्विच करने के कुछ संदर्भ थे, लेकिन मुझे शांत रखने के लिए उनके पास पर्याप्त डेटा नहीं था। मुझे चिंता थी कि Yii हमारी अत्यधिक अनुकूलित Drupal स्थापना की तुलना में धीमा हो सकता है, इसलिए मैंने 30 दिनों में हमारी साइट के 20% कोर (जो हमें सभी कार्यक्षमता का 80% दिया था) को फिर से लिखने का फैसला किया। यह फ्रेमवर्क की उत्पादकता और उत्पादकता का परीक्षण करने का एक शानदार तरीका प्रतीत होता है, और यदि Yii एक महीने के काम के बाद परिणाम नहीं देता है, तो हम हमेशा Drupal में वापस जा सकते हैं और किसी भी नए डेटा को वापस स्थानांतरित कर सकते हैं।

Yii 150,000 नोड्स (प्रत्येक फिर से लिखे गए URL के साथ) और प्रति दिन 50,000 आगंतुकों के साथ हमारे Drupal साइट की तुलना में बहुत तेज था। हां, हमने इन 30 दिनों (और अगले 15) में पागल की तरह काम किया, लेकिन यह इसके लायक था। हम समय व्यतीत करते थे कि हम Yii पर विकसित होने पर Drupal में धीमे प्रश्नों को फंसाने और ठीक करने के लिए उपयोग करते थे। Yii का वास्तविक लाभ बाद में आया जब हमने अपनी साइट को फिर से डिज़ाइन किया।
Yii MVC के साथ, हमने Drupal में दर्जनों के खिलाफ सिर्फ 2 लेआउट फ़ाइलों को बदल दिया।

मुझे खेद है कि हमने एक साल पहले पार नहीं किया। यहाँ हमने सीखा है:

1. ड्रुपल खरोंच से शुरू करने का सबसे अच्छा तरीका नहीं है । Drupal का मुख्य विक्रय बिंदु " अपना खुद का CMS क्यों बना?" "। कई वेब डेवलपर्स की तरह, मैंने स्क्रैच से सभी वेब एप्लिकेशन ( 1999 और 2000 में ) लिखे और ऑप्रेशन प्रमाणीकरण, सत्यापन, एसक्यूएल इंजेक्शन, आदि के लिए अपना खुद का कोड लिखने के बजाय, एप्लिकेशन की अनूठी व्यावसायिक आवश्यकताओं पर ध्यान केंद्रित करने के अवसर की सराहना की।
   2007 की शुरुआत में मैंने जिस कंपनी की मदद की थी, उसमें एक ड्रुपल साइट प्रोटोटाइप था, और मैं यह देखने के लिए तैयार था कि रूबी ऑन रेल्स के लिए ड्रापल क्या कर सकता है। रूबी की दीवानगी ने 1997 में मुझे जावा क्रेज की याद दिला दी। मैं 1997-99 में WebEx प्रतियोगी में इंटर्न था, जिसने सर्वर हार्डवेयर और वीएम अनुकूलन स्केलेबिलिटी के लिए अनुमति देने से पहले जावा में अपना सर्वर लिखना शुरू करके अपनी उत्पादकता को मार दिया था। PHP ने फ्रेंडस्टर और फेसबुक को रीमेक करने में खुद को साबित कर दिया है, और अगर हम रूबी में स्केलेबिलिटी के मुद्दों में भाग लेते हैं, तो हमारे उपयोगकर्ता फेल व्हेल नहीं देखना चाहते हैं।
   
   बेशक, PHP में प्रत्येक पंक्ति को लिखने की तुलना में Drupal के साथ शुरू करना आसान है। लेकिन, 2008 में शुरू किए गए PHP 5 फ्रेमवर्क का एक गुच्छा और 2009 में परीक्षण किया गया । एक PHP डेवलपर, अब एक वेब एप्लिकेशन बनाना शुरू कर रहा है (और भविष्य में साइट पर काम करना जारी रखेगा), या तो एक फ्रेमवर्क का चयन करेगा या PHP लाइब्रेरीज़ (PECL या PEAR) का उपयोग करके स्क्रैच से शुरू करेगा।
   
2. यदि ड्रुपल ढांचा है, तो केवल रूबी गोल्डबर्ग मशीन इसे पसंद करेगी ( मशीन जो एक जटिल तरीके से सरल क्रियाएं करती है )। Drupal को PHP प्रोग्रामिंग की अधिक जानकारी के बिना एक्स्टेंसिबल होने के लिए डिज़ाइन किया गया है। यह अच्छा है यदि आप साइट को सरल सामग्री के साथ स्टाइल करते हैं या यदि आपके पास कम ट्रैफ़िक साइट है। यदि आप फ़ॉर्म्स बदलने और कार्यक्षमता जोड़ने के लिए पूर्णकालिक लेखन मॉड्यूल काम करते हैं, तो आप Drupal कार्यक्षमता को दबाने में अधिक समय बिताएंगे , जिसे आपको रूपरेखा पर बनाने की आवश्यकता नहीं है। Yii में विपरीत दृष्टिकोण है - यदि आप काफी तेज़ हैं तो रूबी जैसे ORM पर रूबी का उपयोग कर सकते हैं और केवल 10% क्वेरीज़ को ऑप्टिमाइज़ कर सकते हैं, जिन्हें आपको MySQL में फिर से लिखना होगा।
   
3. समुदाय द्वारा योगदान किए गए मॉड्यूल को करतब ("धोखाधड़ी"?) और अत्यधिक जटिलता से होने वाली त्रुटियां होने का खतरा है।
   Drupal के लिए बहुत सारे कंट्रिब मॉड्यूल हैं, और यदि आपके पास पूर्णकालिक डेवलपर्स हैं, तो आप शायद यह तय करते हैं कि हमने इसे कैसे किया, कुछ अतिरिक्त मॉड्यूल को अपने में आत्मसात करने के लिए। ड्रुपल इमेज एडिटिंग और कैशिंग मॉड्यूल इसका प्रमुख उदाहरण हैं। चूंकि मॉड्यूल को सामान्य समस्याओं को हल करने के लिए डिज़ाइन किया गया है (ताकि वे अन्य मॉड्यूल की एक मनमानी संख्या के साथ काम कर सकें!), वे टन की कार्यक्षमता शामिल करते हैं जो आप कभी भी उपयोग नहीं करेंगे । हमारे मामले में, हमें कई आकारों के पूर्वावलोकन करने की आवश्यकता है, जो हमें ImageMagick का उपयोग करने के लिए मिलेगा। ऐसा करने के लिए, हमें 4 मॉड्यूल शामिल करने थे, प्रत्येक में PHP फ़ाइलों का एक गुच्छा: ImageAPI, ImageAPI for ImageMagick, ImageCache, और ImageCache UI, के बजाय वास्तविक डेटाबेस के लिए 2 डेटाबेस तालिकाओं में थंबनेल बनाने के लिए। यदि मॉड्यूल श्रृंखला के एक हिस्से को अपडेट करते समय कुछ गलत हो जाता है, तो इसके कारणों को खोजने में बहुत समय लगेगा, बजाय इसके कि आपको क्या चाहिए।
   
   Yii में छवियों के साथ काम करने के लिए एक एक्सटेंशन भी है (कोहना से अनुकूलित), लेकिन इसमें कार्यक्षमता शामिल है जिसकी हमें ज़रूरत नहीं है (घुमाएँ! फ्लिप!) और यह इस तथ्य से जटिल है कि यह ImageMagick और GD (GD के बीच पारदर्शी रूप से स्विच करने के लिए डिज़ाइन किया गया है) 2MB से बड़ी फ़ाइल समस्याएँ हैं )। इन सब के बावजूद, यह अभी भी आपको रिव्रीटाइट का उपयोग करके मक्खी पर छवियों का आकार बदलने की अनुमति नहीं देता है यदि पूर्वावलोकन मौजूद नहीं है।
   इसलिए मैंने अभी एक index.php फ़ाइल बनाई है जो छवियों के लिए समर्पित सर्वर पर रिटर्रिएट रिक्वेस्ट को प्रोसेस करती है और बाइनरी में बदलने के लिए सीधे शेल्ड कमांड को भेजती है। इसका अर्थ है कि ये रिवाइटररूल अनुरोध Yii की index.php फ़ाइल को प्रभावित नहीं करते हैं, ओवरहेड को कम करने और छवियों का आकार बदलने और कैश को रीसेट करने के लिए आवश्यक समय। यह php में सिर्फ एक पेज है जो बाइनरी को सिंगल कॉल में पास किए जाने वाले तर्कों को लेता है, और ImageMagick अपडेट होने पर समर्थन और परीक्षण करना बहुत आसान है।
   
4. Drupal में PHP 4 सामान संगतता है। एक बार, जब मैंने PHP फ्रेमवर्क पर एक नज़र डालने का फैसला किया, तो मुझे जल्दी से एहसास हुआ कि मुझे केवल 100% PHP5 OOP फ्रेमवर्क चाहिए। आपको कई लोग नहीं मिलेंगे जो दावा करते हैं कि हुक सिस्टम ओओपी दृष्टिकोण से बेहतर है। हालाँकि Drupal 7 के लिए PHP5 की आवश्यकता है, जैसे CodeIgniter 1.0 और अन्य पुराने PHP फ्रेमवर्क, फिर भी वे बहुत अधिक संगतता रखते हैं। ऐसा सामान कौन चाहता है?
   
5. अपने Drupal 5 साइट को धीमा करने के लिए Drupal 6 या 7 नहीं चाहिए? अप्रचलित jQuery के साथ सौदा नहीं करना चाहते हैं? अधिकांश साइटों के लिए, यह सामान्य है। हम वास्तव में गति की परवाह करते हैं, क्योंकि Google और Microsoft ने दिखाया है कि उपयोगकर्ता तेज़ साइटों के प्रति अधिक वफादार होते हैं। 2009 में, जब Drupal 6 स्थिर हो गया, हम औसत गति लाभ के कारण Drupal 5 पर अटक गए। समस्या यह है कि Drupal 5 में jQuery 1.0 शामिल है। आप कंट्रिब मॉड्यूल को स्थापित कर सकते हैं, जो jQuery को 1.2 में पैच करता है (और इसे संदर्भित करने वाले Drupal फ़ंक्शन को अपडेट करता है), लेकिन यह संस्करण भी पुराना है। JQuery 1.3x और Drupal 5 के बारे में भूल जाओ।
   
6. Drupal में Drupal Field / (CCK) API आपको पागल कर देगा, और यह Drupal 7 कोर का हिस्सा है । जब आप $ नोड-> फ़ील्ड_आईपी [0] ['मूल्य'] का उपयोग कर सकते हैं, तो $ नोड-> आईपी का उपयोग क्यों करें। और यदि आप दो अलग-अलग प्रकार की सामग्री चाहते हैं, तो एक ही नाम के साथ एक फ़ील्ड है, CCK उन्हें आश्चर्यजनक तालिका नामों (field_ip_value) के साथ अपनी तालिका (content_field_ip) में डाल देगा। बेशक, नोड लोड होने पर ड्रुपल इस गंदगी को समझ सकता है, लेकिन इसे देखना अच्छा नहीं है। सभी अतिरिक्त CCK तालिकाओं को संसाधित करने के लिए MySQL प्रश्नों को बहुत सारे LEFT JOIN की आवश्यकता होती है, और वे अनावश्यक जटिल प्रश्न जो धीमे क्वेरी लॉग में बहुत बार समाप्त होते हैं। मैं आखिरकार इन सभी धीमे प्रश्नों को अनुकूलित करने की कोशिश में थक गया और मैंने CCK से छुटकारा पाने का फैसला किया, जिसके कारण मुझे PHP फ्रेमवर्क, और फिर Yii तक ले जाना पड़ा।
   Yii के लिए हमारे डेटा को माइग्रेट करने में उतना ही समय लगता है, जब हम Drupal पर रहते हुए CCK मॉड्यूल से छुटकारा पा रहे थे। फिर भी, हम उन सभी अतिरिक्त तालिकाओं के बिना एक स्वच्छ डेटाबेस के साथ शुरू करने में सक्षम थे जो ड्रुपल अपनी आंतरिक आवश्यकताओं के लिए उपयोग करता है। हमारे पुराने डेटाबेस में 173 टेबल थे, नए 54 में।
   
7. Drupal Yii की तुलना में बहुत धीमा है।
   
   Drupal विस्तार योग्य है यदि आप सभी को मेमेकैड और APC के साथ कैश करते हैं और सभी धीमी अनुरोधों को फिर से लिखते हैं। कैशिंग विशेष रूप से महत्वपूर्ण है यदि आप सभी लिंक के लिए एसईओ पतों का उपयोग करते हैं, क्योंकि प्रत्येक कॉल एल () एक और डेटाबेस क्वेरी उत्पन्न करता है। तो, Yii में 3-5 की तुलना में औसत पृष्ठ में 50+ अनुरोध हैं। संक्रमण के बाद, Google वेबमास्टर टूल्स के अनुसार, हमारा औसत डाउनलोड समय 163ms से घटकर 63ms हो गया है। इससे भी बेहतर, Yii + APC इतना तेज़ है कि हमें कोड और संचालन को याद रखने, उपयोग करने की आवश्यकता नहीं है।
   

हमारे सर्वर आँकड़े अपने लिए बोलते हैं। आगंतुकों (अपाचे प्रक्रियाओं) से एक साथ अनुरोधों की एक ही संख्या के लिए, डेटाबेस और सीपीयू का उपयोग कम हो गया। स्मृति उपयोग लगभग समान रहता है। पिछले एक वर्ष में, हमारे ट्रैफ़िक में प्रति माह 60% से 1.5 मिलियन की वृद्धि हुई, जबकि MySQL पर भार 66% तक गिर गया