Bug #925
closed
Warden-client: konfigurovatelný timeout spojení
Added by Pavel Kácha over 11 years ago.
Updated over 11 years ago.
Description
zaznamenal jsem problemy pri prijmu zprav typu portscan.
mam pocit ze pri realnem pouziti je novy mechanismus batchovani
na serveru prilis narocny pro fronty ve kterych je mnoho dat
http://pastebin.com/9yVAKAhK
na "vine" je podle mene nove nastaveni timeout nad soap klientem. zkousel sem
pouzit ruzne hodnoty, obcas sem dostal timeout i na 180, takze sem si tam zatim
namastil 600 ...
problem ve starem klientovi nebyl, protoze tam se zadny timeout nikde
nenastavoval a knihovna poslusne cekala ...
navrhy:
- rozsirit testy, ktere by toto dokazaly odhalit
- udelat tuto moznost konfigurovatelnou
(nicmene 10s je podle mne tak ci tak pomerne optimisticke nastaveni)
- otazka jestli by se to spise nemelo resit zmenout velikosti prijimaciho
bufferu (6000 vs 100)
RB
Přidal jsem konfigurovatelnou položku CONNECTION_TIMEOUT do konfiguráku (revize a508bf2f). Defaultně je nastavena na hodnotu 60 sekund. Myslím, že delší okno je zbytečné a přiklonil bych se k Bodíkovi v tom, že pak už je to spíš otázka velikosti přijímajícího bufferu.
TODO:
- doplnit CONNECTION_TIMEOUT do readme
- doplnit do instalátoru a updatu (generování warden-client.conf)
- zanést do changelogu
Jan Soukal wrote:
Přidal jsem konfigurovatelnou položku CONNECTION_TIMEOUT do konfiguráku (revize a508bf2f). Defaultně je nastavena na hodnotu 60 sekund. Myslím, že delší okno je zbytečné a přiklonil bych se k Bodíkovi v tom, že pak už je to spíš otázka velikosti přijímajícího bufferu.
Souhlas. Jak tedy navrhuješ změnit default MAX_RCV_EVENTS_LIMIT?
Jan Soukal wrote:
TODO:
- doplnit do instalátoru a updatu (generování warden-client.conf)
Doplněno do install.sh a update.sh v revizi a506b12f
Pavel Kácha wrote:
Jan Soukal wrote:
Přidal jsem konfigurovatelnou položku CONNECTION_TIMEOUT do konfiguráku (revize a508bf2f). Defaultně je nastavena na hodnotu 60 sekund. Myslím, že delší okno je zbytečné a přiklonil bych se k Bodíkovi v tom, že pak už je to spíš otázka velikosti přijímajícího bufferu.
Souhlas. Jak tedy navrhuješ změnit default MAX_RCV_EVENTS_LIMIT?
Při testování hodnoty 6000 událostí v jedné dávce jsem s tím problémy neměl. A nikdo další kromě Bodíka nic nereportoval, takže těžko říct (je ovšem otázka, kolik lidí reálně testuje). Osobně bych to zatím nechal tak, jak to je. Uživatel si, pokud s tím bude mít problémy, může libovolně dle uvážení a svých možností hýbat s oknem a/nebo s velikostí bufferu. Do budoucna by z toho mohla vyplynout nějaká nová implicitní hodnota pro MAX_RCV_EVENTS_LIMIT, ale takto od pasu si ji nastřelit netroufám.
Jan Soukal wrote:
TODO:
- doplnit CONNECTION_TIMEOUT do readme
- zanést do changelogu
Hotovo v revizi 566390fd
- Status changed from New to Feedback
- Status changed from Feedback to Closed
Mám okno nastavené na 10000 a trvá to od 25 do 45 vteřin, ale jsem na stejném segmentu, jako je Warden. Drtivá většina pravidelných dotazů se teď vejde cca do 2000, zbytek budou hromadní stahovači. Ok, 6000/60 should be enough for everybody.
Also available in: Atom
PDF