Node.js Uwzględnianie wydajności śledzenia urządzeń GPS

Question

Używając node.js jako serwera tcp, zamierzam zarządzać stosunkowo dużą liczbą urządzeń GPS (~ 3000 urządzeń) i jako pierwszy krok chcę przechowywać dane przychodzące w bazie danych, ale nawet w tej fazie wyobrażam sobie problemy z wydajnością, które mnie niepokoją i chciałbym je złapać, zanim mnie ugryzą.

1 - Patrząc na pisemne podobnych serwerów posługujących się językami jak java lub rubin widzę jakiś kod jak poniżej:

java

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

rubin

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

Co wydaje się, że dają one osobny wątek każdemu urządzeniu (gniazdu), które łączy się z serwerem tcp? Ponieważ plik node.js jest jednowątkowy i działa asynchronicznie, czy powinienem martwić się połączeniami przychodzącymi lub podobnymi prostymi metodami, które zaspokoją dużą liczbę jednoczesnych połączeń?

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

2 - Czy należy ograniczyć połączenia z bazą danych za pomocą puli połączeń? Jako że baza danych również zapytuje drugiej strony o GIS i monitoring, ile powinien mieć rozmiar puli?

3 - W jaki sposób mogę wykorzystać buforowanie (na przykład przy użyciu redis) w takim systemie?

Powinno być świetnie, jeśli ktoś rzuci trochę światła na te myśli. Chętnie również chciałbym usłyszeć inne myśli dotyczące wydajności, których być może doświadczasz lub które są świadome przy wdrażaniu takich systemów. Dzięki.

Answer 1

1. Wybór spośród opcji zostały wymienione powiedziałbym NodeJS jest w rzeczywistości lepszym rozwiązaniem dla przypadku użycia, ponieważ nie korzysta z jednego wątku na połączenie jak pozostałych dwóch opcji. Wątki są zazwyczaj zasobami skończonymi na danym komputerze. Java i Ruby mają jednak serwery "wydarzenie" i warto je przejrzeć, jeśli chcesz porównać jabłka do jabłek.

2. Myślę, że musisz powiedzieć więcej o bazie danych, której chcesz użyć, jeśli potrzebujesz porady dotyczącej łączenia połączeń. Jednak ponowne wykorzystanie połączeń, jeśli są kosztowne w konfiguracji, byłoby dobrym rozwiązaniem. Prawdopodobnie dobrym rozwiązaniem jest skonfigurowanie minimalnej i maksymalnej wielkości puli. Ostatecznie odpowiedni rozmiar do użycia to kwestia testowania.

3. Myślę, że korzyści z buforowania w tym systemie byłby minimalny, jak są przeważnie zapisywania danych. Jeśli dane są cenne, będziesz chciał zapisać je na dysku, a nie w pamięci. Z drugiej strony, jeśli masz klientów, którzy czytają zebrane dane, może buforowanie ich odczytów w coś takiego jak Redis może być dobrym pomysłem.

Answer 2

Jestem pewien, że jesteś świadomy, ale to brzmi tak, jakbyś próbował przedwcześnie zoptymalizować aplikację tutaj.

1- węzła zdarzeniami i bez blokowania sprawia, że ​​jest idealnym kandydatem do przechowywania dużej liczby otwartych połączeń gniazd, nie ma potrzeby rozwidlone za połączenia. Jak zawsze, upewnij się, że aplikacja jest prawidłowo zgrupowana. Udało mi się pomieścić ~ 100 tys. Otwartych gniazd TCP na taniego laptopa.Jeśli liczba urządzeń, które potrzebujesz wspierać, wciąż rośnie, po prostu skaluj odpowiednio.

2 - Widziałem, że planowałeś użyć PostgreSQL. Baseny są zawsze dobre.

3 Buforowanie jest przydatne w przypadku "gorących" danych. Rzeczy, o które często się pyta, a zatem posiadanie ich w pamięci lub wewnątrz redis (przechowywanie w pamięci) sprawia, że ​​wyszukiwanie danych jest szybsze i usuwa obciążenie systemu. W twoim przypadku, jeśli potrzebujesz tylko niektórych porcji danych, analizy lub bardziej przyczynowego, polecam spark lub solr w przeciwieństwie do zwykłej warstwy buforowania. Będzie to również znacznie tańsze i łatwiejsze w utrzymaniu.