extrem langsame imap zugriffe

[Martin Heiland]

Das beschriebene Verhalten kann auch durch den IMAP Server bzw. seine Storageimplementierung ausgelöst werden. Viele Mails in vielen Ordnern sind langsam. Desktopclients kann man nicht wirklich vergleichen da sie einen lokalen Storage haben und die Ordner "in Ruhe" abfragen können. Wie Horde arbeitet kann ich dir leider nicht sagen, vielleicht lassen sie sich keine Liste von IDs im derzeitigen Ordner geben oder verzichten auf sonstige Abfragen oder arbeiten nicht über IMAP.

Bisher wurde beschrieben dass der Zugriff langsam ist und die Vermutung aufgestellt dass OX alle Mails auf Vorrat abruft. Dem habe ich widersprochen da das Verhalten auch bei einem Account mit einigen hunderttausend Mails und dutzenden Ordnern nicht auftritt. Wenn es mit Dovecot mit maildir o.ä. genau so langsam ist oder die Stelle im OX Code genannt werden kann, lasse ich mich gerne vom Gegenteil überzeugen

[tsdauche]

ich habe mal für user1 und user2 nen dcpdump mitlaufen lassen...
bei user 1 kommt wie von dir genannt der aufruf module mail, list mit nem array an ids usw) und dann kommen auch genau diese emails wieder zurück... soweit ist für mich alles klar und so ist das ganze wohl auch gedacht..
bei user 2 finde ich den aufruf "list" vom module mail erst gar nicht! dafür aber diesen "newmsgs" mit nem array... diesen aufruf finde ich aber in der doku http://oxpedia.org/wiki/index.php?ti...ule_.22mail.22 gar nicht! was macht das teil?!
aus tcpdump:
{"module":"mail","action":"newmsgs","folder":"INBO X","columns":"600,6 ...

mir wäre es auch am liebsten wenn ich ne codezeile finden würde, die meinetwegen diese "falsche schleife" zum abholen sinnloser mails oder so verursacht, aber es ist unglaublich schwer mich überhaupt in den javascripten den webguis zu recht zu finden... da sind sooo viele doppelte sachen... und wie gesagt, angreifen will ich dich ganz sicher nicht! wir sind da schon auf der selben seite!

[Martin Heiland]

Klar, ich hab mich auch nicht angegriffen gefühlt. Generell sagt die GUI dem Server nur, was sie haben möchte - das Abrufen regelt der Server dann selbst. Im tcpdump taucht scheinbar nur der Request selbst auf, nicht der Pfad bzw. die URL an die es geschickt wird.

[tsdauche]

haben mittlerweile auch nen tcpdump beim imap server mitgelesen... da wird schön fleißig ein examine auf die ordner nach dem anderen gemacht

[Martin Heiland]

EXAMINE wird aufgerufen, um die Ordnerstruktur und die entsprechene Anzahl der Mails und der ungelesenen Mails zu erhalten. Das sind Abfragen auf den Ordnerstatus. E-Mail Content wird dabei keiner übertragen, siehe RFC3501 6.3.2. Mails werden über das FETCH command gelesen.

Das EXAMINE auf einen Ordner in Cyrus mit über 20k Mails passiert quasi ohne Verzögerung:

666 EXAMINE "INBOX/archive/bugzilla 2009"
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen $NotJunk $Forwarded $Junk $cl_0)
* OK [PERMANENTFLAGS ()]  
* 20709 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1265974624]  
* OK [UIDNEXT 20710]  
666 OK [READ-ONLY] Completed

Scheinbar ist die Datenhaltung von UWIMAP nicht ganz unschuldig daran wenn es langsam wird:

"The reason for this difference is that UW IMAP uses the original, 'flat' mailbox format where all the mail is kept in one large file. It has to (or, at least, does) scan through that file for each SELECT and EXAMINE, which is intrinsically slow." Quelle

Das Performanceproblem über das wir hier sprechen wird dort ausgiebig analysiert, mit einem Hinweis das zeitgemäße IMAP Server die gleiche Aufgabe wesentlich schneller bewältigen. Es handelt sich um ein konzeptionelles Problem im UWIMAP. OX kommt zwar mit UWIMAP klar, UWIMAP aber nicht unbedingt mit den Anforderungen einer modernen Webapplikation.

[tsdauche]

ja da sind wir uns auch auf jeden fall einig dass der uw imap nicht mehr den ansprüchen morderner applikationen genügt, aber der it-admin is da eben manchmal "altmodisch"
ein neues mailbox format wird auch grad diskutiert und ist auf der to-do liste...
mit den tests für OX sind wir nur eigentlich so gut wie fertig, und naja wollten es jetzt dem management zum testen geben, aber genau die haben natürlich die größten mail boxen => wir sollten es ihnen noch nicht geben, sonst gibts ein NEIN
aber solange das groupware thema nicht abgeschlossen ist, steht das mailserver problem hinten an... wir sehen also einen bösen teufelskreis... naja..

