Awesome! It seems it's really something related with SSL handshakes, We open 80 port without https and let cdn connect to our 80 port, everything seems fine. I'll update this thread laters.
On Tue, Apr 25, 2017 at 5:23 PM, Willy Tarreau <w...@1wt.eu> wrote: > On Tue, Apr 25, 2017 at 05:00:48PM +0800, jaseywang wrote: > > Here is the data with debug mode off, still the same issue: > > https://www.dropbox.com/s/4x0cjfv1o2kmwg3/analytics-debug-off.txt?dl=0 > > > > > > Flat profile: > > > > Each sample counts as 0.01 seconds. > > no time accumulated > > > > % cumulative self self total > > time seconds seconds calls Ts/call Ts/call name > > 0.00 0.00 0.00 264321 0.00 0.00 hdr_idx_add > > 0.00 0.00 0.00 189187 0.00 0.00 strlcpy2 > > 0.00 0.00 0.00 155794 0.00 0.00 ultoa_o > > 0.00 0.00 0.00 144666 0.00 0.00 ltoa_o > > 0.00 0.00 0.00 122408 0.00 0.00 http_find_header2 > > 0.00 0.00 0.00 83596 0.00 0.00 fd_update_cache > > 0.00 0.00 0.00 83336 0.00 0.00 http_sync_req_state > > 0.00 0.00 0.00 78736 0.00 0.00 eb_delete > > 0.00 0.00 0.00 78198 0.00 0.00 eb32_insert > > 0.00 0.00 0.00 78043 0.00 0.00 > conn_update_data_polling > > 0.00 0.00 0.00 67163 0.00 0.00 conn_fd_handler > > 0.00 0.00 0.00 66824 0.00 0.00 vars_init > > 0.00 0.00 0.00 66768 0.00 0.00 utoa_pad > > 0.00 0.00 0.00 61080 0.00 0.00 http_resync_states > > 0.00 0.00 0.00 61080 0.00 0.00 http_sync_res_state > (...) > > For me this shows a perfectly healthy load balancer experiencing a very > low load. There's even no connection retries, everything looks OK. I'm > speechless. > > Given that no time was reported in any function, it could be possible > that all the time is spent in SSL handshakes but I'm even having doubts > on this now. > > Do you see some CPU usage on the machine during the test ? Is the CPU > where haproxy runs saturated ? > > The next step will probably require strace to see where the time is wasted. > You can run it like this : > > strace -Tttvs200 -o strace.log -p $(pidof haproxy) > > It will reveal the time spent in each syscall and between them. We may find > that a full millisecond is lost somewhere, helping to narrow the problem > down. > > Willy >
