[jira] [Commented] (TS-880) Major performance problem with second request on same keep-alive connection

2011-08-17 Thread weijin (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086156#comment-13086156
 ] 

weijin commented on TS-880:
---

We can use the Ethread evfd and signal_hook function the achieve it. When 
thread A can not acquire the lock of a contination, which will be call back on 
thread B, we can use b-signal_hook(b) to wakeup thread b, if it is blocked on 
epoll_wait. Reown thread is cool, but is dangerous because of many other things.

 Major performance problem with second request on same keep-alive connection
 ---

 Key: TS-880
 URL: https://issues.apache.org/jira/browse/TS-880
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0, 2.1.4
 Environment: 32-bit TS on linux, using epoll.  With 
 proxy.config.http.keep_alive_enabled_out = 1
Reporter: William Bardwell
Assignee: William Bardwell
 Fix For: 3.1.1

 Attachments: performance_2nd_req.diff, performance_2nd_req_try2.diff


 If I load the same URL through TS twice in a row to a server with keep-alives 
 turned on I get really slow performance on the second request.
 E.g. (loading 212M over loopback with uncachable content, but results are 
 similar with cachable content):
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  212M  100  212M0 0   140M  0  0:00:01  0:00:01 --:--:--  
 142M*
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  212M  100  212M0 0  6397k  0  0:00:34  0:00:34 --:--:-- 
 6400k*
 If I turn off proxy.config.http.keep_alive_enabled_out the problem goes away, 
 it can also be partially solved by making proxy.config.io.max_buffer_size 
 really big (but it needs to be bigger for larger content, and that supports 
 the comment below, and proves that it isn't the origin server's fault.)
 When I turn on debug messages it looks like the IO loop for the second 
 request only wakes up every 10ms (when an epoll_wait times out) and then it 
 reads and writes, for the first request it goes much faster without those 
 pauses.  My theory is that the issue is related to the the fact that the 
 outgoing connection fd gets added to the epoll fd for the thread handling the 
 first request and the first user agent fd is added to the same epoll fd, and 
 it stays on that epoll fd.  But the new user agent request is on a different 
 epoll fd which I assume means is tied to a different thread.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (TS-880) Major performance problem with second request on same keep-alive connection

2011-08-17 Thread weijin (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

weijin updated TS-880:
--

Attachment: performance.try3.diff

 Major performance problem with second request on same keep-alive connection
 ---

 Key: TS-880
 URL: https://issues.apache.org/jira/browse/TS-880
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0, 2.1.4
 Environment: 32-bit TS on linux, using epoll.  With 
 proxy.config.http.keep_alive_enabled_out = 1
Reporter: William Bardwell
Assignee: William Bardwell
 Fix For: 3.1.1

 Attachments: performance.try3.diff, performance_2nd_req.diff, 
 performance_2nd_req_try2.diff


 If I load the same URL through TS twice in a row to a server with keep-alives 
 turned on I get really slow performance on the second request.
 E.g. (loading 212M over loopback with uncachable content, but results are 
 similar with cachable content):
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  212M  100  212M0 0   140M  0  0:00:01  0:00:01 --:--:--  
 142M*
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  212M  100  212M0 0  6397k  0  0:00:34  0:00:34 --:--:-- 
 6400k*
 If I turn off proxy.config.http.keep_alive_enabled_out the problem goes away, 
 it can also be partially solved by making proxy.config.io.max_buffer_size 
 really big (but it needs to be bigger for larger content, and that supports 
 the comment below, and proves that it isn't the origin server's fault.)
 When I turn on debug messages it looks like the IO loop for the second 
 request only wakes up every 10ms (when an epoll_wait times out) and then it 
 reads and writes, for the first request it goes much faster without those 
 pauses.  My theory is that the issue is related to the the fact that the 
 outgoing connection fd gets added to the epoll fd for the thread handling the 
 first request and the first user agent fd is added to the same epoll fd, and 
 it stays on that epoll fd.  But the new user agent request is on a different 
 epoll fd which I assume means is tied to a different thread.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Updated] (TS-880) Major performance problem with second request on same keep-alive connection

