Problem mit max_executiontime bei Schleifen mit vielen Daten

**penizillin** · 20.12.2006, 03:47

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?

**burzum** · 20.12.2006, 03:55

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.

**hhcm** · 20.12.2006, 08:41

Vielleicht bringt dich imap_headerinfo() in Verbindung mit imap_open() weiter

**burzum** · 20.12.2006, 11:47

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.

**hhcm** · 20.12.2006, 12:10

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.

**burzum** · 20.12.2006, 12:31

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.

**penizillin** · 21.12.2006, 06:23

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.

**burzum** · 22.12.2006, 03:26

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.

**penizillin** · 23.12.2006, 15:06

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?

**burzum** · 15.01.2007, 11:39

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.

Problem mit max_executiontime bei Schleifen mit vielen Daten