क्या लारावेल वास्तव में यह धीमा है?

Question

मैंने अभी लारवेल का उपयोग शुरू किया है। मैंने अभी तक किसी भी कोड को मुश्किल से लिखा है, लेकिन मेरे पेज लोड होने में लगभग एक सेकंड ले रहे हैं!

यह मेरे लिए थोड़ा चौंकाने वाला है, जब मेरा फ्रेम-कम ऐप और NodeJS ऐप ~ 2ms लेते हैं। लारवेल क्या कर रहा है? यह सामान्य व्यवहार नहीं है? क्या इसके लिए कुछ बढ़िया ट्यूनिंग की ज़रूरत है?

Comments

दौड़ने की कोशिश करेंphp artisan optimize --force

— जोसेफ सिलबर

निष्पक्ष होने के लिए, आपके द्वारा देखे जा रहे लोड समय डिबगिंग मोड में हैं। डीबगर आप जिस एप्लिकेशन का उपयोग कर रहे हैं, वह एप्लिकेशन को काफी धीमा कर देती है।

— kajetons

आपका वातावरण कैसा दिखता है? मुझे वीएम पर स्थानीय रूप से वीएम पर विकसित होने की तुलना में तेज गति दिखाई देती है।

— kreeves

@Artsemis बस सब कुछ स्थापित किया। यह दो बार से अधिक धीमा है , और कई ताज़ा होने के बाद यह दुर्घटनाग्रस्त हो रहा है।

— एमपीएन

हाँ, वैग्रंट के उपयोग से कुछ भी तेज़ होने की उम्मीद नहीं है। एक सिम्फनी पेज आमतौर पर वैग्रंट में लोड करने के लिए 1-2s की तरह होता है, जबकि उत्पादन में 50ms लगता है।

— मैथ्यू नेपोली

Answer 1

Laravel है नहीं वास्तव में है कि धीमी गति से। 500-1000ms बेतुका है; मैंने इसे डिबग मोड में 20ms तक नीचे ला दिया।

समस्या वैग्रंट / वर्चुअलबॉक्स + साझा फ़ोल्डर थी। मुझे नहीं लगा कि उन्होंने इस तरह के प्रदर्शन को प्रभावित किया है। मुझे लगता है क्योंकि लारवेल के पास बहुत सारी निर्भरताएँ हैं (लोड ~ 280 फाइलें) और उनमें से प्रत्येक फ़ाइल को धीमा है, यह वास्तव में जल्दी जोड़ता है।

kreeves ने मुझे सही दिशा में, इस ब्लॉग पोस्ट में बताया ने Vagrant 1.5 में एक नई सुविधा का वर्णन किया है जो आपको साझा किए गए फ़ोल्डर का उपयोग करने के बजाय VM में आपकी फ़ाइलों को rsync करने देता है।

विंडोज पर कोई देशी rsync क्लाइंट नहीं है, इसलिए आपको साइबरविन का उपयोग करना होगा । इसे स्थापित करें, और नेट / rsync की जांच करना सुनिश्चित करें। C:\cygwin64\binअपने रास्तों में जोड़ें । [या आप इसे Win10 / बैश पर स्थापित कर सकते हैं]

वैग्रंट नई सुविधा का परिचय देता है । मैं पुफेट का उपयोग कर रहा हूं, इसलिए मेरा वैग्रांटफाइल थोड़ा मजाकिया लग रहा है। मुझे इसे इस तरह से देखना था:

  data['vm']['synced_folder'].each do |i, folder|
    if folder['source'] != '' && folder['target'] != '' && folder['id'] != ''
      config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", 
        id: "#{folder['id']}", 
        type: "rsync",
        rsync__auto: "true",
        rsync__exclude: ".hg/"
    end
  end

