Problem mit max_executiontime bei Schleifen mit vielen Daten

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

  • Problem mit max_executiontime bei Schleifen mit vielen Daten

    Ich bin gerade dabei ein Script zu schreiben das später eventuell mal zu einem kompletten Email-Client wachsen könnte.

    Die Grundidee dabei ist mittels einem php-Script die Daten aus dem (momentan nur) pop3-Postfach zu holen und in der Datenbank zu speichern damit ich mit verschiedenen Programmen unter Linux und Windos darauf Zugriff habe in meinem Netzwerk. Dafür benutze ich unter anderem die klassen von http://www.nameko.org/.

    So, jetzt habe ich aber folgendes problem beim Synchronisieren der Emails mit dem Server:

    Wenn ich die Mails vom Server hole und dabei auch nur die Headerinformationen in der Email parse, läuft das Script gefahr bei vielen und/oder sehr großen Emails (Dateien werden direkt in der Email mitübertragen!) mit Anhängen kommt es zu einem Timeout des Scriptes wegen der maximalen Scriptlaufzeit.

    Hat jemand IRGENDEINE Idee wie ich das lösen kann ohne die Laufzeit auf unendlich zu setzen?

    Dabei hole ich momentan erst die Mails, Parse nur den Header und schreibe noch nicht in der DB vorhandene Mails auch noch gar nicht in die DB. Wenn das noch dazu kommt wird die Laufzeit sich noch mal verlängern...

  • #2
    http://de.php.net/manual/en/function.set-time-limit.php ff.
    Wenn ich die Mails vom Server hole und dabei auch nur die Headerinformationen in der Email parse, [...]
    das ist schlecht. warum dauert es denn so lange?

    Kommentar


    • #3
      Wenn Du dir anschaust wie eine Email aufgebaut ist, wirst du Festellen das ALLES in einem Block gespeichert ist und je nach Typ unterschiedlich codiert wird und in Parts aufgeteilt ist. Wenn du einen Dateianhang von 10 oder auch 200mb hast, so wird dieser direkt in der Email codiert abgelegt. Eine Mail wird "in einem Stück" versand. Anhänge in einer Email sind Parts der Email und keine wirklichen "Anhänge" wie es das Wort impliziert.

      Ergo kannst Du, auch wenn Du nur den Header der Mail auslesen willst, nur die gesamte Datenmenge der Email holen. Darum dauert es so lange. Der Parser sieht sehr gut aus. Ich selbst wüßte nich wie ich ihn schneller programmieren könnte. Immerhin hab ich die Klasse gefunden bevor ich aus Verzweiflung selbst einen geschrieben hätte.

      Eventuell gibt es eine bessere Möglichkeit die nur die Header vom Server holt, aber nachdem was ich bisher im RFC und Web gelesen habe scheint mir dem nicht so zu sein. Ich lasse mich aber eines Besseren belehren.

      --

      set_time_limit ist mir bekannt, hat aber eine Nachteile und Restriktionen. Zum Beispiel wenn mir nicht erlaubt ist sie zu ändern oder eben:

      Your webserver can have other timeouts. E.g. Apache has Timeout directive, IIS has CGI timeout function, both default to 300 seconds. See the webserver documentation for meaning of it.

      Die Zeit ins unendliche zu setzen ist keine gute Idee, in jedem Fall. Vorallem wenn theoretisch mehrere User zeitnach mehrere und/oder große Mails holen.

      Kommentar


      • #4
        Vielleicht bringt dich imap_headerinfo() in Verbindung mit imap_open() weiter
        gruss Chris

        [color=blue]Derjenige, der sagt: "Es geht nicht", soll den nicht stoeren, der's gerade tut."[/color]

        Kommentar


        • #5
          Nein.

          Damit werden große Mails auch nicht schneller vom Mailserver abgeholt und geparst. Die Größe der Emails ist das Problem, nicht das Holen direkt oder das Parsen.

          Gibt es nicht vielleicht eine Konsolenanwendung für Linux mit der ich via Chonjob die Mails gleich direkt in die Datenbank schreiben kann? Natürlich so das ich sie irgendwie einem Nutzer zuordnen kann.

          Wäre zwar nicht ganz das angestrebte flexible Ziel das man keinen Rootserver braucht aber eine Alternative. Schon alleine weil ich damit einem Haufen Problemen mit php-Umgebungseinstellungen entgehe.

          Kommentar


          • #6
            Ich bezweifel das es da eine fertige Lösung gibt.

            Eine 10-200MB Mail in eine Datenbank schreiben zu wollen ist nunmal keine Praktikable Lösung.
            gruss Chris

            [color=blue]Derjenige, der sagt: "Es geht nicht", soll den nicht stoeren, der's gerade tut."[/color]

            Kommentar


            • #7
              Die Attachments könnte man ja seperat speichern?

              Vorallem, wie macht es Scalix dann? www.scalix.com

              Ich brauche jedenfalls eine fertige Lösung oder eine Lösung für mein Problem wie ich die Mails irgendwie abspeichere und von überall in meinem Netzwerk erreichen kann, vorzugsweise mit einem guten Webmailclient der Termine, Contacts und Kalender unterstützt.

              Kommentar


              • #8
                Ergo kannst Du, auch wenn Du nur den Header der Mail auslesen willst, nur die gesamte Datenmenge der Email holen.
                nein, aber die imap_* implementierung von php in verbindung mit pop3 erzwingt das. überlege dir, ob du an dieser stelle nicht auf eine externe anwendung ausweichst, die es vielleicht besser macht, indem sie wirklich _nur_ die headers vom server lädt.
                Eventuell gibt es eine bessere Möglichkeit die nur die Header vom Server holt, aber nachdem was ich bisher im RFC und Web gelesen habe scheint mir dem nicht so zu sein.
                du verwechselst die mail-headers und die informationen über die anhänge, kann das sein?
                Gibt es nicht vielleicht eine Konsolenanwendung für Linux mit der ich via Chonjob die Mails gleich direkt in die Datenbank schreiben kann?
                keine ahnung, was das mit cronjobs zu tun hat, aber grundsätzlich: fetchmail + irgend ein client für die datenbank. was nutzst du denn?
                Eine 10-200MB Mail in eine Datenbank schreiben zu wollen ist nunmal keine Praktikable Lösung.
                kommt auf die datenbank an.

                Kommentar


                • #9
                  Ok, stimmt, wenn man direkt mit dem Sever "spricht " könnte man ja auch nur die ersten paar Lines holen die die Header ausmachen, da hab ich nicht dran gedacht.

                  Nein, ich verwechsel das nicht, beides steht aber in der Mail. Jeder Part hat seine eigenen Informationen.

                  Ehh, ja, doof ausgedrückt: Via Cronjob eben nur regelmäßig, natürlich nicht direkt mit Cronjob.

                  Wie soll das mit fetchmail funktionieren? Ich werd da nicht schlau draus und ja, ich hab schon man fetchmal gelesen... Ich benutze mySQL5.

                  Kommentar


                  • #10
                    Nein, ich verwechsel das nicht, beides steht aber in der Mail. Jeder Part hat seine eigenen Informationen.
                    aber die mail headers stehen (1) garantiert (2) immer (3) nur am anfang der mail, die information über die anhänge ist im mail body wild verteilt.

                    Wie soll das mit fetchmail funktionieren?
                    schau mal in die man pages, ich weiß es gerade auch nicht. wenn fetchmal nicht passt, schau dir andere clients an, im grunde muss man das sogar mit den mitteln des pop3 protokolls können - etwas in richtung TOP oder RETR oder soetwas...

                    was willst du denn nun in die db schreiben - nur die headers? oder die ganze email samt anhängen?

                    Kommentar


                    • #11
                      Nur die komplette (Text) Email. Die anhänge wollte ich im Dateisystem ablegen und nur in der DB die Daten dafür (Größe, Filename usw...) hinterlegen.

                      Kommentar

                      Lädt...
                      X