Sziasztok, tanacsot szeretnek kerni, mi lehet az oka a kovetkezo jelensegnek. A tesztkornyezetrol: egy nagyobb latogatottsagu webszerver elott ul egy zorp, HttpProxyURIFilter -en keresztul szaladnak a keresek. - Ha nem a zorpon keresztul szolitom meg a gepet (iptables portforwarddal a tuzfalon megkerulve a zorpot), akkor a mogottes httpd szepen leforkol 200 folotti szalat, es amennyivek a webszerver birja, kiszolgalja a kereseket (nehany masodperces timeoutra van allitva, hamar kiszorja a ne'ma keepalive-olokat); - Ha a zorpon keresztul mennek ugyanezek a keresek, ~120 szalnal tobbet nem nagyon tudtam produkalni, ugyanannyi ke're'ssza'm mellett, a letoltesek lassabban szolgalodnak ki es tobb ter vissza hibaval. Az erintett zorp instance a terheles alatt maximum 30%-os processzorhasznalatig maszott fel, a load 0.5 alatt maradt vegig, a tuzfal ugy tunt "unatkozik". Hatarerteket keresve a referenciakonyvben es a Http.py-ban utananeztem, elvileg a max_keepalive_requests, es a request_count is unlimited default, ezen nem is valtoztattam. Van valamilyen belso limit a zorpban, ami "leszabalyoz", mint valami fordulatszam alapu tiltas a motoroknal? :) Vagy megprobalja osszefuzni a beeso kereseket es egy mar meglevo keepalive-os szalon betolja kovetkezo keresnek? Mi lehet ennek a jelensegnek az oka? A tuzfalgep latszolag birna tobbet, de sajnos a zorp lassitja a szolgaltatast. Kozvetlen kapcsolatnal lenyegesen jobb teljesitmennyel erheto el a webszerver. - Ez nem meglepo, az viszont igen, hogy - szerintem - indokolatlanul nagy a lassulas, foleg a tuzfal latszolagos terheletlensegehez kepest. Nagyon koszonom a segitseget, udv, K!