On 22 Mar 2001 08:04:35 +0200, Mihai RUSU wrote:
>
> man io am pus pe un squid ce era proxy transparent cu 4000 de conexiuni
> online in orele de varf si nu prea am avut probleme de viteza nici cu
Cite requesturi pe secunda primea squid-ul ala?
Ce hardware era pe masina aia? (procesor, memorie)
> djbdns nici cu bind.
> o singura problema:
> daca pui un squid (io lucram cu 2.3STABLE4) sa faca resolving direct
> dintr-un djbdns si are incarcare relativ mare (1000 conexiuni la un moment
> dat)
Cite request-uri pe secunda inseamna asta?
Nu ma intereseaza cite conexiuni sint deschise la un moment dat. O
metrica mai buna pentru un cache este numarul de request-uri pe secunda.
Numarul de conexiuni deschise la un moment dat e o metrica ce combina de
fapt doua fenomene diferite: numarul de cereri pe secunda, si viteza
retelei pe upstream.
> vei avea foarte multe mesaje in cache.log de eroare de genul
> idns: queue... o kestie ciudata rau si dupa un timp nu prea random
> squid-ul crapa cu un mesaj de eroare (.... Assertion failed). M-am uitat
Da, asta e. Bug #110.
2001/03/20 13:29:44| dnsSubmit: queue overload, rejecting
adimages.go.com
2001/03/20 13:29:44| assertion failed: cbdata.c:184: "c != NULL"
E din cauza de cod stupid in dns.c: e o conditie la care, in caz de
succes se executa ramura de succes, dar in caz de failure se executa
atit ramura de failure cit si o bucata din ramura de succes.
E suficient sa pui un return imediat inainte de sfirsitul if-ului
(astfel incit functia sa returneze imediat dupa executia ramurii de
failure).
Duane Wessels are aceeasi parere (corectia la bug #110 pe squid-bugzilla
pentru squid-2.4 face exact asta ce ti-am zis).
> in surse acolo unde era assert-ul cu pricina si este tot de la DNS. se
> pare ca baietii de la squid folosesc o kestie nu prea rfc compliant care
> este in bind dar nu in djbdns (DJB=RFC bot :) ).
Bug #110 (daca asta e cauza) nu e din cauza de non-compliance, e din
cauza de coada de cereri DNS care nu se opreste din umplere atunci cind
trebuie. Iar cind coada e prea plina... BANG!!!
Oricum, fenomenul apare doar cind se combina doua conditii:
- foarte multe cereri pe secunda de la clienti
- servere DNS lente
> dupa ce am pus squid-ul
> sa ia DNS-ul dintr-un bind (8) a mers perfect. totusi ca sa reduc
> incarcare pentru DNS am rulat dnsserver-ele squid-ului (cam 16 sau 32 de
> procese) care s-au descurcat de minune.
Uite, m-am gindit si eu la asta, si nu prea mi-e clar. Oare intr-adevar
daca folosesti dnsserver se reduce incarcarea pe serverele DNS?
Eu as zice ca nu. Daca folosesti dnsserver-ele, de fapt squid foloseste
resolverul masinii pe care ruleaza, adica paseaza cererile dns la
masina, care se uita in resolv.conf si intreaba serverele DNS pe care le
gaseste acolo. Deci tot la serverele DNS ajungi, cu singura deosebire ca
in cazul cu dnsserver-e se mai tine cont si de search path din
resolv.conf (nu squid tine cont, ci masina tine cont), pe cind squid
fara dnsserver-e intreaba direct serverele DNS fara sa mai tina cont de
search path, deci s-ar putea sa fie chiar mai rapid *fara* dnsserver-e
(ceea ce ar fi conform si cu documentatia squid, care zice ca
dnsserver-ele sint "deprecated" incepind cu squid-2.3).
Gresesc?
P.S.: Pentru cei care considera terminologia folosita aici stupida (si
pe buna dreptate):
- dnsserver este o mica aplicatie folosita de squid pentru a prelua
sarcina rezolvarii directe si inverse; fara dnsserver-e, squid face
rezolvarile in bucla principala
- prin "servere DNS" am vrut sa ma refer la masinile de pe domeniul
respectiv care ruleaza bind sau djbdns
--
Florin Andrei
---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
unsubscribe from this list.
