रेल ऐप के लिए पहला अनुरोध बहुत धीमा है

Question

हमेशा मेरे रेल ऐप पर पहला अनुरोध (एक कार्य सत्र का) लगी हुई है। उत्पादन मोड पर स्विचिंग मदद नहीं करता है।

मैं मंगोल का उपयोग करता हूं और अन्य अनुरोध स्वीकार्य गति से संभाले जाते हैं।

मैं इसे तेज़ी से कैसे बना सकता हूं?

सादर

Answer 1

यदि आप लॉग की सामग्री पोस्ट करते हैं तो पहला अनुरोध संसाधित होता है तो शायद हम यह समझ सकते हैं कि यह इतना धीमा कर रहा है। उदाहरण के लिए, यह मेरा लॉग के रूप में पहली उपयोगकर्ता साइट

Booting Mongrel (use 'script/server webrick' to force WEBrick)  
Rails 2.1.0 application starting on http://0.0.0.0:3000  
Debugger enabled  
Call with -d to detach  
Ctrl-C to shutdown server 
** Starting Mongrel listening at 0.0.0.0:3000 
** Starting Rails with development environment... 
/usr/lib/ruby/gems/1.8/gems/actionpack-2.1.0/lib/action_controller/mime_type.rb:66: warning: already initialized constant CSV 
** Rails loaded. 
** Loading any Rails specific GemPlugins 
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart). 
** Rails signals registered. HUP => reload (without restart). It might not work well. 
** Mongrel 1.1.5 available at 0.0.0.0:3000 
** Use CTRL-C to stop. 


Processing SessionsController#new (for 127.0.0.1 at 2009-05-26 12:26:00) [GET] 
    Session ID: de2acf074759026e1ed6205724f547a9 
    Parameters: {"action"=>"new", "controller"=>"sessions"} 
Rendering sessions/new 
Completed in 0.00587 (170 reqs/sec) | Rendering: 0.00298 (50%) | DB: 0.00092 (15%) | 200 OK [http://localhost/] 

मुझे लगता है कि 170 reqs/सेकंड हमारे एप्लिकेशन के लिए ठीक है, लेकिन दूसरों कि धीमी गति से मिल सकता है में पहुंचता है। आप आंकड़ों से देख सकते हैं कि रेल प्रदान करता है कि आवश्यक समय का आधा जवाब प्रतिक्रिया प्रदान करने में बिताया जाता है - इस मामले में लॉगिन स्क्रीन के लिए HTML उत्पन्न करना। अगर यह अनुरोध लंबे समय से ले रहा था, तो कॉल का मेरा पहला बंदरगाह लॉगिन स्क्रीन से जुड़े विचार और सहायक होंगे।

यदि आपके पास ऐसा सिस्टम है जो पहले ही अनुरोध पर खुद को शुरू करने में लंबा समय लेता है तो क्यों न हो और अपना खुद का स्टार्टअप प्रोग्राम लिखें जो पहले रेल चलाता है और फिर कर्ल के माध्यम से नकली अनुरोध भेजता है। इस तरह आपके उपयोगकर्ता कभी समस्या नहीं देखते हैं।

क्रिस

Answer 2

इससे हमारे अनुप्रयोगों एक लंबे समय के लिए पहली बार हम Websphere में उन्हें शुरू लेने के रूप में एक ही कारण हो सकता है।

WAS को कंटेनरों को स्थापित करने के लिए बहुत प्रारंभिक कार्य करना पड़ता है जब एप्लिकेशन का एक नया संस्करण स्थापित होता है (या WAS पुनरारंभ होता है)।

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

मुझे नहीं पता कि रुबी के साथ ऐसा करने के लिए या यहां तक ​​कि यह संभव है या नहीं। आपको उसको समझना होगा।

Answer 3

मुझे लगता है कि आप पूर्ण पाठ खोज के लिए फेरेट का उपयोग कर रहे हैं? हो सकता है कि फेरेट कनेक्शन को प्रारंभ करने में कुछ समय लगे? जब मैं आपके लॉग की जांच करता हूं तो ऐसा लगता है कि डीबी और दृश्य दोनों सामान्य समय लेते हैं लेकिन कुल अभी भी 10 सेकंड है। तो मुझे कुछ और होना चाहिए इसलिए मैं अनुमान लगा रहा हूं कि फेरेट समस्या हो सकती है।

Answer 4

यह है क्योंकि आप कर रहे हैं हो सकता है:

• की आवश्यकता होती है और प्लगइन्स और जवाहरात

• एक बाहरी सेवा करने के लिए एक कनेक्शन बनाने के एक नंबर लोड हो रहा है (तब कैशिंग)

• अपने स्वयं के पृष्ठों को कैश करना और केवल पहले अनुरोध के बाद होता है जब तक कि आप 'गर्म' कैश

इनमें से कोई भी अनिवार्य रूप से पहले अनुरोध के प्रतिक्रिया समय को बढ़ाएगा।

Answer 5

शायद आपको अपाचे conf में PassengerPoolIdleTime var समायोजित करने की आवश्यकता है। अपनी रेल प्रक्रिया को कभी भी रोकने के लिए इसे 0 पर सेट करें।