extrem langsame imap zugriffe

[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...

[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]

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

[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

[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]

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]

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]

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]

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]

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]

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]

wie sonst soll ich mir erklären, dass folgendes passiert:
login user1, ordner struktur baut sich ohne klicken auf email auf,
wenig mails, sowohl in inbox als auch in ordnern => schnell

login user2, ordner struktur versucht sich aufzubauen ohne klicken auf email, (NACH 50 sekunden!!)
wenig mails in inbox, VIELE in einem ordner => langsam
klickt man auf das briefsymbol geht die inbox quasi sofort auf

login user3, ordner struktur versucht sich aufzubauen ohne klicken auf email (NACH vielen minuten!!!)
VIELE mails in inbox, VIELE mails in den ordnern => extrem langsam
klickt man auf das briefsymbol, geht nach einigen minuten die inbox auf

also sehe ich das ganz sicher nicht so, dass die ordner struktur NUR aufgebaut wird und KEINE mails abgerufen werden. der imap server kriegt sobald ich einen user einlogge im ox so richtig was zu tun und die sun maschine kommt so richtig ins schwitzen wenns grad nicht nur ein user versucht... und das tut der imapd bei anderen clients (sowohl desktop clients wie thunderbird und co, also auch webclients wie horde) nicht!

und bitte nicht angegriffen fühlen, würde ich ox nicht toll finden, würde ich nicht versuchen das management der firma davon zu überzeugen, und das sieht auch gut aus, aber DAS problem ist leider ein KO kriterium

[Martin Heiland]

Wie oft soll ich noch schreiben. dass OX sich genau wie gewünscht verhält? Es wird lediglich die Ordnerstruktur und die ersten paar Mail-headers des selektierten Ordners sowie die IDs des gesamten Ordners geladen. Scheinbar (ohne bisher einen konkreten Beweis zu liefern) ist das in deiner Umgebung anders. Dies kann jedoch auch durchaus mit uwimap bzw. mbox zu tun haben.

[tsdauche]

trotz aller verbesserungen durch mailbox umstellungen wäre es sehr sehr wichtig (und auch ein K.O. Kriterium für Openxchange als groupware system ) wenn man dem webgui oder dem ox server nicht beibringen kann, die Ordner Struktur zwar zu laden aber absolut keinerlei Inhalte dieser Ordner zu holen..
also: 1. Inbox holen, 2. Ordnerstruktur anzeigen 3. Ende
ich hoffe mir kann jemand sagen wie ich Open-Xchange bzw. den Webgui dazu bringe, sonst siehts ganz schlecht aus
vielen dank schon noch einmal im voraus für alle die sich gedanken machen und mich daran teilhaben lassen!

[tsdauche]

dovecot 2 unterstützt sogar mdbox also die kombination aus mbox und maildir... (portionsweise speichern der mails, nicht in einzelnen dateien oder einer riesendatei) und ja ich werd dann wohl mal sehen wenn ich diesen kleinen oder großen test hinter mir hab ob es daran lag...
ist übrigens im linux magazin 09/10 ein schöner artikel drin... zwar leider mit postfix als beispiel, aber vom prinzip her passts ja trotzdem...