2016-09-10 9 views
1

Derzeit ein Projekt mit einem Heroku Standard-1X Dyno mit Node, Express und Socket.io. Die Prämisse der App ziemlich einfach: Menschen nach Artikeln von einem Client suchen (unter der Haube als Dicts gespeichert, wie so):Node.js und Express mit socket.io auf Heroku - H12 & H13 Fehler

['Item':'Coffee', 
    'Id':0247508725, 
    'Location': 'Baker Street'] 

und wählen Sie diese aus, dann werden die Elemente Schlüsselwerte werden an den Node-Server geschoben und in einer Liste gespeichert. Die Liste wird dann von den übrigen Clients in Echtzeit abgerufen. Clients sind alle nativ Swift iOS apps

Ich lief es zum ersten Mal mit rund 60 Benutzern, alle suchen und Elemente gleichzeitig hinzufügen. Die Ergebnisse aus der Heroku Armaturenbrett waren horrend:

Heroku Dashboard

Ich dachte, ich in der Prüfung gründlich gewesen war, hatte ich noch nie so viele H12 & H13 Fehler gesehen. Ein Teil von mir denkt, dass es auf meiner Serverseite ineffizienter Code oder einfach das Fehlen einer richtigen Node-Implementierung für so viele Anfragen ist, so dass ich nicht ständig auf I/O warte wegen der ganzen Single-Threading-Ness-Vereinbarung. Hier

ist ein Beispiel für die Funktion Server-Seite, die ein Element auf dieser Liste hinzuzufügen läuft:

clientSocket.on("additionToList", function(Location,Item,Id){ 
    client.query("INSERT q_venue_list (item_name, item_id, at_location) VALUES ($1, $2, $3)",[Item,Id,Location], function(err, result) { 
if(err) { 
    return console.error('error running insert', err); 
} 
io.sockets.in(Location).emit('updateList'); 
    }); 
}); 

Wenn die Kunden Steckdosen im Raum Location erhalten 'updateList' Befehl, sie ziehen die neue Liste. Lagerung und Rückholung funktionieren alle gut, aber aus irgendeinem Grund ist bei all diesen Leuten alles hängengeblieben und extrem zurückgeblieben. Ich weiß kaum, was ich tue aber ich versuche nur zu verstehen, wo ich vielleicht falsch liege. Ich kann nicht clustern, weil ich nur Zugang zu einem Kern bekomme, also wäre die nächstbeste Option async zu erkunden? Könnte es ein schreckliches Gerätesignal sein, gekoppelt mit Warten auf I/O, das alle Timeouts verursacht?

Ich bin nur darauf aus, dies zu verstehen, jede Hilfe wird geschätzt. Lassen Sie mich wissen, ob ich mehr Informationen zur Verfügung stellen kann.

+0

Ohne mehr von Ihrem Code kann ich nicht wirklich sagen, was von unten ist, aber es scheint so, als ob viele Fehler darauf hindeuten, dass Sie das asynchrone Potential von Node nicht nutzen. – sova

+0

@sova du hast wahrscheinlich recht. Sind Sie jemals auf Ressourcen gestoßen, die diese Konzepte für Laien, die gerade lernen, lächerlich darstellen? – daulSwift

+0

Nun, in letzter Zeit habe ich gerade das Callback-Modell selbst verstanden, ich kann den Kurs der Codeshow "Echtzeit-Web mit node.js" wärmstens empfehlen. Einige Videos und interaktive Übungen helfen einem den Kern zu verstehen. Versuchen Sie, auf der Javascript Event Loop als eine nette Ergänzung zu lesen. – sova

Antwort

0

Für jeden, der über diesen Thread mit seltsamen Problemen wie diesem stolperte, fand ich schließlich heraus, was das Problem war. Ich habe die Sockelschicht nicht freigegeben und die Verbindung (socket.disconnect) unter applicationDidEnterBackground oder applicationWillResignActive getrennt. Dies führte dazu, dass der Socket im Backend bis zum Timeout (55 Sekunden) wartete. Die ganze Zeit, die es wartete, war es den Rest der Event-Schleife verpuffen; Folglich würden andere eingehende Anfragen warten, dann würden sie ebenfalls eine Zeitüberschreitung haben.

tl; dr: seien Sie fleißig beim Öffnen und Schließen Ihrer Steckdosen. Vergessen Sie nicht, sie zu schließen, wenn der Benutzer die App beendet.