2009-07-22 10 views
7

मुझे लगता है कि इस सवाल से बहुत कुछ पूछा गया है। मुझे पता है रेल स्केल कर सकते हैं क्योंकि मैंने इस पर काम किया है और यह कमाल है। और इस बारे में कोई संदेह नहीं है कि जहां तक ​​PHP ढांचे का संबंध है।रेल बनाम रेल स्केलिंग की लागत बनाम PHP बनाम पायथन फ्रेमवर्क

मैं नहीं जानना चाहता कि कौन से ढांचे बेहतर हैं।

रेल के बनाम अन्य ढांचे (PHP, पायथन) को स्केलिंग की लागत में अंतर कितना अंतर है, जो प्रति माह 1 मिलियन विज़िट के साथ एक बड़ा ऐप मानते हैं?

यह कुछ है जो मुझे बहुत कुछ मिलता है। मैं लोगों को समझा सकता हूं कि "रेल बहुत अच्छी तरह से स्केल करता है" लेकिन लंबे समय तक, अर्थशास्त्र क्या हैं?

अगर कोई कुछ मीट्रिक प्रदान कर सकता है, तो यह बहुत अच्छा होगा।

+2

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

उत्तर

5

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

शुद्ध "विज़िट की संख्या" पैरामीटर के लिए, प्रश्न वास्तव में यह है कि आपका HTML टेम्पलेटिंग सिस्टम कितनी तेजी से काम करता है। तो सवाल यह है कि आप प्रति सेकेंड कितने पेज प्रस्तुत कर सकते हैं? मैं यह निर्धारित करने के लिए प्राथमिक मेट्रिक्स बनाउंगा कि सिस्टम कितना अच्छा होगा।

बेशक, अलग-अलग पृष्ठों की अलग-अलग लागत हो सकती है; कुछ के लिए, आप कैशिंग का उपयोग कर सकते हैं, लेकिन दूसरों के लिए नहीं। तो मापनीयता को मापने में, अपनी 1 मिलियन यात्राओं को सस्ते और महंगे पृष्ठों में विभाजित करें, और उन्हें अलग से मापें। साथ में, उन्हें आपके सिस्टम द्वारा लोड किए जाने वाले लोड का एक अच्छा अनुमान देना चाहिए (या मांग को पूरा करने के लिए आपको आवश्यक सिस्टम की संख्या)।

मेमोरी उपयोग का मुद्दा भी है। यदि आपके पास SQL ​​में डेटा है, तो इससे कोई फर्क नहीं पड़ता - लेकिन कैशिंग के साथ, आपको स्केलेबिलिटी wrt पर भी विचार करने की आवश्यकता हो सकती है। मुख्य स्मृति उपयोग।

4

आईएमएचओ मुझे नहीं लगता कि स्केलिंग की लागत उन तीनों के बीच अलग हो जाएगी क्योंकि उनमें से कोई भी "स्केलेबिलिटी बैटरी" शामिल नहीं है। मुझे उन तीन विकल्पों के बीच कोई बड़ा वास्तुशिल्प अंतर नहीं दिखता है जो स्केलिंग में महत्वपूर्ण अंतर पैदा करेंगे।

दूसरे शब्दों में, आपका एप्लिकेशन आर्किटेक्चर इस बात पर हावी होने जा रहा है कि एप्लिकेशन किस प्रकार तीन भाषाओं में से किसी पर ध्यान दिए बिना स्केल करता है।

यदि आपको मेमोरी कैशिंग की आवश्यकता है तो आप कम से कम memcached (या ऐसा कुछ जो सभी तीन भाषाओं के साथ इंटरफेस करेंगे) का उपयोग करने जा रहे हैं। हो सकता है कि आप सीधे memcache से सेवा करने के लिए nginx का उपयोग करके अपनी स्केलेबिलिटी में मदद करें, लेकिन यह स्पष्ट रूप से php/perl/python/ruby ​​के प्रदर्शन को बदलने वाला नहीं है।

यदि आप MySQL या Postgresql का उपयोग करते हैं तो आपको अभी भी अपनी ऐप भाषा के बावजूद स्केलिंग के लिए अपना डेटाबेस सही तरीके से डिज़ाइन करना होगा, और क्लस्टरिंग/मिररिंग शुरू करने के लिए आपके द्वारा उपयोग किए जाने वाले किसी भी टूल को आपके ऐप के बाहर होने वाला है।

मुझे लगता है कि मेमोरी उपयोग पायथन (mod_wsgi डिमन मोड के साथ) और रूबी (यात्री/mod_rack के साथ एंटरप्राइज़ रूबी) के मामले में लगता है कि कम से कम अच्छे पैरों के निशान एफसीजीआई के तहत PHP से तुलनात्मक हैं और शायद mod_php के तहत PHP से बेहतर (यानी अपाचे एमपीएम सभी अपाचे प्रक्रियाओं में prefork + php बहुत मेमोरी बेकार करता है)।

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

1

दुर्भाग्य से, मुझे रेल, PHP और Django की कोई भी लागत तुलना नहीं पता है। लेकिन मुझे कुछ जावा वेब फ्रेमवर्क की लागत तुलना पता है: स्प्रिंग (9 के $), विकेट (5 9 के $), जीडब्ल्यूटी (6k $) और जेएसएफ (4 9 $)।

http://www.devoxx.com/display/DV11/WWW++World+Wide+Wait++A+Performance+Comparison+of+Java+Web+Frameworks

वहाँ आप इसके बारे में एक पोस्ट किया है (कम):

आप यहाँ मूल सम्मेलन है

http://blog.websitesframeworks.com/2013/03/web-frameworks-benchmarks-192/

आप इस लागत के बारे में infere करने की कोशिश करना चाहते हैं । आप bencharmk Techempower द्वारा प्रस्तावित के साथ इस डेटा पार कर सकता:

http://www.techempower.com/benchmarks/

तो, अगर आप जानते हैं कि वसंत बहुत सस्ता है विकेट से तुलना और Django/रेल विकेट और स्प्रिंग से मानक में बदतर के निशान है, यह शायद साधन वे एक उच्च लागत का प्रतिनिधित्व करेंगे।

उम्मीद है कि यह मदद करता है।

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