क्या प्रोग्रामिंग भाषा की गति वेब अनुप्रयोगों के लिए मायने रखती है?

Question

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

नोट: मुझे एहसास है कि कुछ किनारे के मामलों में, जैसे कुछ गणितीय/वैज्ञानिक वेब अनुप्रयोग, प्रदर्शन बहुत मायने रखता है, लेकिन मैं उन लोगों के बारे में बात नहीं कर रहा हूं; मैं आपके औसत सोशल नेटवर्क, स्टैक ओवरफ्लो इत्यादि के बारे में बात कर रहा हूं।

Answer 1

प्रदर्शन का मामला क्या है? आखिरकार, यकीन है।

लेकिन आपकी वेबसाइट इतनी बड़ी होनी चाहिए कि आप प्रति माह लाखों हिट में हों, इससे पहले कि आप पारंपरिक ऑप्टिमाइज़ेशन (जैसे आपके डेटाबेस में उचित अनुक्रमण) के बाहर भी एक मुद्दा होगा।

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

Answer 2

मुझे नहीं लगता कि आपका प्रश्न बहुत अच्छी तरह से सोचा गया है।

सबसे पहले आप जोर देते हैं कि अधिकांश वेब ऐप्स को चीजों के अनुप्रयोग-पक्ष पर शानदार प्रदर्शन की आवश्यकता नहीं होती है, जो शायद उनमें से बहुत से के लिए सच है। फिर आप वेब अनुप्रयोगों के कुछ उदाहरण देते हैं जो को अच्छे प्रदर्शन की आवश्यकता होती है, और उन्हें दूर कहती है कि लोग उन्हें सी ++ या जावा में लिखते हैं!

अच्छा, आपको नहीं लगता कि वे रूबी या पायथन में उन्हें लिखना पसंद कर सकते हैं? शायद यही कारण है कि रूबी और पायथन के प्रदर्शन को मापने में लोग रुचि रखते हैं!

EDIT: ठीक है, तो आप बहुत से रन-ऑफ-मिल-मिल वेब ऐप्स में रुचि रखते हैं।

• प्रदर्शन वास्तव में है, जिसके कारण वे रूबी और पायथन और PHP के प्रदर्शन के बारे में चिंतित हैं, महत्वपूर्ण है: तो फिर तुम और मैं दोनों दो संभावनाएं देखते हैं कि देख सकते हैं।

• प्रदर्शन महत्वपूर्ण नहीं है, इसलिए वे गलत हैं, और वे या तो उस तथ्य से अनजान हैं या बहाना कर रहे हैं।

Answer 3

प्रदर्शन वेब अनुप्रयोगों के लिए महत्वपूर्ण है?

हाँ! डेस्कटॉप अनुप्रयोगों के मुकाबले कहीं भी ज्यादा!

डेस्कटॉप एप्लिकेशन के साथ, यदि आपको इसकी आवश्यकता है तो आप अपने उपयोगकर्ताओं के कंप्यूटर के लिए उपलब्ध लगभग सभी संसाधनों का उपयोग कर सकते हैं।एक वेब ऐप के साथ, एक कंप्यूटर को एक साथ उपयोगकर्ता के लॉट के लिए अपने ऐप को चलाने में संभावित रूप से संभालना पड़ता है। यदि आप इसे आसानी से करने के लिए नहीं प्राप्त कर सकते हैं, तो आप वास्तविक परेशानी में हैं।

Answer 4

संदर्भ के आधार पर यह बहुत मायने रख सकता है। अधिकांश वेबसाइटें साझा होस्टिंग सर्वर पर चलती हैं जहां वह सामान जोड़ता है। उसी बॉक्स पर चल रहे कुछ सौ वेब अनुप्रयोगों के साथ आप सीपीयू और मेमोरी बाधाओं के लिए जा रहे हैं।

Answer 5

यह आपके प्रश्न का ध्यान नहीं होना चाहिए। इसके बजाय आपको इस बात पर ध्यान देना चाहिए कि अंतिम उपयोगकर्ता को सामग्री को सबसे कुशल माध्यमों में कैसे पहुंचाया जा सकता है। यदि कोई वेब एप्लिकेशन अच्छी तरह लिखा गया है तो मुझे लगता है कि कोई भी प्रमुख सर्वर-साइड भाषा एक अच्छी पसंद है।

Answer 6

आपको कोने में डरते हुए क्या करना चाहिए यह है कि amazon.com और google.com द्वारा किए गए कई अध्ययनों से पता चला है कि < पृष्ठ लोड समय में 1 सेकंड की कमी के कारण उनके रूपांतरण दर पर महत्वपूर्ण (उनके लिए) प्रभाव पड़ा और इसलिए लाभ।

इसलिए प्रदर्शन छोटी साइटों के लिए भी बहुत मायने रखता है। सवाल यह है कि इससे कोई फर्क नहीं पड़ता। खोना 1% बिक्री वास्तव में कोई फर्क नहीं पड़ता जब आप दिन में 100 यूनिक्स करते हैं, लेकिन जब आप 10 मिलियन कर रहे हैं तो अचानक अचानक 1% आपको बहुत पैसा खर्च करता है।