एक बार जब आप सभी सेट हो जाते हैं, तो प्रयास करें vagrant up। यदि सब कुछ सुचारू रूप से चला जाए तो आपकी मशीन को बूट होना चाहिए और इसे सभी फाइलों को कॉपी करना चाहिए। vagrant rsync-autoफ़ाइलों को अद्यतित रखने के लिए आपको एक टर्मिनल चलाने की आवश्यकता होगी । आप विलंबता में थोड़ा भुगतान करेंगे, लेकिन 30x तेज़ पृष्ठ लोड के लिए, यह इसके लायक है!

---

यदि आप PhpStorm का उपयोग कर रहे हैं, तो यह स्वतः अपलोड सुविधा rsync से भी बेहतर काम करता है। PhpStorm बहुत सारी अस्थायी फ़ाइलें बनाता है, जो फ़ाइल वॉचर्स तक जा सकती हैं, लेकिन यदि आप इसे अपलोड को स्वयं हैंडल करने देते हैं, तो यह अच्छी तरह से बंद हो जाता है।

---

एक और विकल्प lsyncd का उपयोग करना है । मुझे उबंटू मेजबान -> फ्रीबीएसडी अतिथि पर इसका उपयोग करने में बड़ी सफलता मिली है। मैंने इसे अभी तक विंडोज होस्ट पर आजमाया नहीं है।

Comments

अपने प्रदर्शन में सुधार (rsync का उपयोग करने से अलग) करने के लिए आपने क्या किया?

— jpcamara

@jpcamara कुछ नहीं। रुपेण्ट ने अकेले इसे ~ 20ms तक घटा दिया। आप इसे एचएचवीएम के तहत चला सकते हैं, किसी भी डिबगिंग को बंद कर सकते हैं और artisan optimizeथोड़े बढ़ावा के लिए चला सकते हैं । बाकी ज्यादातर यह है कि आप अपने ऐप को कैसे डिज़ाइन करते हैं मुझे लगता है। स्थापित करें barryvdh/laravel-debugbarऔर किसी भी सुस्ती के लिए देखें।

— एमपीएन

यह 20ms में 280 फ़ाइलों को कैसे लोड करता है? किसी प्रकार का संकलन / OPcache यहाँ उपयोग किया जाता है? एसएसडी भंडारण, ofc मानकर।

— मैनुअल आर्म्ड श्मिट

टेलर ओटवेल लारवेल 5.2 के अनुसार 25% भी तेज होगा: twitter.com/taylorotwell/status/674327734252892161

— Koga

डिफ़ॉल्ट के बजाय NFS फ़ाइल साझाकरण का उपयोग करें। 10 बार सब कुछ गति ... NFS: config.vm.synced_folder ":", "/ vagrant", टाइप करें: "nfs", nfs: true, nfs#udp: false, nfs_version: 3

— डिडज़िस

Answer 2

आपकी समस्या का समाधान करने के लिए मुझे यह ब्लॉग मिला, जो लार्वा उत्पादन को अनुकूलित बनाने की बात करता है। अपने ऐप को तेज़ बनाने के लिए आपको जो कुछ करने की ज़रूरत है, उसमें से अधिकांश अब आपके कोड, आपके नेटवर्क क्षमता, CDN, कैशिंग, डेटाबेस के लिए कितना कुशल है।

अब मैं इस मुद्दे के बारे में बात करूंगा:

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

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

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

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

सामान्य व्यापार बंद:

 Easy = Slow, Hard = Fast

मैं C या Java को हार्ड लर्निंग कर्व और हार्ड मेंटेनेंस पर विचार करूंगा लेकिन यह वेब फ्रेमवर्क में बहुत ऊपर है।

हालांकि बहुत संबंधित नहीं है। मैं सिर्फ इस बात को साबित करने की कोशिश कर रहा हूं easy = slow:

रूबी को बनाए रखने में बहुत अच्छी प्रतिष्ठा है और इसे सीखने में सुगमता है लेकिन इसे अजगर और php के बीच सबसे धीमा माना जाता है जैसा कि यहाँ दिखाया गया है ।

Comments

उन ग्राफिक्स का सवाल क्या है?

— NullPoiиteя

PHP7, PHP5

— Cobolt

