On 20 Aug 2001 19:52:51 +0300, Mihai RUSU wrote:
>
> IMHO cerintele de la un proxy sunt destul de putine cat sa apara si sa se
> mentina o concurenta numeroasa
Hmmm...
> 1. ei zic ca un avantaj ar fi stabilitatea. IMHO asta ramane de vazut
Corect.
> 2. altul ar fi modul de stocare al cache-ul. asta e discutabil deoarece
> cu FS-uri gen ReiserFS kicks ass la orice alte alternative de a folosi
> putine fisiere mari, adica in loc sa cauti in fisierul mare folosind
> hash-urile si structura ta cauta reiserfs-ul in hashurile si structura
> lui...
Heh, exact la asta m-am gindit si eu cind am vazut documentatia.
> 3. ca are cate un proces per request... hmmm din cate stiu eu si orice
> programator imi poate confirma solutia cu IO ASYNC si single process
> pentru un server este cea mai rapida/scalabila la incarcari mari. daca
Cica este un thread per request, ceea ce e cu totul altceva.
Dar nici mie nu-mi place. Mai bine-l fac cum e TUX: unul-doua thread-uri
per procesor. ;-) Da, TUX e kernel-level, dar oricum ideea pare extrem
de rezonabila.
Chadd zicea ca, in posibila versiune viitoare de Squid, or sa aiba mai
multe procese, cu un fel de frontend pentru chestii ca accounting, etc.
Nu rezulta prea clar, dar mi s-a parut ca voia sa spuna "un numar fix de
procese". Probabil ceva similar cu TUX, nu stiu...
Asta suna mult mai bine, si oricum in directia asta deja au inceput sa
sape cu 2.4 (diskd). Sa zicem, cite un proces-proxy (squid) per
procesor, plus cite un proces-cache (diskd) per partitie de cache, plus
frontend-ul ala... Suna foarte bine.
> singurul "potential" avantaj se va dovedi schema modulara care o vor
> aborda (stil apache/proftpd/php)
Right.
--
Florin Andrei
---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
unsubscribe from this list.
