Bug #925
closedWarden-client: konfigurovatelný timeout spojení
0%
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 datna "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
Updated by Jan Soukal over 11 years ago
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
Updated by Pavel Kácha over 11 years ago
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?
Updated by Jan Soukal over 11 years ago
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
Updated by Jan Soukal over 11 years ago
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.
Updated by Jan Soukal over 11 years ago
Jan Soukal wrote:
TODO:
- doplnit CONNECTION_TIMEOUT do readme
- zanést do changelogu
Hotovo v revizi 566390fd
Updated by Pavel Kácha over 11 years ago
- 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.