2011-08-17 Thread mohan_zl (JIRA)

 [ 
https://issues.apache.org/jira/browse/TS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mohan_zl updated TS-880:


Attachment: performance_2nd_req_another_version.patch

Thank you William for your work, we tested your first diff file, and found ts 
will crash, so we write another patch.

 Major performance problem with second request on same keep-alive connection
 ---

 Key: TS-880
 URL: https://issues.apache.org/jira/browse/TS-880
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0, 2.1.4
 Environment: 32-bit TS on linux, using epoll.  With 
 proxy.config.http.keep_alive_enabled_out = 1
Reporter: William Bardwell
Assignee: William Bardwell
 Fix For: 3.1.1

 Attachments: performance.try3.diff, performance_2nd_req.diff, 
 performance_2nd_req_another_version.patch, performance_2nd_req_try2.diff


 If I load the same URL through TS twice in a row to a server with keep-alives 
 turned on I get really slow performance on the second request.
 E.g. (loading 212M over loopback with uncachable content, but results are 
 similar with cachable content):
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  212M  100  212M0 0   140M  0  0:00:01  0:00:01 --:--:--  
 142M*
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  212M  100  212M0 0  6397k  0  0:00:34  0:00:34 --:--:-- 
 6400k*
 If I turn off proxy.config.http.keep_alive_enabled_out the problem goes away, 
 it can also be partially solved by making proxy.config.io.max_buffer_size 
 really big (but it needs to be bigger for larger content, and that supports 
 the comment below, and proves that it isn't the origin server's fault.)
 When I turn on debug messages it looks like the IO loop for the second 
 request only wakes up every 10ms (when an epoll_wait times out) and then it 
 reads and writes, for the first request it goes much faster without those 
 pauses.  My theory is that the issue is related to the the fact that the 
 outgoing connection fd gets added to the epoll fd for the thread handling the 
 first request and the first user agent fd is added to the same epoll fd, and 
 it stays on that epoll fd.  But the new user agent request is on a different 
 epoll fd which I assume means is tied to a different thread.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TS-859) ATS requesting to origin instead to the parent server

2011-08-17 Thread Leif Hedstrom (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086319#comment-13086319
 ] 

Leif Hedstrom commented on TS-859:
--

TS-905.

 ATS requesting to origin instead to the parent server
 -

 Key: TS-859
 URL: https://issues.apache.org/jira/browse/TS-859
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache, HTTP, Network
Affects Versions: 3.0.0
 Environment: ATS 3.0
 CentOS 5.6 Linux 2.6.18-238.12.1.el5 64 bit. gcc 4.1.2-50.el5
 Compiled in this machine. Clean installation.
Reporter: Francisco Sariego
Assignee: Leif Hedstrom
Priority: Critical
 Fix For: 3.1.0


 I'm trying to configure parent servers for hierarchical caching in a forward 
 proxy mode, but I am showing strange effects.
 I have 3 servers:
 - The ATS 3.0 server (172.16.1.144)
 - The parents (172.16.1.195, 172.16.1.196)
 My installation is clean and I've changed only a few parameters.
 - records.config:
 CONFIG proxy.config.url_remap.remap_required INT 0
 CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
 - parent.config
 dest_domain=.  parent=172.16.1.195:8080; 172.16.1.196:8080  
 round_robin=strict
 If I request http://www.apache.org from my web browser, I see, using tcpdump 
 port 8080 -nn in the ATS 3.0 machine connections to 140.211.11.131.8080 
 (www.apache.org) but nothing to the parent servers.
 Connectivity between the ATS and the parents are confirmed using telnet to 
 the 8080 port, and is responding to HTTP requests.
 If I disable the parent config, ATS 3.0 works well.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TS-880) Major performance problem with second request on same keep-alive connection

2011-08-17 Thread William Bardwell (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086364#comment-13086364
 ] 

William Bardwell commented on TS-880:
-

