2016-01-28 6 views
12

हमारे पास एक मोबाइल ऐप है जो उपयोगकर्ताओं को फ़ीड प्रस्तुत करता है। फ़ीड आरईएसटी एपीआई को टोमकैट पर लागू किया गया है, जो समानांतर सामग्री प्रस्तुत करने के लिए कोचबेस, MYSQL जैसे विभिन्न डेटा स्रोतों को कॉल करता है। सरल कोड नीचे दिया गया है:फ़ीड खींचने के लिए टोमकैट को अनुकूलित करने के लिए कैसे करें

Future<List<CardDTO>> pnrFuture = null; 
Future<List<CardDTO>> newsFuture = null; 

ExecutionContext ec = ExecutionContexts.fromExecutorService(executor); 

final List<CardDTO> combinedDTOs = new ArrayList<CardDTO>(); 

// Array list of futures 
List<Future<List<CardDTO>>> futures = new ArrayList<Future<List<CardDTO>>>(); 

futures.add(future(new PNRFuture(pnrService, userId), ec)); 
futures.add(future(new NewsFuture(newsService, userId), ec)); 
futures.add(future(new SettingsFuture(userPreferenceManager, userId), ec)); 

Future<Iterable<List<CardDTO>>> futuresSequence = sequence(futures, ec); 

// combine the cards 
Future<List<CardDTO>> futureSum = futuresSequence.map( 
     new Mapper<Iterable<List<CardDTO>>, List<CardDTO>>() { 
      @Override 
      public List<CardDTO> apply(Iterable<List<CardDTO>> allDTOs) { 
       for (List<CardDTO> cardDTOs : allDTOs) { 
        if (cardDTOs != null) { 
         combinedDTOs.addAll(cardDTOs); 
        } 
       } 

       Collections.sort(combinedDTOs); 
       return combinedDTOs; 
      } 
     } 
); 

Await.result(futureSum, Duration.Inf()); 
return combinedDTOs; 

अभी हमारे पास प्रति अनुरोध लगभग 4-5 समांतर कार्य हैं। लेकिन यह लगभग 20-25 समानांतर कार्यों तक बढ़ने की उम्मीद है क्योंकि हम फ़ीड में नए प्रकार के सामान पेश करते हैं।

मेरा सवाल है, मैं इस डिजाइन को कैसे सुधार सकता हूं? टॉमकैट में यह सुनिश्चित करने के लिए कि किस तरह की ट्यूनिंग की आवश्यकता है, इस तरह के 20-25 समांतर कॉलों को भारी भार के तहत बेहतरीन रूप से परोसा जा सकता है।

मुझे समझ में आता है कि यह एक व्यापक विषय है, लेकिन कोई सुझाव बहुत उपयोगी होगा।

+0

वहाँ एक अनुरोध में सभी डेटा वापस जाने के लिए एक आवश्यकता है का उपयोग करना चाहते नहीं होगा? – AdamSkywalker

+0

हां, पूरी फ़ीड वापस कर दी गई है। भविष्य में, इसे पृष्ठित किया जा सकता है ... –

+0

@ माधुर-आहुजा: ऐसी कई चीजें हैं जिन्हें इस तरह के डिजाइन को बेहतर बनाने के लिए बेहतर किया जा सकता है - ऐसा लगता है कि आप कुछ ऐसा करने की कोशिश कर रहे हैं [http://martinfowler.com/articles/microservices.html] (सूक्ष्मजीव) फ़ीड के लिए डेटा के विभिन्न स्रोतों को एकत्रित करने के लिए। समस्या है ... टोमकैट आपकी समस्याओं का सबसे कम है। चूंकि प्रत्येक दूरस्थ सेवा विफल हो सकती है, इसलिए आपको इस तरह के डिज़ाइन को वास्तव में खींचने के लिए सिस्टम लचीलापन पर ध्यान केंद्रित करने की आवश्यकता होगी। सर्किट तोड़ने वाले और बैलेंसर्स पहली बात है जो मेरे दिमाग में आती है, लेकिन वे सवाल के दायरे में हैं :) –

उत्तर

4

मुझे समझ में आता है कि आप इसे मोबाइल ऐप से कॉल कर रहे हैं और फीड की संख्या बढ़ सकती है।

वापस लौटाए जाने वाले डेटा की मात्रा के आधार पर, क्या एक ही कॉल में कुछ फ़ीड्स के परिणाम वापस करना संभव होगा? इस तरह सर्वर काम करता है। आप सर्वर के नियंत्रण में हैं - आप उपयोगकर्ता डिवाइस और उनकी कनेक्शन की गति के नियंत्रण में नहीं हैं।

जैसा कि निकबिट सुझाव दिया गया है, DefferedResult जैसी चीजें लागू करने में वास्तव में आसान हैं। क्या यह संभव है कि इन फीड्स का डेटा त्वरित फैशन में अपडेट नहीं किया जाएगा? यदि ऐसा है - तो आपको EHCache और @Cacheable एनोटेशन के उपयोग की जांच करनी चाहिए।

आप ऐसे समाधान के साथ आ सकते हैं जहां उपयोगकर्ता हमेशा आपके टॉमकैट सर्वर से आपकी सामग्री का कैश संस्करण खींच रहा हो। लेकिन आपका टॉमकैट सर्वर पृष्ठभूमि में उस कैश को लगातार अद्यतन कर रहा है।

इसका काम का एक अतिरिक्त टुकड़ा - लेकिन दिन के अंत में अगर उपयोगकर्ता अनुभव तेज़ है - उपयोगकर्ताओं को इस एप्लिकेशन

7

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

यदि आपको प्रत्येक आने वाले HTTP अनुरोध के लिए चलाने के लिए 25 समांतर प्रक्रियाओं की आवश्यकता है, और आपको लगता है कि यह पागल है, तो आपको फिर से सोचने की आवश्यकता है कि आपका एप्लिकेशन कैसा काम करता है।

कोई टॉमकैट कॉन्फ़िगरेशन आपके प्रश्न में आपके द्वारा प्रस्तुत किए गए कार्यों में सहायता करेगा।

4

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

यदि यह मैं था तो मैं अपने आरईएसटी एपीआई से एकल या समन्वयक अभिनेताओं के पूल से अनुरोध करता हूं जो अनुरोध को असीमित रूप से संसाधित करेंगे। स्प्रिंग के रेस्ट कंट्रोलर का उपयोग करके इसे Callable या DeferredResult का उपयोग करके किया जा सकता है लेकिन स्पष्ट रूप से आप जो भी ढांचा उपयोग कर रहे हैं उसके बराबर होगा।

यह समन्वय अभिनेता फिर अन्य कलाकारों (यानी श्रमिकों) को प्रसंस्करण करने के लिए बंद कर देगा जो आई/ओ बाध्य कार्यों का ख्याल रखता है (अधिमानतः अन्य सीपीयू बाउंड धागे को अवरुद्ध नहीं करने के लिए अपने स्वयं के प्रेषक का उपयोग करके) और जवाब समन्वयक को उनके परिणामों के साथ।

एक बार सभी श्रमिकों ने अपना डेटा प्राप्त कर लिया है और परिणाम के साथ समन्वयक को जवाब दिया है तो मूल अनुरोध पूर्ण परिणाम सेट के साथ पूरा किया जा सकता है।

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