2012-03-22 11 views
5

Więc ja po prostu zaczyna nurkować w węźle i rozumiem, że I/O nie jest blokowanie i że pętla zdarzenie blokuje ale co ja zastanawiałem się:Czy serwer Node.js może przyjmować przychodzące żądania, gdy kolejka zdarzeń jest zablokowana?

Jeśli masz kod, który blokuje kolejka zdarzeń, czy serwer nadal będzie w stanie umieszczać przychodzące żądania na końcu kolejki, czy wszystkie z nich po prostu przekroczą limit czasu/odrzucenia?

+0

To dobre pytanie, na które może odpowiedzieć ktoś znający się na Nodes.js. Podejrzewam, * że biblioteka C++ obiektu 'http'' obsługuje faktyczne operacje we/wy w osobnym wątku, więc * powinna * kolejkować żądania (może nie dodawać zdarzeń do kolejki, dopóki pętla zdarzeń nie zostanie podana kontrolować ponownie i oczekujące zdarzenia są interpretowane i dodawane?) –

+0

Z tego, co przeczytałem wiem, że I/O jest asnieroniczny, ale po krótkiej wizualizacji wewnętrznej, jak działa programowanie asynchroniczne, czytałem, że asynchronizacja nie odradza nowych wątków? Czy to prawda? –

+0

"Programowanie asynchroniczne promuje używanie tego samego wątku do przetwarzania wielu żądań po kolei, ale bez żądania zablokowania wątku, jak zobaczymy później, operacje wykonywane przez żądania będą wykonywane" w kawałkach "." http: // www. theserverside.com/discussions/thread.tss?thread_id=61693 –

Odpowiedz

2

To nie ma nic wspólnego z węzła, a przynajmniej tej dyskusji dotychczas wprowadza żadnych dowodów zachowanie węzła.

Stos TCP sam w sobie akceptuje połączenie do własnej kolejki bez pomocy programu korzystającego z gniazda akceptującego. Jeśli ta kolejka się zapełni, kolejne żądania będą czekać, aż w kolejce połączenia TCP będzie miejsce. Takie "niedopuszczalne" połączenia nie są odrzucane, chociaż mogą się wygasnąć, jeśli coś naprawdę się opóźni.

Najważniejsze jest jednak to, że przykładowa odpowiedź, za pomocą curl, nie udowadnia niczego poza podstawowym zachowaniem stosu TCP, ale to prawdopodobnie nie ma znaczenia, ponieważ pierwotny problem dotyczył tego, że połączenia mogą się odbijać. Stanie się tak tylko wtedy, gdy twój serwer jest tak przeciążony (lub źle napisany), że jest skutecznie przeciążony, a odrzucanie niektórych żądań jest najlepszą szansą na zapewnienie przynajmniej części usług dla niektórych użytkowników.

+0

Dziękuję, bardzo podoba mi się ta odpowiedź. W ogóle nie wiedziałem o stosie TCP –

9

Tak. Serwer nadal może kolejkować żądania. Aby zademonstrować, zrobiłem następujący plik, który blokuje przez 10 sekund, uruchomiłem go i zwinnąłem serwer na innym terminalu.

require('http').createServer(function(req, res) { 
    console.log('got a request!'); 
    res.end('hello world!\n'); 
}).listen(3000); 

var t = Date.now(); 
console.log('blocking..'); 
while(t + 10000 > Date.now()); 
console.log('not blocking anymore'); 

Wynik z systemem to

blocking.. 
not blocking anymore 
got a request! 
+0

W porządku, myślę, że to dobrze odpowiada. Zastanawiam się, czy przychodzące żądania zostały umieszczone w kolejce po wystąpieniu blokady, a następnie zalogowano się "otrzymałem żądanie" lub gdy przychodzące żądanie zostało umieszczone w kolejce PODCZAS blokowania, a następnie "dostałem żądanie" zostało zwolnione po pętla zdarzeń została zwolniona. –

+0

To odpowiada jednak ważniejszemu aspektowi pytania, ale przychodzące prośby nie odbiły się ... co było moim głównym zmartwieniem. Dziękuję, dobry sir –

+0

Jeśli I/O jest naprawdę asynchroniczny, powinien on zostać umieszczony podczas bloku, ale jeśli kolejka zdarzeń jest zablokowana, nie widzę sposobu, w jaki mogłaby ona zaakceptować więcej zdarzeń ...chyba że sama kolejka znajduje się w asynchronicznym środowisku, a każde zdarzenie jest obsługiwane w środowisku blokującym ... domyślam się, że kolejka zdarzeń jest w środowisku asynchronicznym lub blokującym ... ale dla wszystkich intensywnych celów pytanie jest odpowiedział. Mogę spać w nocy. –

Powiązane problemy