प्रतिक्रिया समय में भी छोटे बदलाव महत्वपूर्ण प्रभाव हो सकते हैं। Google ने पाया कि 10 सेकंड के से 0 सेकंड में लोड हो रहा है 30-परिणाम पृष्ठ 0.9 सेकंड में लोड हो रहा है 20% (लिंडन 2006) द्वारा यातायात और विज्ञापन राजस्व में कमी आई है। जब Google मानचित्र का होम पेज 100KB से 70-80KB तक घटा दिया गया था, तो पहले सप्ताह में में ट्रैफ़िक 10% और में अतिरिक्त 25% (फरबर 2006) में अतिरिक्त 25% तक चला गया। अमेज़ॅन में टेस्ट इसी तरह के परिणाम सामने आए: Amazon.com के लोड समय में प्रत्येक 100 एमएस में की बिक्री 1% (कोहावी और लॉन्गबोथम 2007) की बिक्री में कमी आई। पर लाइव खोज माइक्रोसॉफ्ट पर प्रयोगों से पता चला है कि जब खोज परिणाम पृष्ठों 1 सेकंड से धीमा गया:

* Queries per user declined by 2.5%, and 
* Ad clicks per user declined by 4.4% 

: 2 सेकंड द्वारा (Kohavi 2007)

* Queries per user declined by 1.0%, and 
* Ad clicks per user declined by 1.5% 

खोज परिणाम पृष्ठ धीमा करने के बाद http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/

Answer 7

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

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

लेकिन मैंने बहुत अधिक पेज कोड देखा है जो करने की कोशिश करता है डाटाबेस को विपरीत और स्केलेबिलिटी पर समान रूप से हानिकारक परिणामों के साथ, विपरीत (उदाहरण के लिए कर्सर) की तुलना में (जैसे सरणी के साथ) करने के लिए डिज़ाइन किया गया है।और डेटाबेस क्वेरी को अनुकूलित करना मेरे प्रयोगकर्ता में PHP कोड को ठीक करने से कम काम है।

मुझे लगता है कि अधिकांश गति समस्याएं भाषा (या डीबीएमएस स्वयं) नहीं बल्कि डिजाइन और कोड की गुणवत्ता हैं। तो मुझे लगता है कि अच्छे डेवलपर्स इस बात से अधिक चिंतित होंगे कि कोई भाषा अच्छी डिजाइन और अच्छी कोड की सुविधा प्रदान करती है या नहीं, यह कितनी तेज़ी से चलती है।

Answer 8

यहां कुछ अलग-अलग तर्क हैं: क्योंकि कोड आपके सर्वर पर चल रहा है, और यदि आपका कोड अक्षम है, तो यह ओवरलोड और सभी के लिए अनुभव को कम करने जा रहा है।

सिक्का का दूसरा पक्ष you need to be successful for it to matter है, क्योंकि टेड डज़ीबा ने इतनी जोरदार और गंभीरता से कहा। "धीमी" भाषाएं संकलित भाषाओं की तुलना में अधिक विकसित और अधिक अभिव्यक्तिपूर्ण होती हैं, इसलिए वे एक टीम को साइट प्राप्त करने और अधिक तेज़ी से चलने की अनुमति देते हैं।

Answer 9

मेरे अनुभव में, एक बार जब आप वास्तव में व्यस्त हो जाते हैं तो यह डेटाबेस पर है जहां आप सबसे अधिक अंतर कर सकते हैं।

लेकिन मैं एक और विचार भी जोड़ूंगा, और इस प्रकार छवियों, जेएस और HTTP अनुरोधों के संदर्भ में आपका पृष्ठ आकार 'बड़ा' है। आपके पास बहुत धीमी साइट हो सकती है क्योंकि आपके तेज तेज डेटाबेस और ऐप कोड ने ब्लूटेड जेएस और छवियों के साथ एक वेब पेज का राक्षस बनाया है। :)

Answer 10

jfar आपको सही रास्ते से शुरू करता है। जहां तक ​​आपकी भाषा इस पर प्रभावशाली है, प्रोफाइलिंग से पता चलता है कि आपकी भाषा आपकी बोतल की गर्दन नहीं है।

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

किसी और के पास कुछ सामान्य वेब ट्यूनिंग संकेत या अन्य SO प्रश्नों के लिंक हैं?

Is there a good book on web application performance tuning?

Answer 11

आप सही हैं। ज्यादातर समय बाधा आपके सर्वर-साइड भाषा से स्वतंत्र होगी। बेशक सभी आंकड़ों का 9 0% मक्खी पर बना है, लेकिन मैं कहूंगा कि 10 में से 9 गुना बैंडविड्थ/ट्रांसफर स्पीड या डेटाबेस ऑपरेशंस में होगा।

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

अक्सर कई बार वेबसाइट की गति में सबसे बड़ा सुधार gzip संपीड़न और कैशिंग/सामग्री समाप्ति के सावधानीपूर्वक उपयोग से आ सकता है। और उन दोनों चीजों को अपाचे या आईआईएस में कॉन्फ़िगर किया जा सकता है। मैंने यहां उस विषय के बारे में लिखा: http://swortham.blogspot.com/2007/10/three-ways-to-improve-your-websites.html