2010-05-28 7 views
16

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

मैं सवाल पूछता हूं क्योंकि मैं एक परियोजना प्रबंधन वेब एप्लिकेशन बनाना चाहता हूं और मैं अभी भी कुछ ढांचे के बीच संकोच करता हूं। मुझे ज़ेंड सीखने में कुछ परेशानी हुई है, लेकिन इमो मैंने काफी मेहनत की कोशिश नहीं की है।

तो निष्कर्ष में, इसके बाद के संस्करण पहला सवाल के अलावा, मैं एक और सवाल पूछना चाहूँगा:

मैं एक परियोजना प्रबंधन उपकरण बनाने के लिए (जो एक बहुत बड़ी परियोजना है) चाहते हैं, निम्न में से किसके आप का सुझाव चाहिए, developement समय पर विचार, जिसके परिणामस्वरूप आवेदन की गति, और अंतिम उत्पाद की मजबूती:

  • Symfony
  • CakePHP
  • Zend फ्रेमवर्क
  • +०१२३५१६४१०

मुझे यह भी उल्लेख करना चाहिए कि मुझे इनमें से किसी भी ढांचे को नहीं पता है, और मैं उनमें से एक (कम से कम) सीखना चाहता हूं।

+1

जब से तुम चाहिए उत्पादन में किसी प्रकार का कैश का उपयोग करें, मुझे नहीं लगता कि गति अंतर यह महत्वपूर्ण है। बस उस व्यक्ति को चुनें जिसे आप सबसे अधिक आरामदायक बनाते हैं। – baloo

+0

मुझे लगता है कि यह बहुत कठोर है; हालांकि इसका उत्तर दिया गया है :-) – richsage

+0

मुझे नहीं लगता था कि एक परियोजना प्रबंधन उपकरण के लिए गति एक प्रमुख चिंता होगी .. – Tom

उत्तर

20

बेंचमार्क के साथ समस्या यह है कि वे आम तौर पर खुद को असली दुनिया में उधार नहीं देते हैं। एक असली एप्लिकेशन लिखें, और आप देखेंगे कि गति के आने पर सभी ढांचे एक-दूसरे की परिमाण के क्रम में हैं। और यदि आप ढांचे का उपयोग नहीं करते हैं (और प्रोग्राम कैसे करें) तो वे सभी धीमे होते हैं।

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

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

+2

मैं यह जोड़ना चाहता हूं कि ढांचा लगभग प्रदर्शन बाधा का नतीजा न हो। यह कई मामलों में अन्य गरीब तकनीकों का उपयोग किया जा रहा है। 1 खराब सीएसएस चयनकर्ता आपके प्रदर्शन को उतना ही मार सकता है जितना ढांचा का उपयोग करना। मुझे लगता है कि यह सवाल चर्चा की गई संकलित भाषा वीएस स्क्रिप्टिंग भाषाओं की तरह है। जैसा कि हमने एचएफपी के साथ देखा, ऐसा लगता है कि यह केवल 30% लाभ है, जिसका मतलब है कि आपके पास 5000 से कम सर्वर होने पर मामलों के लिए कुछ भी नहीं है। – Parris

2

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

+0

हालांकि यह इंगित करना हमेशा आसान होता है कि I/O आमतौर पर एक वेब ऐप में बाधा होगी (मैं इस मामले में, इस तरह से सहमत हूं) मुझे लगता है कि आप अपने निष्कर्ष के साथ केवल एक बाल हैं जो सभी ढांचे को बनाए जाते हैं बराबरी का। –

+4

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

8

मैं केकेपीएचपी v1.3 की सलाह देता हूं क्योंकि यह तेज़ और आसानी से समझ में आता है। आपको इस ढांचे से संबंधित बहुत अच्छी मदद मिलेगी (दस्तावेज़ीकरण और ट्यूटोरियल)। दस्तावेज़ीकरण अच्छी तरह से लिखा गया है। भले ही आप कहीं भी अटक गए हों, आप स्टैक ओवरफ्लो या केकेएफपी Google समूह या Google पर खोज करके समाधान ढूंढ पाएंगे।

मैंने केकफ़्पी (1.2 और 1.3) के दोनों संस्करणों पर काम किया है और मैंने ज़ेंड फ्रेमवर्क पर भी हाथ लगाने की कोशिश की है (मैंने भी अपने स्तर का सबसे अच्छा प्रयास किया लेकिन लेआउट के कार्यान्वयन के समय ढांचे में फंस गया) ।

लेकिन केकफ़्प पर एक वर्ष से अधिक समय व्यतीत करने के बाद मुझे यह कहते हुए गर्व है कि यह काम करने के लिए सबसे अच्छा ढांचा है।

+1

केक 2 भी तेज है, और संस्करण 3 में इसे और भी बेहतर बनाने के लिए शोध किया जा रहा है। –

6

फ्रेमवर्क आमतौर पर बेहतर कोड संगठन, घटकों की पुन: प्रयोज्यता, टेस्टेबिलिटी, और सामान्यीकरण, अनुप्रयोग गुणवत्ता & रखरखाव का लक्ष्य रखता है। यह अधिक प्रदर्शन उन्मुख पसंद नहीं हो सकता है।

मुझे साइटें सिम्फनी के साथ चल रही हैं जो बहुत तेज हैं, बेंचमार्क मूल स्थिर HTML टेम्पलेट के करीब आता है।

एक HTML स्थिर पृष्ठ के अंदर स्पैगेटी कोड डालने की तुलना में एक फ्रेमवर्क (और एक ओआरएम जैसे डॉक्टर) का उपयोग करते समय प्रदर्शन समस्या अधिक तेज़ी से हो सकती है। यह ध्वनि सामान्य है मेरे लिए: अधिक treatements, अधिक सत्यापन, मोड निर्भरता, पार्स करने के लिए अधिक कोड, आदि

आप तेजी से आवेदन करने के लिए mant हैं, वे कर रहे हैं तरीके के लिए मूल रूप से है:

  1. तेजी से प्राप्त करें हार्डवेयर, इसकी लागत होती है, लेकिन यह लागत इसके लायक हो सकती है यदि यह लागत प्रोग्रामर & इंजीनियरों की लागत के तहत है, जो आमतौर पर मामला है।
  2. सॉफ़्टवेयर अनुकूलित करें, इस तरह से बड़ा कदम कई स्तरों पर कैशिंग का उपयोग करना है: ऑपोड, डेटाबेस क्वेरी परिणाम, कोई भारी वस्तुएं, एचटीएमएल प्रतिपादन (आंशिक और संपूर्ण)।

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

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

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

तो टीम अनुभव बहुत चौड़ा है और किसी को भी अपनी ही वरीयता है, तो मैं personnaly सुझाव है Symfony, अपने कैशिंग क्षमताओं के रूप में आता है निर्मित ढांचे के साथ (मैं दूसरों के लिए पता नहीं है)

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