from what I can guess, TS' read-while-writer is a connection-collapsing
like implement. TS have a http_tunnel that will make use of the same
data for different output, maybe that is the magic point, right?
After talk with Leif, I have the following config setup:
CONFIG proxy.config.cache.enable_read_while_writer INT 1
CONFIG proxy.config.http.background_fill_completed_threshold FLOAT
0.000000
CONFIG proxy.config.cache.max_doc_size INT 0
when I testing the read_while_writer, to a 160MB tgz file using wget,
it looks just not work, I have debug setup to .*:
first request:
> [Jan 28 13:34:58.563] Server {1119885632} DEBUG: (http) [7] State Transition:
> ORIGIN_SERVER_OPEN -> SERVER_READ
> [Jan 28 13:34:58.563] Server {1119885632} DEBUG: (http_redirect)
> [HttpSM::do_redirect]
> [Jan 28 13:34:58.563] Server {1119885632} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Jan 28 13:34:58.563] Server {1119885632} DEBUG: (http_tunnel) [7] adding
> producer 'http server'
> [Jan 28 13:34:58.563] Server {1119885632} DEBUG: (http_tunnel) [7] adding
> consumer 'user agent'
> [Jan 28 13:34:58.563] Server {1119885632} DEBUG: (http) [7]
> perform_cache_write_action CACHE_DO_WRITE
> [Jan 28 13:34:58.563] Server {1119885632} DEBUG: (http_tunnel) [7] adding
> consumer 'cache write'
> [Jan 28 13:34:58.563] Server {1119885632} DEBUG: (http_tunnel) tunnel_run
> started, p_arg is NULL
> [Jan 28 13:34:58.563] Server {1119885632} DEBUG: (http_tunnel) [7]
> producer_handler [http server VC_EVENT_READ_READY]
> [Jan 28 13:34:58.563] Server {1119885632} DEBUG: (http_redirect)
> [HttpTunnel::producer_handler] enable_redirection: 0 event: 100
> [Jan 28 13:34:58.568] Server {1138833728} DEBUG: (udpnet-service) Advancing
> by (1 slots): behind by -40938 ms
> [Jan 28 13:34:58.570] Server {1084062016} DEBUG: (http_tunnel) [7]
> consumer_handler [user agent VC_EVENT_WRITE_READY]
> [Jan 28 13:34:58.570] Server {1084062016} DEBUG: (http_tunnel) [7]
> consumer_handler [user agent VC_EVENT_WRITE_READY]
> [Jan 28 13:34:58.575] Server {1092098368} DEBUG: (http_tunnel) [7]
> consumer_handler [cache write VC_EVENT_WRITE_READY]
while the second request:
> [Jan 28 13:35:15.133] Server {1123043648} DEBUG: (http) [10] State
> Transition: ORIGIN_SERVER_OPEN -> SERVER_READ
> [Jan 28 13:35:15.133] Server {1123043648} DEBUG: (http_redirect)
> [HttpSM::do_redirect]
> [Jan 28 13:35:15.133] Server {1123043648} DEBUG: (http_redirect)
> [HttpTunnel::deallocate_postdata_copy_buffers]
> [Jan 28 13:35:15.133] Server {1123043648} DEBUG: (http_tunnel) [10] adding
> producer 'http server'
> [Jan 28 13:35:15.133] Server {1123043648} DEBUG: (http_tunnel) [10] adding
> consumer 'user agent'
> [Jan 28 13:35:15.133] Server {1123043648} DEBUG: (http) [10]
> perform_cache_write_action CACHE_DO_NO_ACTION
> [Jan 28 13:35:15.133] Server {1123043648} DEBUG: (http_tunnel) tunnel_run
> started, p_arg is NULL
> [Jan 28 13:35:15.133] Server {1123043648} DEBUG: (http_tunnel) [10]
> producer_handler [http server VC_EVENT_READ_READY]
> [Jan 28 13:35:15.133] Server {1123043648} DEBUG: (http_redirect)
> [HttpTunnel::producer_handler] enable_redirection: 0 event: 100
> [Jan 28 13:35:15.140] Server {1110411584} DEBUG: (http_tunnel) [10]
> consumer_handler [user agent VC_EVENT_WRITE_READY]
> [Jan 28 13:35:15.140] Server {1110411584} DEBUG: (http_tunnel) [10]
> consumer_handler [user agent VC_EVENT_WRITE_READY]
> [Jan 28 13:35:15.149] Server {1138833728} DEBUG: (udpnet-service) Advancing
> by (1 slots): behind by -40938 ms
> [Jan 28 13:35:15.165] Server {1129359680} DEBUG: (iocore_net) read_from_net,
> read finished - signal done
> [Jan 28 13:35:15.165] Server {1129359680} DEBUG: (iocore_net) read_from_net,
> read finished - signal done
> [Jan 28 13:35:15.169] Server {1138833728} DEBUG: (udpnet-service) Advancing
> by (1 slots): behind by -40938 ms
> [Jan 28 13:35:15.170] Server {1123043648} DEBUG: (http_tunnel) [10]
> producer_handler [http server VC_EVENT_READ_READY]
> [Jan 28 13:35:15.170] Server {1123043648} DEBUG: (http_redirect)
> [HttpTunnel::producer_handler] enable_redirection: 0 event: 100
> [Jan 28 13:35:15.170] Server {1123043648} DEBUG: (http_tunnel) [10]
> producer_handler [http server VC_EVENT_READ_READY]
> [Jan 28 13:35:15.170] Server {1123043648} DEBUG: (http_redirect)
> [HttpTunnel::producer_handler] enable_redirection: 0 event: 100
> [Jan 28 13:35:15.171] Server {1123043648} DEBUG: (http_tunnel) [10]
> producer_handler [http server VC_EVENT_READ_READY]
> [Jan 28 13:35:15.171] Server {1123043648} DEBUG: (http_redirect)
> [HttpTunnel::producer_handler] enable_redirection: 0 event: 100
> [Jan 28 13:35:15.171] Server {1123043648} DEBUG: (http_tunnel) [10]
> producer_handler [http server VC_EVENT_READ_READY]
> [Jan 28 13:35:15.171] Server {1123043648} DEBUG: (http_redirect)
> [HttpTunnel::producer_handler] enable_redirection: 0 event: 100
> [Jan 28 13:35:15.180] Server {1110411584} DEBUG: (http_tunnel) [10]
> consumer_handler [user agent VC_EVENT_WRITE_READY]
> [Jan 28 13:35:15.180] Server {1110411584} DEBUG: (http_tunnel) [10]
> consumer_handler [user agent VC_EVENT_WRITE_READY]
it turns out that nothing have happen here.
there is magic indeed: the second request will be about 10x faster than first.
sounds intersting?
--
zym, Zhao Yongming.
aka: yonghao @ taobao.com
