2010-04-10 1 views
5

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

तो वहाँ इस वेब आवेदन के दो घटक हैं:

  1. सामने के छोर यूआई कि साइट के मालिक उनके विजेट
  2. वापस अंत घटक है कि विजेट की वेब API कॉल का जवाब कॉन्फ़िगर करने के लिए उपयोग करता

पहले हमारे पास यह सब PHP में चल रहा था। अब हम रेल के साथ प्रयोग कर रहे हैं, जो # 1 (फ्रंट एंड यूआई) के लिए शानदार है। सवाल यह है कि # 2 को कैसे करना है, विजेट की जानकारी की पिछली सेवा कुशलतापूर्वक। जाहिर है, यह फ्रंट एंड की तुलना में बहुत अधिक भार है, क्योंकि प्रत्येक बार जब हमारे पृष्ठ की वेबसाइटों में से एक पर फ्रंट पेज लोड होता है तो इसे कहा जाता है।

मैं दो स्पष्ट दृष्टिकोण देख सकते हैं:

समानांतर ढेर: एक समानांतर ढेर मोर्चे के रूप में रेल के अलावा कुछ (जैसे हमारे पुराने पीएचपी आधारित दृष्टिकोण) का उपयोग करता है, लेकिन एक ही डेटाबेस तक पहुँचता सेट करें अंत

बी रेल धातु: उपयोग रेल धातु/रैक रेल बाईपास मार्ग तंत्र है, लेकिन रेल अनुप्रयोग के भीतर API कॉल प्रत्युत्तर रखने के लिए

मेरा मुख्य सवाल:

  1. क्या रेल इस तरह के कुछ के लिए उचित दृष्टिकोण है?

लेकिन भी ...

  1. विल लोड हो रहा है रेल वातावरण अभी भी बहुत भारी हो की भूमि के ऊपर?
  2. क्या अधिकांश पर्यावरण को छोड़कर रेल के साथ धातु के करीब पहुंचने का कोई तरीका है?
  3. क्या रेल/धातु प्रदर्शन सीधे PHP पर समान कार्य के पेर्फ तक पहुंच जाएगा (बस यहां बॉलपार्क की तलाश में है)?

और ...

  1. वहाँ एक 'सी' विकल्प है कि दोनों ए और बी की तुलना में काफी बेहतर होगा है? यही है, बाइनरी में संकलित सी कोड की लंबाई तक जाने से पहले और nginx या apache मॉड्यूल के रूप में स्थापित किया गया है?

किसी भी अंतर्दृष्टि के लिए अग्रिम धन्यवाद।

उत्तर

1

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

अंगूठे का मेरा नियम: यदि आप मैट्रिक्स की जरूरत नहीं है, आप अपने प्रदर्शन मुद्दा है और किसी भी संभव समाधान के बारे में समझदारी से कारण नहीं कर सकते।

मेरे अनुभव में मुद्दे लगभग हमेशा हैं: विचार और डेटाबेस।

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

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

+0

टोबी, बहुत बहुत धन्यवाद - यहां बहुत सारी जानकारी है। अनुकूलन बिंदु से पहले उपाय के साथ पूर्ण समझौता। इस सवाल के साथ मैं वास्तव में यह पता लगाने की कोशिश कर रहा था कि क्या पूरा रेल दृष्टिकोण उस मार्ग को शुरू करने से पहले एक उचित था, और आपके द्वारा की गई जानकारी, न्याय और रयान एक सुंदर ठोस हां बनाने लगते हैं। मैं हालांकि रेल प्रदर्शन के आसपास कुछ धारणाओं के दोषी था - पिछले 18-24 महीनों में यह एक लंबा सफर तय हुआ है क्योंकि मैंने आखिरी बार किसी भी विवरण में मूल्यांकन किया था। – Greg

3

नहीं वास्तव में सबसे विस्तृत जवाब लेकिन:

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

class PostsController < ApplicationController 
    caches_page :index 

    def index 
    @posts = Post.all 
    respond_to do |format| 
     format.html 
     format.xml 
    end 
    end 

    def create 
    @post = Post.new(params[:post]) 
    respond_to do |format| 
     if @post.save 
     expire_page :action => :index 
     format.html { redirect_to posts_path } 
     format.xml 
     else 
     format.html { render :action => "new" } 
     end 
    end 
    end 
end 

अधिक जानकारी के लिए the Caching Guide पढ़ें।

+0

धन्यवाद रयान। बस स्पष्ट करने के लिए, क्या आप सुझाव दे रहे हैं कि मैं वेब एपीआई के परिणामों को कैश करने के लिए कैशिंग तंत्र का उपयोग करता हूं? यदि ऐसा है, तो मुझे लगता है कि इसका लाभ उन डिग्री पर निर्भर करेगा, जिनके परिणाम समय के साथ बदल रहे हैं। या क्या मैं तुम्हारा मुद्दा याद कर रहा हूँ? – Greg

+0

@ ग्रेग: हाँ, मैं आपको एपीआई परिणामों को कैश करने का सुझाव दे रहा हूं। परिणाम बदल रहे हैं * प्रति अनुरोध * तो यह बहुत कैशिंग कर उपयोग नहीं है, लेकिन भले ही वे हर 3 अनुरोध बदल रहे हैं यह 2 अनुरोध सेवा की रेल ढेर मार नहीं कर रहे हैं कि, और यहां तक ​​कि अच्छा है होने जा रहा है कैशिंग का उपयोग करने के लिए पर्याप्त है। –

2

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

+1

धन्यवाद न्याय - यह बहुत दिलचस्प है। बस यह सुनिश्चित करने के लिए कि मैं सही निहितार्थ खींच रहा हूं: चूंकि रेल एक बार पर्यावरण को लोड करते हैं और धातु रेलों के ढेर से गुजरता है, रेल/धातु शुद्ध PHP के आधार पर एक दृष्टिकोण से भी तेज हो सकता है? – Greg

+0

यह सही है। – yfeldblum

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

  • कोई संबंधित समस्या नहीं^_^