क्या बात है? आसान = धीमी गति से आगे विशेष भाषाओं के प्रति निराधार गलतफहमी फैलती है

— क्रिस

इन्फोग्राफिक्स में एक त्रुटि यह है कि अजगर जावा से प्रभावित नहीं हो सकता क्योंकि जावा का आविष्कार 1995 में और 1991 में अजगर ने किया था।

— हरितसिंह गोहिल

@HaritsinhGohil Python 3 को 2008 को रिलीज़ किया गया था।

— माजिदरीफ

Answer 3

हाँ - लारवेल वास्तव में धीमा है। मैंने इस खातिर एक POC ऐप बनाया। सरल राउटर, एक लॉगिन फॉर्म के साथ। मैं केवल $ 20 डिजिटल महासागर सर्वर (कुछ जीबी रैम) पर 10 समवर्ती कनेक्शन के साथ 60 आरपीएस प्राप्त कर सकता था ;

सेट अप:

2gb RAM
Php7.0
apache2.4
mysql 5.7
memcached server (for laravel session)

मैं ऑप्टिमाइज़ेशन, कम्पोज़र डंप ऑटोलैड आदि चला गया, और यह वास्तव में आरपीएस को 43-ईश तक कम कर दिया ।

समस्या यह है कि ऐप 200-400ms में प्रतिक्रिया करता है। मैंने स्थानीय मशीन से एबी परीक्षण चलाया, लार्वा चालू था (यानी, वेब ट्रैफ़िक के माध्यम से नहीं); और मुझे केवल 112 आरपीएस मिला; 300ms की औसत के साथ 200ms तेजी से प्रतिक्रिया समय।

तुलनात्मक रूप से, मैंने AWS t2.medium (x3, लोड संतुलित) पर एक दिन में कुछ मिलियन अनुरोधों को चलाने वाले अपने उत्पादन PHP मूल एप्लिकेशन का परीक्षण किया। जब मैं अपने स्थानीय मशीन से 25 से अधिक समवर्ती कनेक्शनों को वेब पर ELB के माध्यम से भेजूँगा, तो मुझे लगभग 1200 RPS मिले। लोड बनाम लार्वा "लॉगिन" पृष्ठ के साथ एक मशीन पर भारी अंतर।

ये सेशंस (प्रत्यास्थ / मेमकाटेड), लाइव डीबी लुकअप (मेमेकैक्ड के माध्यम से कैश्ड क्वेश्चन), एसेट्स ऑन सीडीएन, वगैरह, वगैरह, साथ पेज हैं।

मैं क्या बता सकता हूं, लार्वा लगभग 200-300 सेंटीमीटर भार से चिपक जाता है। PHP उत्पन्न विचारों के लिए इसका जुर्माना, आखिरकार, उस प्रकार का विलंब लोड पर सहनीय है। हालांकि, छोटे अपडेट को संभालने के लिए अजाक्स / जेएस का उपयोग करने वाले PHP के विचारों के लिए, यह सुस्त लगने लगता है।

मैं कल्पना नहीं कर सकता कि यह प्रणाली एक बहु किरायेदार ऐप के साथ कैसी दिखती है जबकि 200 बॉट्स एक ही समय में 100 पृष्ठों को क्रॉल करते हैं।

सरल एप्स के लिए लारवेल बढ़िया है। लुमेन सहनीय है यदि आपको कुछ भी ऐसा करने की आवश्यकता नहीं है, जिसमें मिडलवेयर बकवास (IE, कोई मल्टी टेनेंट ऐप और कस्टम डोमेन आदि) की आवश्यकता नहीं होगी;

हालांकि, मुझे कभी भी किसी ऐसी चीज से शुरुआत करना पसंद नहीं है जो "हेल्लो वर्ल्ड" पोस्ट के लिए 300ms लोड और बांध सकती है।

यदि आप सोच रहे हैं "कौन परवाह करता है?"