Oh, I was testing 'try3', performance_2nd_req_another_version.patch looks like 
my original patch, so I would expect it to have the same problems...

 Major performance problem with second request on same keep-alive connection
 ---

 Key: TS-880
 URL: https://issues.apache.org/jira/browse/TS-880
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0, 2.1.4
 Environment: 32-bit TS on linux, using epoll.  With 
 proxy.config.http.keep_alive_enabled_out = 1
Reporter: William Bardwell
Assignee: William Bardwell
 Fix For: 3.1.1

 Attachments: performance.try3.diff, performance_2nd_req.diff, 
 performance_2nd_req_another_version.patch, performance_2nd_req_try2.diff


 If I load the same URL through TS twice in a row to a server with keep-alives 
 turned on I get really slow performance on the second request.
 E.g. (loading 212M over loopback with uncachable content, but results are 
 similar with cachable content):
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  212M  100  212M0 0   140M  0  0:00:01  0:00:01 --:--:--  
 142M*
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  212M  100  212M0 0  6397k  0  0:00:34  0:00:34 --:--:-- 
 6400k*
 If I turn off proxy.config.http.keep_alive_enabled_out the problem goes away, 
 it can also be partially solved by making proxy.config.io.max_buffer_size 
 really big (but it needs to be bigger for larger content, and that supports 
 the comment below, and proves that it isn't the origin server's fault.)
 When I turn on debug messages it looks like the IO loop for the second 
 request only wakes up every 10ms (when an epoll_wait times out) and then it 
 reads and writes, for the first request it goes much faster without those 
 pauses.  My theory is that the issue is related to the the fact that the 
 outgoing connection fd gets added to the epoll fd for the thread handling the 
 first request and the first user agent fd is added to the same epoll fd, and 
 it stays on that epoll fd.  But the new user agent request is on a different 
 epoll fd which I assume means is tied to a different thread.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TS-880) Major performance problem with second request on same keep-alive connection

2011-08-17 Thread weijin (JIRA)

[ 
https://issues.apache.org/jira/browse/TS-880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086738#comment-13086738
 ] 

weijin commented on TS-880:
---

The may be never NULL if the thread is an ET_NET thread, after the netHandler 
is calls back startNetEvent.

 Major performance problem with second request on same keep-alive connection
 ---

 Key: TS-880
 URL: https://issues.apache.org/jira/browse/TS-880
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP
Affects Versions: 3.0.0, 2.1.4
 Environment: 32-bit TS on linux, using epoll.  With 
 proxy.config.http.keep_alive_enabled_out = 1
Reporter: William Bardwell
Assignee: William Bardwell
 Fix For: 3.1.0

 Attachments: performance.try3.diff, performance_2nd_req.diff, 
 performance_2nd_req_another_version.patch, performance_2nd_req_try2.diff


 If I load the same URL through TS twice in a row to a server with keep-alives 
 turned on I get really slow performance on the second request.
 E.g. (loading 212M over loopback with uncachable content, but results are 
 similar with cachable content):
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  212M  100  212M0 0   140M  0  0:00:01  0:00:01 --:--:--  
 142M*
   % Total% Received % Xferd  Average Speed   TimeTime Time  
 Current
  Dload  Upload   Total   SpentLeft  Speed
 100  212M  100  212M0 0  6397k  0  0:00:34  0:00:34 --:--:-- 
 6400k*
 If I turn off proxy.config.http.keep_alive_enabled_out the problem goes away, 
 it can also be partially solved by making proxy.config.io.max_buffer_size 
 really big (but it needs to be bigger for larger content, and that supports 
 the comment below, and proves that it isn't the origin server's fault.)
 When I turn on debug messages it looks like the IO loop for the second 
 request only wakes up every 10ms (when an epoll_wait times out) and then it 
 reads and writes, for the first request it goes much faster without those 
 pauses.  My theory is that the issue is related to the the fact that the 
 outgoing connection fd gets added to the epoll fd for the thread handling the 
 first request and the first user agent fd is added to the same epoll fd, and 
 it stays on that epoll fd.  But the new user agent request is on a different 
 epoll fd which I assume means is tied to a different thread.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira