optimalizace IMAP serveru (diskuse)

[D-Evil]

Jsem v tomhle teda celkem amatér, ale zdá se mi neefektivní otvírat např. 200 MB soubor a hledat v něm třeba jen pár kilobajtů, v tomhle by asi maildir moh pomoct, soubory jsou indexovaný, takže se mi zdá, že zátěž by měla bejt menší.

Taky se mi zdá neefektivní při velkym počtu spojení používat xinetd - jestli se nepletu, při každym požadavku se pal spouští program, kterej ho obslouží. To je další zátěž pro disk a další zpomalení. Démon by asi svojí práci odvedl líp.

[Mobidick]

Souhlasim s tim,ze prechod na Maildir pomuze,resil jsem stejny problem a jako jedno z opatreni to znacne zvedlo pruchodnost imapu.

[..]

Kamarad google na dotaz co vi o imap proxy; odpovedel webem http://www.imapproxy.org kde lze najit - cituji :

What is the imapproxy?

The name says almost all you need to know. It proxies IMAP transactions between an IMAP client and an IMAP server. The general idea is that the client should never know that it's not talking to the real IMAP server.

Snad by Vam to mohlo pomoci, pri (velmi) zbeznem pohledu je to presne to co potrebujete.

[Dunric]

Podobný problém jsem asi před 2 lety řešil taktéž s UW-IMAPem a slabinou byl právě defaultně používaný formát mbox. Kupodivu stačilo nastavit způsob uložení do formátu mbx a nároky na zdroje serveru se prudce snížily a rovněž odezva pro klienty je znatelně lepší. IMAP lze překompilovat, aby používal MBX právě jako výchozí. Na bezproblémový převod schránek mbox -> mbx dobře poslouží nástroje z imap-utils, konkrétně mailutil.

[lenox]

Pripojuji se ke kritice formatu mbox...prechod na maildir vyrazne ulechci serveru.

Nasledne bych uvazoval o imapproxy ci dbmail

[Roman DAVID]

taky jsem se podobnou otazkou asi pred mesicem zabyval. Puvodne jsem mel umysl prejit na maildir, ale pak jsem si precetl o mbx a nevypada spatne (az na par nevyhod, ktere jsou uvedeny ve FAQ).

Co se tyka vykonu, kouknete na: http://www.decisionsoft.com/pdw/mailbench.html

Taky doporucuji ke cteni: http://www.washington.edu/imap/documentation/formats.txt.html (zejmena posledni cast, kde se pojednava o nevyhodach maildiru)

[Marek]

Můj názor je jednoznačně přechod na "maildir", "mbox" je silně neproduktivní ... otevírat X-set MByte pro čtení pár kByte ... to je přece nelogické, toť můj pohled.

Sám jsem to řešil a "maildir" problém vyřešil, uživatelé spokojeni a převod proběhl nějakou utilitkou mboxtomdir, nebo tak nějak.

[Heron]

Hmm v mail klientu (KMail) mám přes 300 000 mailů (rozdelené do cca 50složek) - maildir jsem zkusil, ale FS (ext3) to psychicky nezvládal, zvlášť při zálohování jsem měl pocit, že ta disková hlavička musí upadnout.

[Jan Kundrát (jkt)]

Jenom tak FMI, nejmenuje se nahodou onen server "sosna"? :)

[krnoha]

Když to víš tak proč se ptáš?

[Jan Kundrát (jkt)]

Protoze jsem to nevedel. Kdyz bych si byl jisty, tak bych se neptal :).

[Jan Kundrát (jkt)]

Take je dobre zminit, ze cast uzivatelu ma svuj $HOME (resp. mailboxy z nej) umisten na jinem stroji a pristupuje se k nemu pres NFS. Muze to nejak ovlivnit vykon?

Drobna poznamka - muj osobni a nicim nepodlozeny nazor je to, ze by zlepseni odezvy pomohlo i to, aby se Maple poustel nekde jinde a ne na onom serveru. Jiste, je to SMP stroj, ale stejne...

Dalsi poznamka - nekdy pred cca. rokem jsem se snazil prinutit pine spolupracovat s maildirem a pokud si dobre pamatuju, tehdy to "oficialni" verze jeste neumela.

A konecne posledni poznamka - celkem zajimave mi pripada pristupovani na IMAP pres SSH tunel. Uzivatel nepouziva standardni TCP/SSL, ale pres SSH si "sam" pusti IMAP demona. Zrejme to pouziva naprosto minimalni pocet lidi, ale je to vcelku zajimava myslenka - umoznuje pouzivat SSH klice etc. Bylo by dobre, aby tahle moznost zustala zachovana (resp. na onom serveru jsem ji jeste nezkousel, takze vlastne nevim, jestli funguje).

[krnoha]

Napřed děkuji za tip na imapproxy.org , tohle jsem myslím přesně potřeboval. Jinak podle mnoha názorů by nám pomohl jiný formát poštovních souborů. Každý jiný než klasický mbox bude lepší. Začneme si nějak hrát s formátem mbx. maildir se radši vyhneme, protože statisíce souborů každého ze stovek uživatelů, s tím by se docela špatně manipulovalo.

Začneme tou proxy. Jo a taky od xinetd přejdeme k démonovi. I když na tom vlastně nezáleží.