Hi,
CSS used as web services loadbalancing, go alive to operation, and work smoothly.
few days ago doing test for CSS performance and response time.
the front end test client IP 10.76.152.37 same subnet with CSS VIP 10.76.152.241, and backend real web servers (10.76.152.5~29).
and the CSS loadbalance default "roundrobin".
from client do web service test.
first, client to L4 Load Balance target VIP (10.76.152.241) , and flow dispatch to real web server.
second, client directly To access single real web01 (10.76.152.5), flow bypass L4 VIP.
Both run 10,50,100 connections test
method: run /home/www/_util/script/strain_L4.pl $connection
used wget background，and enable debug，query homepage index.phtml，and report to /tmp/strain_L4
result:
1. when connection count "10" ，L4 Load Balance average response 0.8 sec.; directly access web01 response time 1.5 sec.
2. when connection count "50" ，L4 Load Balance average response time 0.4 ~ 21.5 sec.; directly access web01 response 4.5 +-3 sec.
3. when connection count "100", L4 Load Balance average response time from 0.5 ~ to timeout (shown html tag，no timer ticket) ; directly access web01 response time 5.5 +- 3sec ，no timeout.
note: when timeout , server /var/log/httpd/error_log.1 has error message " PHP Fatal erro : pdo_oci_handle_factory: ORA-12535" on these servers log file.
Compare with client directly access real server (bypass CSS), there is no "timeout" and reponse more guickly.
Based on this result, when test 100 connections, there is large amount connection need L4 VIP service in short term, flow has "timeout" happened, and response time is more longer. And caused server report error "PHP Fatal erro : pdo_oci_handle_factory: ORA-12535".
it seems quite not reasonable for CSS loadbalance performance and response time, but how to explain ?
Please help to verify and any solution to improve.
Thank you.
Jason
