Portál AbcLinuxu, 25. dubna 2024 13:20
S MySQL nemám tolik praktických zkušeností (používám Firebird), ale persistentní spojení jsou obvykle problém hlavně proto, že při velkém počtu klientských instancí máte trvale otevřeno mnoho spojení s databází, což je náročné hlavně na paměť. Pokud je paměti dost, jsou ale persistentní spojení výhodnější, protože navázání spojení s databází může být často časově náročnější než vlastní dotazy. Jen musíte dávat pozor, aby spojení nebylo příliš mnoho a případně zvýšit limit na počet file deskriptorů (databázi i klientovi) pomocí ulimit -n
. V tom je jedna z výhod toho middleware, protože tam jsem si mohl vytvořit efektivní pool databázových spojení, a tak na jednu stranu nečekat pokaždé na nové spojení a na druhou nedržet extrémně mnoho spojení.
*_pconnect()
totéž co *_connect()
.
KeepAlive
má IMHO reálný smysl jen v případě, že má některý klient s keepalive spojeními problémy (a pak bych to dělal jen pro toho klienta) nebo pokud dochází k nasycení hodnoty MaxClients
(a nemůžete ji z výkonových nebo paměťových důvodů zvednout), protože pak může dlouhotrvající keepalive spojení na dlouhou dobou odblokovat další klienty.
MaxClients
). Ty failed requesty nemusejí nic znamenat, ab
považuje za failed i to, že odpověď má jinou délku než odpověď na první zkušební dotaz, takže při benchmarkování dynamických stránek se musíte dívat i na důvody těch failed requestů.
httpd
a ab
mezi sebou prát o výkon.
Tiskni Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.