.. कुछ सौ हज़ार परिणामों में स्वतः पूर्ण सुझावों का जवाब देने के लिए त्वरित प्रश्नों पर निर्भर रहने वाली एक पूर्वानुमानात्मक खोज लिखें। यह 200-300ms अंतराल आपके उपयोगकर्ताओं को पूरी तरह से पागल कर देगा।

Comments

मिडलवेयर बकवास क्यों है? तथ्यों की व्याख्या करने में सावधानी बरतें ताकि हम सभी यह कह सकें कि यह बकवास है? इसके अलावा, मैं एक लारवेल इंस्टॉलेशन चलाता हूं जो खुशी से 80 और 65 एमएस के बीच प्रतिक्रिया करता है (हां, यह 4 बिलियन रिकॉर्ड टेबल पर एक डीबी क्वेरी करता है) इसलिए मैं यह देखने के लिए उत्सुक हूं कि आप किस बारे में हैं।

— म्झ

आप स्पष्ट रूप से लार्वा से प्यार करते हैं। मैंने खराब परिणामों के आधार स्थापित, अनुकूलित और अनुकूलित किया है। मैंने पाया कि पूर्व मार्ग प्रसंस्करण को संभालने के लिए मिडलवेयर और रिवर्स इंजीनियरिंग की आवश्यकता है; जो आदर्श नहीं था। सिर्फ इसलिए कि आपको अनुकूलन करने के लिए "आपका" लार्वा स्थापित हो गया, बढ़िया। यह अप्रासंगिक है। HELLO WORLD का एक बेस पैकेज रूटिंग एक साधारण रूटिंग फ्रेमवर्क और ट्विग टेंपलेटिंग इंजन की तुलना में भारी और धीमा था। क्या दोनों को कैश किया जा सकता है? अनुकूलित किया गया? सुधार हुआ? हाँ। क्या यह बात है? नहीं, लारवेल भारी है। भारी (धीमी) है। दुनिया उस पर सहमत है। यदि आप इसे पसंद करते हैं, तो इसका उपयोग करें, लेकिन यह धर्मशास्त्र नहीं है। :)

— निक

मुझे कम समय बिताना पसंद है। मैं वास्तव में एक ढांचे / प्रौद्योगिकी / जो भी हो, के बारे में परवाह नहीं करता, मुझे लगता है कि आप वही हैं। किसी लक्ष्य को प्राप्त करने में कम समय लगाना = यह मेरी पुस्तक में एक जीत है। अब, हाँ, लारवेल भारी है। नंगे हड्डियों वाली भाषा की तुलना में हर रूपरेखा भारी है। किसी भी कार्यक्रम / सॉफ्टवेयर के रूप में - लारवेल तेजी से दौड़ सकता है , जो कि मेरी टिप्पणी का बिंदु है। यदि कोई ढांचा आपकी मदद करता है, अगर आपको इसे तेज चलाने की आवश्यकता है - यह प्राप्त करने योग्य है।

— Mjh

आप $ 20 DO सर्वर पर चल रहे लारावेल के एक गैर-कॉन्फ़िगर / अनुकूलित / कैश्ड इंस्टेंस की तुलना एक कस्टम बिल्ड, उच्च ट्यून / अनुकूलित / कैश्ड php ऐप पर कर रहे हैं, $ 400 उच्च ट्यून / अनुकूलित / कैश्ड सर्वर इन्फ्रास्ट्रक्चर पर चल रहे हैं, फिर शिकायत कर रहे हैं अन-ऑप्टिमाइज़्ड ऐप धीमा है? मुझे गलत मत समझो, सभी ढांचे बॉक्स से बाहर हैं! सभी के लिए काम करने के लिए एक रूपरेखा तैयार करने का कोई तरीका नहीं है। इसके अलावा, अधिकांश ढांचे एक देव पर्यावरण FIRST के लिए सेटअप हैं। धीमी ऑटोलोडिंग, नॉन कैश्ड टेम्प्लेट आदि। कृपया सेब की तुलना सेब से करें, फेरारी से सेब की नहीं, या इस मामले में, एक

