Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Eine Anfrage blockiert alle weiteren Anfragen.

Einklappen

Neue Werbung 2019

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

  • [Erledigt] Eine Anfrage blockiert alle weiteren Anfragen.

    Hallo Leute,

    ich habe ein Script geschrieben, mit welchem ich Daten von externen Seiten verarbeiten kann. Dieser Vorgang kann manchmal sogar 1-2 Minuten brauchen (große XML-Dateien müssen eingelesen und verarbeitet werden). Dies funktioniert nun auch sehr gut. Nur musste ich leider feststellen, dass in der Zeit, wo ein solcher Import-Vorgang abläuft, alle anderen Anfragen blockiert werden. Ich kam auf den Verdacht, als ich während eines Import-Vorgangs ein ganz normales Anzeigescript aufrufen wollte. Dies hat erst zuende geladen, als der Import-Vorgang abgeschlossen war. An der CPU Auslastung kann es nicht liegen, das habe ich bereits kontrolliert.
    Leider kann ich mir dies nicht erklären und hoffe daher auf eure Hilfe. Im Internet bin ich hierfür auch nicht wirklich fündig geworden

    Kleine Anmerkung noch: ich breche mein Import-Script mit fastcgi_finish_request() ab. Grund: Die Datenlieferanten wollen eine Statusmeldung haben, wie weit der Import bereits ist. Daher gebe ich ihnen bevor das eigentliche Script losgeht, einen Token, mit welchem sie den Status abfragen können. Danach schalte ich fastcgi_finish_request() und beginne den Import Vorgang:
    PHP-Code:
    # start script
    echo makeAndReturnToken();
    # stop output
    fastcgi_finish_request()
    # start import
    startImport(); 
    Systeminformationen:
    - Linux
    - PHP Version: 5.4.4-14+deb7u14
    - Nutzung von FastCGI

    Ich wäre wirklich über Rat sehr dankbar

    Ganz liebe Grüße

    CapCa


  • #2
    Nur musste ich leider feststellen, dass in der Zeit, wo ein solcher Import-Vorgang abläuft, alle anderen Anfragen blockiert werden.
    welche anfragen wo?

    Kommentar


    • #3
      Naja, dadurch, dass die anderen Seiten nicht mehr fertig laden während der Import am Laden ist, habe ich vermutet, dass alle anderen Requests (also andere Seiten, die nebenbei ablaufen sollen).
      Du kannst es dir wie folgt vorstellen:
      Der Import kann im Hintergrund ablaufen, aber gleichzeitig sollen Daten weiterhin abgerufen können. Das Problem ist aber, dass die bisherigen Seiten, wo man diese Daten abrufen kann, statt den normalen max. 1sek Ladezeit plötzlich mind. 10 Sekunden brauchen. Komischerweise sind sie immer genau dann fertig, wenn auch der Import fertig geladen hat. Daher glaube ich, dass diese Seiten blockert werden. D.h. dass meine Webseite eigtl. lahmgelegt ist, während der Import läuft. Das darf aber nicht sein :/

      Viele Grüße

      Christoph

      Kommentar


      • #4
        hm, alles sehr kryptisch.
        das ganze ist in einer xml gespeichert? auf die kannste nicht zugreifen, weil sie gelocked ist?
        butter bei die fische, bitte.

        Kommentar


        • #5
          Nein, der Importvorgang läuft wie folgt ab:
          1. Lese XML-Datei (simplexml) und schreibe die Daten in Objekte ein (kann zu Rekursion kommen, d.h. eine XML-Datei verweist auf eine andere -> große Datenmengen müssen eingelesen werden).
          2. Durch 1. wird gleich überprüft, ob Daten Vollständig sind
          3. Wenn vollständig: Schreibe Daten durch TRANSACTION in MySQL DB.

          Daher sollte es eigentlich wegen Zugriffsprobleme keine Probleme geben, da Schritt 3 max. 10 Sekunden braucht, d.h. 90 % der Zeit wird durch das Laden und Verarbeiten der XML-Daten verbraucht.

          Wenn ich während den Schritten 1-3 versuche eine andere Seite aufzurufen, braucht diese so lange, bis Schritt 3 fertig gestellt wurde (also auch während Datenbank nicht mal berührt wird, wodurch es wohl an PHP liegen muss). Und das geht natürlich nicht :-/

          Danke für die Hilfe schonmal!!

          VG

          PS: Wenn ich nochmals genauer drauf eingehen soll, bitte sagen. Die komplette Projektgeschichte würde hier nur den Rahmen sprengen.

          Kommentar


          • #6
            wieso liesst denn die nächste anfrage nicht direkt aus der db?
            bist du sicher dass der table nicht schon vorher geblocked ist?
            ich kann jetzt auch nur raten.

            Kommentar


            • #7
              Zitat von CapCa Beitrag anzeigen
              Wenn ich während den Schritten 1-3 versuche eine andere Seite aufzurufen, braucht diese so lange, bis Schritt 3 fertig gestellt wurde (also auch während Datenbank nicht mal berührt wird, wodurch es wohl an PHP liegen muss)
              Ja, hier geht das Rätselraten weiter. Was macht die "andere Seite", welche Ressourcen benötigt diese, usw...

              Mach dir eine minimale Testseite, welche nur die aktuelle Zeit ausgibt und teste, ob diese Seite auch erst nach Ablauf deiner Aktionen 1-3 erscheint.
              PHP-Klassen auf github

              Kommentar


              • #8
                Verwendest du start_session()? Das bleibt aktuell noch offen, klingt aber passend. Eine Session blockiert im Standardfall parallele Anfragen mit der gleichen SessionID um Raceconditions zu vermeiden. Bei Ajax-Requests immer wieder eine Problemquelle. Kannst du die Verarbeitung nicht wirklich im Hintergrund machen? (cron, mq)
                Standards - Best Practices - AwesomePHP - Guideline für WebApps

                Kommentar


                • #9
                  Es reicht schon, wenn der Import eine Tabelle blockiert, die in einer anderen Anfrage gelesen werden soll...
                  Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

                  Kommentar


                  • #10
                    Hey,

                    also ich habe das Problem jetzt lokalisieren können. Es liegt wohl nicht an der Session. Ich habe den Lösungsansatz mit session_write_close() auch schon probiert (siehe http://stackoverflow.com/questions/1...session-exists). Ich habe nun folgendes Script geschrieben, welches verdeutlicht, wo das Problem wohl liegen könnte.

                    Script zum Aufrufen einer langen Interaktion
                    PHP-Code:
                    echo "TEST";
                    session_write_close();
                    fastcgi_finish_request(); 
                    sleep(5); //Simulate long computation time 
                    Während das Script läuft wird z.B. folgende Seite / folgender Code aufgerufen:
                    PHP-Code:
                    echo "Hello Im working!"
                    Effekt: Ich rufe Script 1 auf und parallel dazu rufe ich Script 2 auf. Die Ausgabe "Hello Im working!" kommt aber erst, wenn die 5 Sekunden von dem sleep() abgelaufen sind.

                    Gibt es noch etwas, das ich deaktivieren könnte?

                    Dankeschön schonmal

                    VG

                    Kommentar


                    • #11
                      Mach mal dein Test ohne session_write_close() und ohne fastcgi_finish_request(). Dies

                      PHP-Code:
                      <?php
                      echo 'start test '.date('Y-m-d H:i:s').'<br>';
                      if(isset(
                      $_GET['s'])) sleep((int)$_GET['s']);
                      echo 
                      'end test '.date('Y-m-d H:i:s').'<br>';
                      einmal mit s=10 und in einen 2.Tab mit s=1 gestartet zeigt:

                      start test 2014-10-15 14:51:07
                      end test 2014-10-15 14:51:17

                      und

                      start test 2014-10-15 14:51:10
                      end test 2014-10-15 14:51:11
                      PHP-Klassen auf github

                      Kommentar


                      • #12
                        Gleicher Effekt. Liegt das nur an meinem Browser?

                        Kommentar


                        • #13
                          Welche Browser nimmst du denn?
                          Probier mal
                          http://jspit.sculptor.uberspace.de/t...odate.php?s=10

                          http://jspit.sculptor.uberspace.de/t...hodate.php?s=1
                          PHP-Klassen auf github

                          Kommentar


                          • #14
                            Anschluss an deinen geänderten Post:
                            Wert aus 1. Tab:
                            start test 2014-10-15 14:56:00
                            end test 2014-10-15 14:56:10

                            Wert aus 2. Tab:
                            start test 2014-10-15 14:56:10
                            end test 2014-10-15 14:56:12

                            Ich glaube wirklich, dass da irgendetwas blockt, aber was? :/

                            Danke vielmals schonmal

                            VG

                            Edit: Bei dir klappts: 1sek
                            start test 2014-10-15 14:58:58
                            end test 2014-10-15 14:58:59

                            start test 2014-10-15 14:58:57
                            end test 2014-10-15 14:59:07

                            Also doch der Server :-/ Hat jemand eine Idee, an was das liegen kann? Dann könnte ich meinem Webmaster Bescheid geben.

                            Edit2: Firefox

                            Kommentar


                            • #15
                              Wurde nun gelöst. Die Einstellung pm war auf static. Einstellungen, die das Problem nun gefixt haben:
                              pm = dynamic
                              pm.max_children = 20
                              pm.start_servers = 2
                              pm.min_spare_servers = 2
                              pm.max_spare_servers = 5
                              pm.max_requests = 0

                              Dankeschön an alle!!

                              VG

                              Kommentar

                              Lädt...
                              X