2011-09-12 7 views
5

हमारे पास एक प्रणाली है जो अनुरोधों का एक बैच देता है, बाहरी तृतीय पक्ष एपीआई को समान संख्या में कॉल करता है। यह देखते हुए कि यह एक I/O बाध्य कार्य है, हम वर्तमान में इन अनुरोधों की सेवा के लिए आकार 20 के कैश किए गए थ्रेड-पूल का उपयोग करते हैं।बाहरी API अनुरोधों के बड़े # के लिए सॉफ्टवेयर/हार्डवेयर स्केलिंग?

उपयोग अधिक कोर (कम संदर्भ-स्विचिंग, अधिक समवर्ती धागे समर्थन करने में सक्षम)

या

अधिक मशीनों का उपयोग के साथ कम मशीनों: उपरोक्त के अलावा, समाधान करने के लिए है कमोडिटी/सस्ता हार्डवेयर (पिज्जा बक्से) का लाभ उठाकर

हमें एक दिन प्राप्त अनुरोधों की संख्या के क्रम में है लाखों लोगों की।

हम जावा का उपयोग कर रहे हैं, इसलिए यहाँ धागे कर्नेल हैं, न कि "हरा"।

अन्य अंक/विचार:

  • Hadoop आमतौर पर इस प्रकार की समस्याओं के लिए प्रयोग किया जाता है, लेकिन यह वास्तविक समय बनाम टकसाली ऑफ़लाइन डाटा खनन की जरूरत है।
  • API अनुरोधों पर औसत
  • 200 मि.से 2 सेकंड से कहीं भी ले अनुरोध
  • प्रश्न में 3 पार्टी अधिक अनुरोध हम कर सकते हैं संभवतः आग (भुगतान विक्रेता) से सर्विसिंग करने में सक्षम है के बीच कोई साझा राज्य नहीं है।
+0

क्या आपने राज्य साझा किया है, अनुरोधों को संभालने के लिए उपयोग किया जाता है? यदि हां, तो यह कितनी बार बदल रहा है? इस साझा राज्य का आकार क्या है? –

+1

तृतीय पक्ष एपीआई पर सीमा क्या है?यदि आपके द्वारा कॉल की गई एपीआई अभी भी बाधा है तो आपके ढेर को स्केल करने का कोई मतलब नहीं है। क्या आप इससे प्राप्त डेटा को कैश कर सकते हैं या एक कॉल से डेटा का उपयोग कर सकते हैं सेवा/आपूर्ति अपने ग्राहकों को एक साथ कई? – Paolo

+0

उपरोक्त प्रश्नों के उत्तर देने के लिए मेरी मूल पोस्ट संपादित की गई। कॉल पूरी तरह से स्वतंत्र हैं, इसलिए कैश करने के लिए कोई डेटा नहीं है। – smonky

उत्तर

1

यह मेरे लिए स्पष्ट नहीं है कि आपको अधिक संसाधनों (बड़ी मशीनों या अधिक मशीनों) की आवश्यकता है। यदि आप एक दिन में अधिकतम 2 मिलियन अनुरोधों के बारे में बात कर रहे हैं, तो इसका मतलब है:

  • ~ प्रति सेकंड 110 अनुरोध। यह इतना तेज़ नहीं है। क्या अनुरोध विशेष रूप से बड़े हैं? या वहाँ बड़े विस्फोट हैं? क्या आप तीसरे पक्ष के एपीआई को प्रेषित करने के अलावा भारी प्रसंस्करण कर रहे हैं? आपने मुझे अब तक कोई जानकारी नहीं दी है जो मुझे विश्वास दिलाती है कि एक ही कोर पर अपनी पूरी सेवा चलाने के लिए संभव नहीं है। (यदि आप एन + 2 रिडंडेंसी चाहते हैं तो इसे तीन सबसे छोटी संभावित मशीनों पर कॉल करें।)
  • औसतन ~ 220 सक्रिय अनुरोध। दोबारा, ऐसा लगता है कि एक मशीन के लिए कोई समस्या नहीं है, यहां तक ​​कि एक (पूल) थ्रेड-प्रति-अनुरोध मॉडल के साथ भी। आप अपने पूल आकार का विस्तार क्यों नहीं करते और इसे एक दिन कहते हैं? क्या ये वास्तव में विस्फोटक हैं? (और क्या आपके पास वास्तव में सख्त विलंबता/विश्वसनीयता आवश्यकताएं हैं?) क्या सक्रिय होने पर उन्हें बड़ी मात्रा में रैम की आवश्यकता है?

क्या आप सोच सकते हैं कि आपको यह विकल्प क्यों बनाना है, इस बारे में कुछ और जानकारी दे सकते हैं?

0

बड़ी संख्या में धागे का उपयोग करने के बजाय, आप घटनाओं से प्रेरित I/O के साथ node.js का उपयोग कर चेतावनी के साथ बेहतर किराया दे सकते हैं, जिसका अर्थ यह हो सकता है कि इसका एक बड़ा पुनर्लेख और तथ्य यह है कि node.js काफी युवा है।

यह SO article रुचि का हो सकता है।

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