jQuery.post - Hoher Load

  • Hallo,

    ich habe gerade ein Problem mit einem Post-Request auf eine Express-Route.
    Habe es schon mit $.post und $.ajax versucht. Jedoch funktionieren beide nicht so wirklich.

    Irgendwo liegt anscheinend ein Problem vor, aber ich kann mir (da es auch nur ein kleiner Textcode ist) erklären woher dieser Fehler kommen könnte.
    Vielleicht kann mir ja einer von euch helfen?

    meine $.post - Variante:

    Dies wird ausgelöst, wenn eine Checkbox verändert wird.
    Auf meinem Server liegt dafür folgende Route:

    req: Request mit body für Postinhalte
    Die Parameter des Requests sind, so wie beim Client angegeben auch am Server vorhanden: option = true o. false

    Die Anfrage kommt innerhalb von 3ms am Server an.
    Ein folgender JS Code, der die Value des Elements auf on oder off verändert (clientseitig) wird ebenfalls ausgeführt.

    Allerdings dauert das Empfangen seltsamer weise 120Sekunden...
    Die Firefox-Netzwerkanalyse sagt mir beim Warten auch nur 3ms.
    Also insgesamt eigentlich mit Empfangen sollten es ca 12-14ms sein, aber 120005ms?!

    Irgendwo wird die Antwort vom Server aufgehalten, aber ich kann mir nicht erklären wo.
    Weiß jemand vielleicht was das Problem sein könnte?


    lg und ein schönes Wochenende..

  • irgendwo nen link?

    und testest du das lokal oder wirklich mit server?
    mach mal nen console.time('meintest');
    beim start vom ajax und nen console.timeEnd('meintest');
    in den success-callback bzw in den complete-callback. damit erhälst du tatsächliche werte der dauer.
    firebug hat derzeit n paar probleme mit Messungs-slowdowns bei allem was mit js zu tun hat.

    an deinem code ist jetzt nichts auffälliges, was bremst also was derart bremst..^^
    du kannst zusätzlich mal deine varibale: $('#accesschanged') als variable cachen, dann haste nicht jedes mal nen selektor-aufruf der zeit frisst.
    dann mehr chaining machen.
    könnte ungefähr so aussehen:

    HTML
    $.post('/control', { option: $('#allowAnalytics').is(':checked') }).done(function(res) {
        console.log(res);
        var achanged = $('#accesschanged');
        achanged.html(res.msg)
            .fadeIn(300, function() {
                window.setTimeout(function() {
                    arguments[1].fadeOut(500);
                }, 2000, $(this));
            });
    });

    ich habs jetzt nicht getestet, kann also gut sein, dass des so nicht läuft bzw ich was übersehen hab.

    kannst du den server rebooten? dass der mal den RAM leer bekommt?
    also so ne verzögerung ist eigentlich nicht wirklich normal.

  • Danke für den Tipp mit der Variable, sind immer die Kleinigkeiten die es noch besser machen. :)

    Bzgl. Firebug hatte ich eigentlich noch keine Probleme.
    Ich arbeite nicht mit Server, sondern lokal. JavaScript auf "Server" und "Client"-seite.

    Habe auch schon mal versucht den Cache zu löschen, aber macht keinen Unterschied.

    Die 2 Debugausgaben, sind ebenfalls wie in Firebug.

    [17:43:15.848] meintest: Timer gestartet
    [17:45:15.861] meintest: 120012.56ms


    Ja das ist wirklich nicht normal, desswegen weiß ich leider auch absolut nicht weiter :/

    Einmal editiert, zuletzt von Bleistift (30. November 2013 um 21:57)

  • ja dann versuch mal ne zweite maschine ins boot zu holen und teste mal mit nem richtigen server.
    hatte letztens im büro auch das problem, dass ich ajaxcalls machte.. 2 von 3 liefen mit 70ms und einer hatte immer so zwischen 200 ms und 3 sekunden.
    hab den scheiss dann mal auf dem rechner von nem kollegen im netzwerk gechecked und da lief es dann flüssig mit 50 bis 80 ms.

    sorge für echte bedingungen und dann schauste nochmal.
    und guck mal, ob du irgendwie nen monitoring aufgebaut bekommst, wo du serverside checken kannst was die verarbeitung anstellt

  • hm, aber was genau kann denn dafür der Grund sein?

    Woher krieg ich jetzt ein Server, wo Node drauf läuft?
    Gibt da leider nur sehr wenige Möglichkeiten noch.

    Hast du vielleicht einen?

    Alle Requests funktionieren eigentlich winwandfrei, warum dieser nicht?
    Ist das wirklich ein Grund für einen so hohen Load? 2 Minuten? Wo kommen die denn her? :confused:

  • ich kanns dir nicht sagen, hab auch selber keinen server mit node.js laufen.

    und anhand deines codes kann ich dir auch nicht sagen worans liegt, aber wenn der request in milisekunden abgefeuert wird und die response so lange dauert, vermute ich liegt das problem eher in der verarbeitung, als im clientside script

  • Nein die Verarbeitung ist ja das Warten, das liegt zwischen 1 und 3 ms.
    Verbindugsaufbau ebenfalls 1-3ms

    Ich habe ja auch auf der Serverside geloggt, die Daten kommen dort sofort und korrekt an!
    Irgendwo auf dem Weg vom Server zu Client zurück, bleibt der irgendwo hängen..

    Kann mir nicht mal vorstellen, dass das irgendwas mit dem Code zu tun hat.
    Aber, verstehen tu ichs auch absolut nicht und so lassen geht ja auch nicht :D

    Gibts denn noch Möglichkeiten das ganze auf eine andere Art und Weise zu lösen?
    Wie gesagt mit $.ajax type POST habe ich das auch schon versucht und das gleiche Problem...

  • das einzige was ich sonst noch empfehlen könnte ist im success-callback zu wirken, statt im complete.
    aber wie gehabt, wenn der request vom client an den server geht (in ms) und das logging auch auf dem server direkt stattfindet (in ms)
    und dann die antwort zurückgeht und ewig braucht, haste in der verarbeitung oder im senden nen datscher.

    aber woran das dann liegen kann... haste ma in nem node.js-forum oder bei stackoverflow mal gesucht?

  • Bei Node oder Express kann ich dazu nichts finden.
    Wenn ich jetzt google, finde ich nur meinen Beitrag der das trift.
    Andere hatten das Problem mit 4 Sekunden o.s. aber das waren andere Themen ..

    Bei $.ajax hatte ich das in den success Callback reingeschrieben.
    $.ajax({
    type: "POST",
    url: url,
    context: document.body,
    data: { option: ischecked },
    success: function(res) { ... }
    });

    gleiches Problem.

  • Manchmal muss man ne Nacht drüber schlafen um das Problem zu sehen :D

    Also was irgendwie anscheinend gefailt hat war das res.json am Ende nach dem Else.
    Er rendert den Inhalt wahrscheinlich zu langsam und dann versucht Express noch eine Seite zu rendern bzw. noch etwas zu senden.
    Das hat sich da wahrscheinlich blockiert. Ebenfalls habe ich .json durch .send ersetzt, obwohl .json dafür ja eigentlich das richtige wäre, weils ja JSON ist .. Naja.
    Manchmal hat Schnelligkeit auch seinen Preis :D

    Richtig müsste die Route also so aussehen, falls mal jemand das gleiche Problem hat:


    So kann ich die Antwort true/false vom Control analysieren und wenn kein gültiges Control übermittelt wird, wird trotzdem noch gesagt, das dies nicht valide ist.

    So kommt das Ergebnis mit einem gesamt Load von 5ms an, wie gewollt.
    Danke trotzdem für deine Hilfe!

    Hätte mir gleich mal einfallen können das zu testen.
    Ist mir leider nur absolut nicht ins Bild gekommen :)


    lg

    4 Mal editiert, zuletzt von Bleistift (2. Dezember 2013 um 10:00)

  • Eigentlich hatte ich das in Node so verstanden: nach dem Rendern ist schluss, ähnlich wie ein break.
    Entweder falsch verstanden oder was gelesen was nicht da stand :D
    Vielleicht ist es auch nur zu schnell und es gab ja für die 'no valid control' Antwort keine Abgrenzung.
    Ein Bug?! :D

    Naja was solls.