Ankündigung

Einklappen
Keine Ankündigung bisher.

Mehrere HTTP POSTs verursachen Wartezeit

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Mehrere HTTP POSTs verursachen Wartezeit

    Ich habe auf einem Testserver eine PHP-Webseite zu laufen, die mit zahlreichen SELECT-Feldern ausgestattet ist. Die Infos in den Feldern werden aus entsprechenden Tabellen einer PostgreSQL-Datenbank gelesen. Alle Tabellen sind nicht besonders groß. Meist nur eine Schlüsselnummer und ein Namensfeld und nie mehr als 2000 Einträge. Die Selektionsfelder bauen aufeinander auf und werden über POST Requests gefüllt. Man muss also zuerst einen Landkreis auswählen, kann dann eine Gemeinde in diesem Landkreis auswählen usw. (Der Zugriff auf die Select-Felder wird mit JScript gesteuert) Die Anwendung läuft auf dem Testserver sehr flüssig und ohne Lags.

    Jetzt habe ich alles auf den Produktivserver kopiert. Der läuft als Loadbalancer zusammen mit 2 anderen Servern. Wenn ich jetzt das Formular lade, kann ich über Firebug beobachten, dass nur 1-2 POST-Befehle sofort ausgeführt werden und die anderen immer genau 30 sekunden später, bzw. 60 sek oder 90 sekunden später. Wie so eine Art vordefiniertes Zeitinterwall, was verhindern soll, dass zu viele POSTs auf einmal abgesendet werden.

    Bzgl. Server-Konfiguration bin ich völliger Laie. In der php.ini finde ich keinen Eintrag, der das Verhalten steuern könnte. Habt Ihr eine Idee, worin das Problem liegen könnte oder in welcher config das einstellbar wäre? Bin für jeden Hinweis dankbar.


  • #2
    Warum verwendest du dafür POST? POST dient dazu Daten zu schreiben.

    Für mich sieht es so aus, als würde das PHP-Skript nicht beendet werden, sondern läuft einfach in einem Timeout. Dafür würden die 30 Sekunden Intervalle sprechen. Aber das kannst du ja relativ leicht selber rausfinden, wenn du einen Profiler verwendest. Und natürlich sollten die Error-Logs immer beobachtet werden. Ein Timeout löst eine Fehlermeldung aus.

    Kommentar


    • #3
      Zitat von hellbringer Beitrag anzeigen
      Für mich sieht es so aus, als würde das PHP-Skript nicht beendet werden, sondern läuft einfach in einem Timeout. Dafür würden die 30 Sekunden Intervalle sprechen. Aber das kannst du ja relativ leicht selber rausfinden, wenn du einen Profiler verwendest. Und natürlich sollten die Error-Logs immer beobachtet werden. Ein Timeout löst eine Fehlermeldung aus.
      Das erklärt aber nicht im geringsten, warum derselbe code auf dem Testserver läuft.

      Kommentar


      • #4
        Durch eine ev. abweichende Config. schon.
        Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
        PHP.de Wissenssammlung | Kein Support per PN

        Kommentar


        • #5
          Zitat von Lencer Beitrag anzeigen
          Das erklärt aber nicht im geringsten, warum derselbe code auf dem Testserver läuft.
          Hast du dir schon mal die HTTP-Requests und -Responses angeschaut? Irgendwelche auffälligen Unterschiede?

          Kommentar


          • #6
            Zitat von hausl Beitrag anzeigen
            Durch eine ev. abweichende Config. schon.
            Sorry, config was? Welche Konfigurationen genau. php.ini? Server Configs? Und wenn letzteres, welche Einträge könnten sowas verursachen?

            Kommentar


            • #7
              Zitat von hellbringer Beitrag anzeigen

              Hast du dir schon mal die HTTP-Requests und -Responses angeschaut? Irgendwelche auffälligen Unterschiede?
              Hab jetzt nochmal detailliert mit identischen Datensätzen im Firebug verglichen. Kann keine Unterschiede feststellen. Error Reporting auf der Seite gibt auch keinerlei Fehler aus.

              Kommentar


              • #8
                Browser haben ein max parallel connection limit das per Protokoll festlegt wieviele gleichzeitige Verbindungen zu einem Host aufgebaut werden dürfen. Bist du sicher, das dieses Limit hier nicht greift ?
                [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                Kommentar


                • #9
                  Zitat von tr0y Beitrag anzeigen
                  Browser haben ein max parallel connection limit das per Protokoll festlegt wieviele gleichzeitige Verbindungen zu einem Host aufgebaut werden dürfen. Bist du sicher, das dieses Limit hier nicht greift ?
                  Laut http://stackoverflow.com/questions/9...s-in-a-browser sollten es im Firefox aber mindestens 6 Verbindungen sein. (Laut meinen Beobachtungen sind es max drei POST gleichzeitig, die durchgehen). Wir schließen ein Client-Problem auch eher aus. Chrome und Firefox zeigen ohne jede Erweiterung das gleiche Verhalten. Zudem erklärt Dein Ansatz auch nicht, warum die Seite auf dem Testsystem wunderbar funktioniert. Trotzdem Danke für Deine Idee.

                  Kommentar


                  • #10
                    Läuft auf dem Nicht-Test-System vielleicht mod_bandwidth der serverseitig die Connections limitiert ? Wenn sich die Implementierung auf 2 Systemen unterschiedlich verhält, ist die Wahrscheinlichkeit ziemlich hoch, das der Server bei dem es Probleme gibt, mehr Limits anders konfiguriert sind, als auf dem Test-System.
                    [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                    Kommentar


                    • #11
                      Laut IT liegt das Problem in meiner (nicht wirklich vorhandenen) Session-Verwaltung. Damit kommt wohl der Load Balancer auf dem Produktivsystem nicht klar. Mir wurde jetzt empfohlen, die Session-Verwaltung über eine Datenbank zu realisieren. Die Webseite wird allerdings nur im Intranet laufen und maximal 5 Kollegen werden gleichzeitig zugreifen. Macht das Sinn? Ich würde gern mal Eure offene Meinung dazu hören.

                      Kommentar


                      • #12
                        Die Sesson war auch mein erster Gedanke. Die Session auf die Datenbank umzustellen ist schnell gemacht. Allerdings solltest du da wissen, was du tust. Es gibt nämlich einen Grund, warum die Session mehr als einen gleichzeitigen Zugriff blockiert. Das Thema ist etwas komplexer und es geht dabei um Race Conditions. Habe gerade keine Zeit breiter auf das Thema einzugehen. Aber das sollte erst mal zum googlen reichen.
                        Standards - Best Practices - AwesomePHP - Guideline für WebApps

                        Kommentar

                        Lädt...
                        X