— ज़ोंडा

CodeIgniter बॉक्स से धीमा नहीं है। वास्तव में, CodeIgniter लगभग PHP के समान ही तेज़ है। PHP = 300 rps, CodeIgniter = 295. लारवेल उससे नीचे का रास्ता है। Zend लगभग 30 आरपीएस है, और केक, जो मुझे याद है, उससे एक तेज 3 आरपीएस। कोई भी दो ढांचे समान नहीं बनाए गए हैं। देखने के लिए कुछ सेब हैं। हालांकि, लारावेल का अनुकूलन आपको 60 एमएस भार दे सकता है, कल्पना करें कि कोडाइग्निटर आपको किस अनुकूलन के लिए मिलेगा। ;)

— वेबमास्टर जी

Answer 4

मैंने पाया कि लारवेल 4 के साथ सबसे बड़ी गति हासिल करने से आप सही सत्र ड्राइवर चुन सकते हैं;

Sessions "driver" file;

Requests per second:    188.07 [#/sec] (mean)
Time per request:       26.586 [ms] (mean)
Time per request:       5.317 [ms] (mean, across all concurrent requests)


Session "driver" database;

Requests per second:    41.12 [#/sec] (mean)
Time per request:       121.604 [ms] (mean)
Time per request:       24.321 [ms] (mean, across all concurrent requests)

उम्मीद है की वो मदद करदे

Comments

जाहिर है और मैं किसी को भी सत्र के रूप में फ़ाइल का उपयोग न करने की सलाह दूंगा। स्केलेबिलिटी के बारे में सोचें :)

— jeveloper

@ जुल्फिकार क्या? इस उदाहरण में, फ़ाइल डेटाबेस की तुलना में 4 गुना अधिक तेज है

— डेवलपर

@ ब्रेट "स्केलेबिलिटी के बारे में सोचें" बिंदु था, निश्चित रूप से दूरस्थ नेटवर्क के लिए निश्चित रूप से फ़ाइल बनाम नेटवर्क कॉल (भले ही एक ही VPC के भीतर) धीमी हो लेकिन कम से कम इसके टिकाऊ और आप सत्र डेटा पर कब्जा कर

— लेंगे

@ जेवलर फाइलर टिकाऊ नहीं है? मुझे यकीन है कि उम्मीद है कि यह है, क्योंकि वैसे भी अधिकांश डेटाबेस के लिए अंतर्निहित भंडारण है।

— डेवलपर

@developerbmw वह जो कहने की कोशिश कर रहा है, यदि आपके पास लोडबेलर और मुलिप्ट इंस्टेंसेस हैं जो आपके एप्लिकेशन की सेवा कर रहे हैं, तो स्थानीय सर्वर की फाइल सिस्टम का उपयोग करना स्केलेबल नहीं है।

— क्रिस हैरिसन

Answer 5

मेरे हैलो वर्ल्ड कॉन्टेस्ट से, लारावेल कौन सा है? मुझे लगता है कि आप अनुमान लगा सकते हैं। मैंने परीक्षण के लिए डॉकटर कंटेनर का उपयोग किया और यहां परिणाम हैं

Http-response को “Hello World” बनाने के लिए:

• लॉग हैंडलर स्टडआउट के साथ गोलंग: 6000 आरपीएस
• लॉग हैंडलर स्टडआउट के साथ स्प्रिंगबूट: 3600 आरपीएस
• लॉग ऑफ के साथ लारवेल 5: 230 आरपीएस

Comments

पता नहीं क्यों यह खुद को चिह्नित किया गया है, हाँ शायद एक टिप्पणी के रूप में अधिक उपयुक्त है। हालाँकि मैं भी एक डॉकटर कंटेनर के भीतर अत्यंत धीमी प्रतिक्रिया समय का अनुभव करता हूं ~ 600ms

— एंड्रयूमैक्गन

क्या आपने रूट कैशिंग की कोशिश की?

— ओयूज़ कैन सर्टेल

आरपीएस क्या है? प्रति सेकंड अनुरोध?

— user3494047

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

— Mjh

मैं सिर्फ प्रदर्शन आधारभूत w / o अन्य जटिल निर्भरता चाहता हूँ

— Aggarat .J

Answer 6

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

इसके अलावा, मुझे काम पर अपनी मशीन पर थोड़ी अधिक संख्याएं मिलती हैं, जो घर पर मेरी मशीन की तुलना में पृष्ठ को अधिक तेजी से निष्पादित करता है।

मुझे नहीं पता कि उन नंबरों की गणना कैसे की जा रही है, लेकिन वे अवलोकन, या फायरबग जैसे ब्राउज़र टूल द्वारा पुष्टि नहीं की जाती हैं ...

लारवेल वास्तव में वह सब धीमा नहीं है, खासकर जब अनुकूलित। हालांकि यह स्मृति-भूख है। यहां तक ​​कि द्रुपल जैसा एक भारी सीएमएस जो बहुत धीमा है, एक नंगे हड्डियों लिवरेल अनुरोध के बारे में 1 / 3rd स्मृति पदचिह्न लगता है।

इस प्रकार उत्पादन में लारवेल को चलाने के लिए, मैं सीपीयू-अनुकूलित सर्वरों से पहले मेमोरी-अनुकूलित सर्वरों को तैनात करूंगा।

Comments

मुझे यकीन नहीं है कि अगर वे नंबर ऑन हैं, लेकिन यह निश्चित रूप से ध्यान देने योग्य है। "विशेष रूप से अनुकूलित" होने से आपका क्या मतलब है? आप इसे कैसे अनुकूलित कर रहे हैं? बस चलाने से php artisan optimizeया और भी बहुत कुछ है जो हम कर सकते हैं?

— एमपीएन

कुछ चीजें जो आप कर सकते हैं, इन दो लिंक में उल्लिखित हैं: crynobone.com/posts/7/crunching-laravel-4-for-production-server | lutro.priv.no/posts/optimizing-for-production-with-laravel-4

— AgmLauncher

Answer 7

मुझे पता है कि यह थोड़ा पुराना सवाल है, लेकिन चीजें बदल गईं। लारवेल इतना धीमा नहीं है। यह बताया गया है, सिंक किए गए फ़ोल्डर धीमे हैं। हालाँकि, विंडोज 10 पर मैं उपयोग करने में सक्षम नहीं था rsync। मैंने दोनों की कोशिश की cygwinऔर minGW। ऐसा लगता है जैसे के संस्करण के rsyncसाथ असंगत git for windowsहै ssh।

यहाँ मेरे लिए क्या काम किया गया है: एनएफएस ।

वैग्रांत डॉक्स कहते हैं:

NFS फ़ोल्डर्स विंडोज होस्ट पर काम नहीं करते हैं। Vagrant Windows पर NFS सिंक किए गए फ़ोल्डर के लिए आपके अनुरोध को अनदेखा करेगा।

यह अब सच नहीं है। हम आजकल vagrant-winnfsd प्लगइन का उपयोग कर सकते हैं। यह वास्तव में स्थापित करने के लिए सरल है:

1. निष्पादित vagrant plugin install vagrant-winnfsd
2. अपने में बदलें Vagrantfile:config.vm.synced_folder ".", "/vagrant", type: "nfs"
3. इसमें जोड़ें Vagrantfile:config.vm.network "private_network", type: "dhcp"

NFSकाम करने के लिए बस इतना ही चाहिए । मेरे लिए लारवल प्रतिक्रिया समय 500ms से घटकर 100ms हो गया।

Comments

क्या आपने विंडोज के लिए बैश के माध्यम से rsync की कोशिश की? मैं इसे अभी वास्तव में चला रहा हूं, और यह बहुत अच्छा काम कर रहा है।

— एमपीएन

नहीं, मैंने इसकी कोशिश नहीं की। मुझे पता है, बहुत से लोग लिखते हैं कि rsync git bash या windows cmd के साथ भी बढ़िया काम करता है। मुझे नहीं पता कि यह मेरे लिए काम क्यों नहीं कर रहा है। लेकिन मुझे वैसे भी एक और उपाय मिला। शायद यह किसी के लिए उपयोगी होगा।

— बिरादरी

Answer 8

मुझे 1.40sविकास क्षेत्र में शुद्ध लार्वा के साथ काम करते समय सामना करना पड़ा !

समस्या का उपयोग कर रहा था: php artisan serveवेबसर्वर को चलाने के लिए

जब मैंने उसी कोड के बजाय अपाचे वेबसर्वर (या NGINX) का उपयोग किया था तो मैंने इसे नीचे कर दिया 153ms

Answer 9

चूंकि किसी और ने इसका उल्लेख नहीं किया है, इसलिए मैंने पाया कि एक्सडेबग डिबगर ने नाटकीय रूप से समय बढ़ाया। मैंने एक मूल "हैलो वर्ल्ड की सेवा की, समय है 2020-01-01T01: 01: 01.010101" डायनेमिक पेज और अनुरोध के समय में अपने httpd.conf में इसका इस्तेमाल किया:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" **%T/%D**" combined

% T सेकंड में सर्व करने का समय है,% D माइक्रोसेकंड में समय है। इसके साथ मेरी php.ini में:

[XDebug]
xdebug.remote_autostart = 1
xdebug.remote_enable = 1

मुझे लगभग 770ms प्रतिक्रिया समय मिल रहा था, लेकिन दोनों को 0 पर सेट करने के साथ उन्हें निष्क्रिय करने के लिए, यह तुरंत 160ms तक कूद गया। इन दोनों को चलाने से यह 120 सेमी नीचे आ गया:

php artisan route:cache
php artisan config:cache

नकारात्मक पक्ष यह है कि अगर मैंने कॉन्फिगर या रूट परिवर्तन किए हैं, तो मुझे उन्हें फिर से कैश करना होगा, जो कि कष्टप्रद है।

एक सिडनोट के रूप में, अजीब तरह से, मेरे SSD से कताई HDD तक साइट को स्थानांतरित करने से कोई प्रदर्शन लाभ नहीं मिला, जो मेरे लिए बहुत ही अजीब है, लेकिन मुझे लगता है कि यह शायद कैश्ड है, मैं XAMPP के साथ विंडोज 10 पर हूं।

Answer 10

Laravel धीमा है, क्योंकि ज्यादातर मामलों में, वेब पेजों के लिए PHP का उपयोग धीमा है।

लारवेल के साथ, पूरे ढांचे को हर आह्वान पर फिर से बनाया गया है - यही कारण है कि सभी पृष्ठ index.php को इंगित करते हैं। चूंकि पूरी रूपरेखा PHP स्क्रिप्ट्स है, इसलिए उन्हें हर बार PHP दुभाषिया से गुजरना पड़ता है। जितना बड़ा ढांचा होगा, उतना ही लंबा समय लगेगा।

एक "सर्वर वातावरण" (जैसे टोमैट) के साथ इसका विरोध करें जहां सर्वर एक बार आरंभीकरण कोड चलाता है, और अंततः सभी पृष्ठ मूल कोड (जेआईटी के बाद) में होंगे।

एक संदर्भ उदाहरण के रूप में, एक ही हार्डवेयर, ओएस, आदि का उपयोग करते हुए इस हार्डवेयर पर JSP का उपयोग करते हुए एक सरल 'हैलो वर्ल्ड' 3000 आरपीएस है, लार्वा पर एक ही हैलो दुनिया 51 आरपीएस है।

फ्रेमवर्क ओवरहेड का परीक्षण करने का सबसे आसान तरीका, और परिणामी अधिकतम आरपीएस प्रति कोर, अपाचे एबी और 1 के समवर्ती मान का उपयोग करना है, एक सरल 'हैलो वर्ल्ड' के साथ जो गतिशील है (स्थैतिक पेज कैशिंग से बचने के लिए)।