2017-02-24 21 views
6

Sử dụng node.js làm máy chủ tcp, tôi sẽ quản lý số lượng thiết bị GPS tương đối lớn (~ 3000 thiết bị) và bước đầu tiên sẽ lưu trữ dữ liệu đến trong cơ sở dữ liệu, nhưng ngay cả trong giai đoạn này tôi hình dung một số vấn đề hiệu suất làm phiền tôi và tôi muốn bắt gặp họ trước khi họ cắn tôi.Node.js Cân nhắc hiệu suất theo dõi thiết bị GPS

1 - Nhìn vào các máy chủ tương tự được viết bằng các ngôn ngữ như java hoặc ruby ​​ tôi thấy một số mã như sau:

java

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

ruby ​​

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

Có vẻ như chúng đưa ra chuỗi riêng biệt cho mọi thiết bị (socket) được kết nối với máy chủ tcp? Vì node.js là một luồng đơn và hoạt động không đồng bộ, tôi có nên quan tâm đến các kết nối đến hay một cái gì đó giống như cách tiếp cận đơn giản sau đây sẽ đáp ứng số lượng lớn các kết nối đồng thời không?

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

2 - Tôi có nên hạn chế kết nối cơ sở dữ liệu bằng cách sử dụng hồ bơi kết nối không? Vì cơ sở dữ liệu cũng truy vấn từ phía bên kia cho GIS và giám sát, kích thước hồ bơi nên là bao nhiêu?

3 - Làm cách nào tôi có thể hưởng lợi khi lưu vào bộ nhớ cache (ví dụ: sử dụng redis) trong hệ thống như vậy?

Sẽ rất tuyệt nếu ai đó làm sáng tỏ suy nghĩ này. Tôi cũng sẵn sàng nghe bất kỳ suy nghĩ hiệu suất nào khác mà bạn có thể cũng gặp phải hoặc nhận thức được trong việc triển khai các hệ thống như vậy. Cảm ơn.

+0

Câu hỏi phụ hoàn chỉnh, nhưng tại sao lại sử dụng ổ cắm thay vì yêu cầu http định kỳ? – Festo

+0

@ Festo, tôi chỉ có thể giao tiếp với thiết bị GPS trong lớp TCP, trong lớp này tôi chắc chắn nên sử dụng ổ cắm để giao tiếp với thiết bị, trong máy chủ http tôi có thể sử dụng yêu cầu định kỳ nhưng dữ liệu sẽ là thời gian thực. – dNitro

Trả lời

3
  1. Chọn trong số các tùy chọn bạn đã liệt kê Tôi sẽ nói NodeJS thực sự là lựa chọn tốt hơn cho trường hợp sử dụng của bạn vì nó không sử dụng một chuỗi cho mỗi kết nối như hai tùy chọn khác. Các luồng thường là một tài nguyên hữu hạn trên một máy đã cho. JavaRuby có các máy chủ 'có sự kiện' và đây là những giá trị đáng xem nếu bạn muốn một quả táo so sánh với táo.

  2. Tôi nghĩ bạn cần nói nhiều hơn về cơ sở dữ liệu bạn định sử dụng nếu bạn muốn được tư vấn về kết nối tổng hợp. Tuy nhiên tái sử dụng các kết nối nếu chúng tốn kém để thiết lập sẽ là một điều tốt để làm. Nó có lẽ là một ý tưởng tốt để có cơ sở để cấu hình kích thước tối thiểu và tối đa của hồ bơi. Cuối cùng kích thước chính xác để sử dụng là một vấn đề của thử nghiệm.

  3. Tôi nghĩ rằng lợi ích của bộ nhớ đệm trong hệ thống này sẽ là tối thiểu khi bạn chủ yếu là viết dữ liệu. Nếu dữ liệu có giá trị, bạn sẽ muốn ghi nó vào đĩa thay vì bộ nhớ. Mặt khác, nếu bạn có khách hàng đang đọc dữ liệu thu thập được có lẽ bộ nhớ đệm đọc của họ trong một cái gì đó như Redis có thể là một ý tưởng tốt.

+0

Cảm ơn câu trả lời, tôi thực sự cần một số sự tự tin về lựa chọn này, câu trả lời của bạn cho tôi vì vậy tôi nghĩ rằng tôi có thể hoàn thành giai đoạn đầu tiên. Các máy chủ Java và Ruby là các applet tốt nhưng tôi sẽ đi với node.js vì tôi có nhiều kinh nghiệm hơn với nó. Trên thực tế tôi sẽ sử dụng postgres làm cơ sở dữ liệu cuz Tôi sẽ cần phải làm việc với GIS trong các giai đoạn tiếp theo. và tôi đã có nghĩa là sử dụng Redis như là một lớp bộ nhớ cache vì vậy tôi nghĩ rằng tôi thực hiện nó cùng với máy chủ http khi chúng tôi quyết định cách chúng tôi muốn cơ sở dữ liệu truy vấn và dữ liệu nào nên ở trong tầm tay. – dNitro

3

Tôi chắc chắn bạn đã biết, nhưng điều này có vẻ như bạn đang cố gắng tối ưu hóa ứng dụng của mình sớm ở đây.

1- Nút được định hướng theo sự kiện và không chặn khiến ứng dụng trở thành ứng cử viên hoàn hảo để giữ số lượng lớn các kết nối ổ cắm mở, không cần phải tìm kiếm kết nối. Như thường lệ, hãy đảm bảo rằng ứng dụng của bạn được nhóm đúng cách. Tôi đã có thể giữ ~ 100k mở ổ cắm TCP trên một máy tính xách tay giá rẻ bẩn.Nếu số lượng thiết bị bạn cần để hỗ trợ bao giờ phát triển vượt ra ngoài đó, chỉ cần quy mô cho phù hợp.

2- Tôi thấy bạn đang lên kế hoạch sử dụng postgres. Hồ bơi luôn luôn là một điều tốt.

3- Caching rất hữu ích cho dữ liệu 'nóng'. Những thứ được truy vấn rất nhiều, và do đó có nó trong bộ nhớ hoặc bên trong redis (trong bộ nhớ lưu trữ) làm cho các tra cứu dữ liệu nhanh hơn và loại bỏ căng thẳng trên hệ thống. Trong trường hợp của bạn, nếu bạn chỉ cần nhận một lượng dữ liệu nhất định, để phân tích hoặc để sử dụng nhiều hơn, tôi sẽ giới thiệu spark hoặc solr như trái ngược với một lớp bộ nhớ đệm đơn giản. Nó cũng sẽ rẻ hơn và dễ bảo trì hơn.

+0

Điểm gọn gàng. Tôi đã có một số exprience với ElasticSearch nhưng có vẻ như các công cụ như tia lửa hoặc solr là trưởng thành hơn nhiều trong lĩnh vực này; vì vậy sẽ theo dõi họ. và tôi nghĩ rằng 'tối ưu hóa sớm' là biểu hiện tôi đã được sau khi nó ở vị trí đầu tiên nhưng không thể tìm thấy nó. Tôi thực sự đánh giá cao việc chia sẻ trải nghiệm của bạn với tôi. Cảm ơn nhiều. – dNitro

Các vấn đề liên quan