2017-02-24 11 views
6

एक टीसीपी सर्वर के रूप में node.js का उपयोग करके, मैं अपेक्षाकृत बड़ी संख्या में जीपीएस डिवाइस (~ 3000 डिवाइस) का प्रबंधन करने जा रहा हूं और पहले चरण में डेटाबेस में आने वाले डेटा को स्टोर करने जा रहा हूं, लेकिन यहां तक ​​कि इस चरण में मैं कुछ प्रदर्शन मुद्दों की कल्पना करता हूं जो मुझे परेशान करते हैं और मैं उन्हें काटने से पहले उन्हें पकड़ना चाहता हूं।Node.js जीपीएस डिवाइस ट्रैकिंग प्रदर्शन विचार

1 - मैं निम्नलिखित की तरह कुछ कोड को देखने के जावा या माणिक जैसी भाषाओं का उपयोग करके लिखा समान सर्वर को देखते हुए:

जावा

Thread serverThread = new Thread(() -> { 
    System.out.println("Listening to server port 9000"); 
    while (true) { 
    try { 
     Socket socket = serverSocket.accept(); 
    ... 

माणिक

require 'socket' 
    server = TCPServer.new ("127.0.0.1",8080) 
    loop do 
    Thread.start(server.accept) do |client| 
    ... 

ऐसा लगता है कि वे प्रत्येक डिवाइस (सॉकेट) को अलग थ्रेड देते हैं जो टीसीपी सर्वर से कनेक्ट हो जाता है? चूंकि node.js एकल-थ्रेडेड है और असीमित रूप से कार्य करता है, क्या मुझे आने वाले कनेक्शनों के बारे में चिंतित होना चाहिए या निम्न सरल दृष्टिकोण जैसे कुछ एक साथ कनेक्शन की बड़ी संख्या को पूरा करेंगे?

net.createServer(function(device) { 
    device.on('data', function(data) { 
    // parse data 
    // store in database 
    }); 
}); 

2 - क्या मुझे कनेक्शन पूल का उपयोग कर डेटाबेस कनेक्शन को सीमित करना चाहिए? चूंकि डाटाबेस जीआईएस के लिए दूसरी ओर से पूछताछ करता है और निगरानी करता है कि पूल का आकार कितना होना चाहिए?

3 - मैं इस प्रणाली में कैशिंग (उदाहरण के लिए रेडिस का उपयोग करके) कैसे लाभ उठा सकता हूं?

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

+0

पूर्ण पक्ष प्रश्न, लेकिन आवधिक http अनुरोधों के बजाय सॉकेट का उपयोग क्यों करें? – Festo

+0

@ फेस्टो, मैं बस टीसीपी परत में जीपीएस उपकरणों के साथ संवाद कर सकता हूं, इस परत में मुझे निश्चित रूप से उपकरणों के साथ संवाद करने के लिए सॉकेट का उपयोग करना चाहिए, http सर्वर में मैं आवधिक अनुरोधों का उपयोग कर सकता हूं लेकिन डेटा रीयलटाइम के रूप में भी मैं सॉकेट के साथ जाऊंगा। – dNitro

उत्तर

3
  1. विकल्प आप मैं कहूंगा कि NodeJS वास्तव में आपके उपयोग के मामले के लिए एक बेहतर विकल्प है क्योंकि यह अन्य दो विकल्पों की तरह कनेक्शन प्रति एक धागा का उपयोग नहीं करता है सूचीबद्ध किया है के बीच चुनना। थ्रेड आमतौर पर किसी दिए गए मशीन पर एक सीमित संसाधन होते हैं। Java और Ruby में 'ईवेंट' सर्वर हैं, और यदि आप सेब की तुलना में सेब की तुलना करना चाहते हैं तो ये देखने लायक हैं।

  2. मुझे लगता है कि यदि आप कनेक्शन पूलिंग पर सलाह चाहते हैं तो आपको उस डेटाबेस के बारे में और अधिक कहना होगा जिसका उपयोग आप करना चाहते हैं। हालांकि अगर वे सेटअप करने के लिए महंगा हैं तो कनेक्शन का पुन: उपयोग करना एक अच्छी बात होगी। संभवतः पूल के न्यूनतम और अधिकतम आकार को कॉन्फ़िगर करने की सुविधा रखने का एक अच्छा विचार है। अंततः उपयोग करने के लिए सही आकार परीक्षण का मामला है।

  3. मुझे लगता है कि इस प्रणाली में कैशिंग का लाभ न्यूनतम होगा क्योंकि आप अधिकतर डेटा लिख ​​रहे हैं। यदि डेटा मूल्यवान है तो आप इसे स्मृति के बजाय डिस्क पर लिखना चाहेंगे। दूसरी तरफ, यदि आपके पास ऐसे क्लाइंट हैं जो एकत्रित डेटा पढ़ रहे हैं तो शायद रेडिस जैसे कुछ में उनके पढ़ने को कैशिंग करना एक अच्छा विचार हो सकता है।

+0

उत्तर के लिए धन्यवाद, मुझे वास्तव में इस चयन पर कुछ विश्वास की आवश्यकता है, कि आपका जवाब मुझे देता है, इसलिए मुझे लगता है कि मैं पहले चरण को पूरा कर सकता हूं। जावा और रूबी घटना सर्वर अच्छे सेब हैं लेकिन मैं node.js के साथ जा रहा हूं क्योंकि मैं इसके साथ अधिक प्रयोग कर रहा हूं। दरअसल मैं डेटाबेस cuz के रूप में पोस्टग्रेज़ का उपयोग करने जा रहा हूं मुझे अगले चरणों में जीआईएस के साथ काम करने की आवश्यकता होगी। और मेरा मतलब रेडिस को कैश परत के रूप में उपयोग करना था, इसलिए मुझे लगता है कि मैं इसे http सर्वर के साथ लागू करता हूं जब हम तय करते हैं कि हम क्वेरी डेटाबेस कैसे चाहते हैं और कौन सा डेटा हाथ में होना चाहिए। – dNitro

3

मुझे यकीन है कि आप जानते हैं, लेकिन ऐसा लगता है कि आप अपने आवेदन को समय-समय पर अनुकूलित करने की कोशिश कर रहे हैं।

1- नोड घटना-संचालित और गैर-अवरुद्ध होने के कारण यह बड़ी संख्या में खुले सॉकेट कनेक्शन रखने के लिए एक आदर्श उम्मीदवार बनाता है, प्रति कनेक्शन फोर्किंग की कोई आवश्यकता नहीं है। हमेशा के रूप में, सुनिश्चित करें कि आपका आवेदन ठीक से क्लस्टर किया गया है। मैं एक गंदगी सस्ते लैपटॉप पर ~ 100k खुला टीसीपी सॉकेट पकड़ने में सक्षम था।यदि डिवाइस की संख्या आपको कभी भी समर्थन देने की आवश्यकता है, तो उसके अनुसार बस स्केल करें।

2- मैंने देखा कि आप पोस्टग्रेज़ का उपयोग करने की योजना बना रहे थे। पूल हमेशा एक अच्छी बात है।

3- कैशिंग 'गर्म' डेटा के लिए उपयोगी है। सामग्री जो बहुत अधिक पूछताछ करती है, और इसलिए इसे स्मृति में या लाल रंग के अंदर (इन-मेमोरी स्टोरेज) इन डेटा लुकअप को तेज़ बनाता है और सिस्टम पर तनाव को हटा देता है। आपके मामले में, यदि आपको डेटा के कुछ हिस्सों, एनालिटिक्स के लिए या अधिक कारण उपयोग के लिए, केवल spark या solr की आवश्यकता होगी, तो एक सादे कैशिंग परत के विपरीत। यह भी बनाए रखने के लिए बहुत सस्ता और आसान होने जा रहा है।

+0

साफ अंक। मुझे लोचदार खोज के साथ कुछ प्राप्ति मिली है लेकिन लगता है कि इस क्षेत्र में स्पार्क या सोलर जैसे उपकरण अधिक परिपक्व हैं; तो उन पर नजर रखेगी। और मुझे लगता है कि 'समयपूर्व अनुकूलन' अभिव्यक्ति थी जो मैं इसके बाद पहली जगह थी लेकिन उसे नहीं मिला। मैं वास्तव में आपके साथ अपने अनुभव साझा करने की सराहना करता हूं। बहुत धन्यवाद। – dNitro

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