Rychly mail client alebo linux nie je pomaly

[Peter Surda]

On Sun, 22 May 2005 11:03:57 +0000 (UTC) Matus UHLAR - fantomas
<uhlar na fantomas.sk> wrote:

>Peter Surda <shurdeek na routehat.org> wrote:
>> Vsetky skusane webmaily boli take pomale preto, ze pri kazdom kliku
>> komplet loadovali cely folder, sortovali ho atd. Na toto dovod nie je,
>> mozes si to cachovat a cez imap transferovat len msgid (tak to robia
>> "poriadne" clienty).
>co je z principu na webmailoch dost tazko implementovatelne.
Ocividne to neplati, lebo mne sa to implementovat podarilo. Sice bez imapu, ale
ako som povedal nevidim v tom principialny problem, len by sa mi to tazsie
programovalo (perl vs. C). A este mam rezervy.

>kedze kazdy http request znamena nove vyvolanie skriptu.
Nie je pravda. Ja pouzivam FastCGI a tam sa to nedeje (napriek tomu este stale
data session necachujem, takze potencialy na zrychlenie nie su vycerpane).
Pomoze mi ale, ze sa nemusi pri kazdom kliku parsovat perlovy skript, robit
spojenie na databazu a dalsie veci, ktore overene maju nezanedbatelny vplyv na
vykon.

BTW FastCGI mozem ozaj odporucat do situacii kde forkovanie vadi. Upravit na
skripte treba minimum (pridal som jeden cyklus).

>Toz, bezstavovost HTTP ma svoju cenu
Ani "bezstavovost" nie je nevyhnutnou podmienkou webmailu. Co ti brani prepojit
session id a nejaky adresar s cache? Staci ked si zoberes perlovsky modul CGI
resp. CGI::Fast, tie implementuju stavovost. Ako som vsak povedal, ja to este
stale nerobim a napriek tomu som to enormne zrychlil.

>a pouzitie HTTP na webmaily nie je bohvieaky napad.
Preco? Je to univerzalne pouzitelne a ako sa mi podarilo demonstrovat, da sa to
naprogramovat aj efektivne.

>je tu niekolko principialnych dovodov aby to bolo dost pomalsie ako praca s
>obycajnym mail klientom.
Nie je. Kvoli zavislosti na HTTP(S) to moze byt trocha pomalsie, nie vsak
"dost". Ti, co sa ohanaju "principialnymi dovodmi" mozno len nevedia programovat
:-).

S pozdravom,
Peter