was examine usw. tun ist uns durchaus klar und naja es heitß ja auf jeden fall dass der mail server JEDEN ordner bzw. jede mailbox komplett durchsucht, was natürlich gehörig i/o last verursacht... nicht besonders nett
am schönsten wäre es eben wenn der ox einfach nur die ".mailboxlist" vom imap abholen würde, und die inbox abrufen würde, und dann einfach die klappe halten würde, und wenn man das hinkriegen würde, wäre alles gut...
ich wünsche jetzt auf jeden fall ein schönes wochenende und ich hoffe wir "schreiben" uns dann bald wieder wenn wir den kopf etwas abgekühlt haben
beste grüße!

[Martin Heiland]

Ein EXAMINE verursacht auf einem aktuellen IMAP Server keinerlei i/o Last, da er nicht über die komplette mbox-datei heizen muss um gelesen/ungelesen abzufragen. Diese Daten werden in einem Index gespeichert. OX kann leider keine Dateien "separat" vom Server abholen sondern nutzt das IMAP Protokoll für den Zugriff.

Ich kann die Intention und das Problem durchaus nachvollziehen, aber bin mir relativ sicher, dass wir keine Sonderbehandlung für UW einbauen werden, der Server ist kaum noch relevant. Würde es fürs Management nicht reichen, diese Problematik zusammenzufassen und die Evaluierung eines neuen IMAPd zu forcieren? Um die Lösung "abnehmen" zu lassen, ist vielleicht auch ein proof-of-concept mit OX vor und Dovecot dahinter ausreichend?

Dir auch ein schönes Wochenende

[tsdauche]

examine verursacht sehr wohl extrem hone i/o last, wenn man mit dem mbox format arbeitet, weil er eben die gesamte mbox datei komplett durchsuchen MUSS - es gibt ja nix anderes...
bei der inbox lässt sich das ja nicht verhindern, aber die anderen "ordner" braucht er ja erstmal nicht für den initalen zugriff, da reicht ja die ordner struktur die er vom imap server kriegt und ein examine ist erst dann nötig wenn man den ordner anklickt!
dass ox natürlich nur das imap protokoll verwenden kann ist klar...

ich rede ja auch nciht von einer sonder behandlung für den sch... uw server, sondern davon ganz einfach das initiale examine auf die inbox zu beschränken - das kann durchaus auch für andere mail server relevant sein.
und die umstellug auf das neue dbox format wird gerade natürlcih auch geprüft, aber es wäre schön vorher die baustelle ox auch mit dem alten setup beenden zu können bevor wir die mega baustelle dovecot öffnen, da es sich da nicht nur um EINEN mailserver sondern um eine mehrzahl davon handelt, und viele andere prozesse geprüft werden müssen ob sie mit dem neuen mailserver zusammenarbeiten - besonders mit dem neuen format...

es wäre also das beste wenn wir wüssten WO geregelt ist im source was alles passiert nach dem klick auf "email" im webgui damit man diesen vorgang vielleicht ein bisschen beeinflussen kann und das kann ja wirklcih auf für andere interessant sein
also dann einen guten, trotz der eiseskälte, start in die woche

[tsdauche]

hallo lencoo, schön dass du mit liest, aber da hast du wohl das zeug vorher ein bisschen wenig gelesen, weil genau das alles schon gesagt wurde
ja mbox format, natürlich manuell konfigurierter mailserver, bzw. viele davon

ich brauch doch nix weiter als ne option die sagt "hey fass die subfolder nicht an" oder zumindest die codezeilen in denen das aufgerufen wird ums raus zu werfen

[Martin Heiland]

Sorry, lencoo war nur nen spammer der uns seine Filme andrehen wollte
Mir ist kein aktueller IMAPd bekannt der mbox als Standard nutzt, die nehmen alle Maildir. Ich denke eine solche Option gibt es im OX nicht, da wir explizit die Anzahl der gelesenen Mails in der Ordnern anzeigen wollen/müssen. OX hat viele Schalter, aber so viele dann doch nicht

Gruß

[tsdauche]

naja beider anfrage "action=list&all=1&columns=..." die diesen großen aufwand auf dem imap server betreibt werden natürlich in den columns die felder festgelegt, die abgefragt werden. dabei handelt es sich um eine voher fest definierte liste...
naja dann ist klar, dass meine intention erstmal war/ist diese liste zu verändern, eben die 311 (unread) raus zu werfen, da sie aus meiner sicht die einzige anfrage ist, die das file "aufmachen" (mindestens examine) muss...
wenn ich die 311 aber einfach rauswerfe tut sich erstmal gar nicht mehr, weil natürlich die funktion auf der anderen seite die reihenfolge der anfrage kennt und braucht... daher wird mein nächster versuch sein, diese liste einfach mal so zu verändern, dass er nix davon merkt... also meinetwegen die 311 durch noch eine 302 zu ersetzen... mal schauen was er dann treibt... wahrscheinlich zeigt er dann einfach an, dass IMMER 2 ungelesene nachrichten drin sind... nicht schön, aber nen test wert obs schneller geht...