[jira] [Updated] (TS-980) change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable

2013-07-09 Thread Leif Hedstrom (JIRA) 

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

Leif Hedstrom updated TS-980:
-

Fix Version/s: (was: 3.3.5)
   3.3.6

 change client_session schedule from global  to thread local, and reduce the 
 try_locks in UnixNetVConnection::reenable
 -

 Key: TS-980
 URL: https://issues.apache.org/jira/browse/TS-980
 Project: Traffic Server
  Issue Type: Improvement
  Components: Network, Performance
Affects Versions: 3.1.0, 3.0.0
 Environment: all
Reporter: weijin
Assignee: weijin
 Fix For: 3.3.6

 Attachments: ts-980.diff


 I did some performance test on ats last days(disable cache, set share_server 
 session 2, pure proxy mode), I did see significant improvement on low load, 
 but it dropped rapidly when load is high. meanwhile, some stability problems 
 happened. Through gdb, I found the client_session`s mutex can be acquired by 
 two or more threads, I believe some schedules happened during the sm 
 life_time. May be we need do some work to find these eventProcessor.schedules 
 and change them to thread schedules.
 UnixVConnecton::reenable {
 if (nh-mutex-thread_holding == t) {
   // put into ready_list
 } else {
MUTEX_TRY_LOCK(lock, nh-mutex, t);
if (!lock) {
  // put into enable_list;
} else {
  // put into ready_list;
}
 }
 remove UnixNetVConnection::reenable try_lock operations, 3 reasons
 1. try_lock operation means obj allocation and deallocation operation. 
 frequently
 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule 
 by as soon as possible)
 3. try_lock should not acquire the net-handler`s mutex. That may lead more 
 net io latency if it is an epoll event need to be processed in other threads. 
 If it is not an epoll event(time event), I don`t think putting vc in 
 ready_list has any advantage than in enable_list.
 may be we can change reenale function like this:
 UnixVConnecton::reenable {
 if (nh-mutex-thread_holding == t) {
   // put into ready_list;
 } else {
   // put into enable_list;
 }
 my buddies, any advice?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-980) change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable

2012-04-09 Thread Zhao Yongming (Updated) (JIRA) 

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

Zhao Yongming updated TS-980:
-

Fix Version/s: (was: 3.1.4)
   3.3.0

reschedule to 3.3.0, may need more tweak  testing

 change client_session schedule from global  to thread local, and reduce the 
 try_locks in UnixNetVConnection::reenable
 -

 Key: TS-980
 URL: https://issues.apache.org/jira/browse/TS-980
 Project: Traffic Server
  Issue Type: Improvement
  Components: Network, Performance
Affects Versions: 3.1.0, 3.0.0
 Environment: all
Reporter: weijin
Assignee: weijin
 Fix For: 3.3.0

 Attachments: ts-980.diff


 I did some performance test on ats last days(disable cache, set share_server 
 session 2, pure proxy mode), I did see significant improvement on low load, 
 but it dropped rapidly when load is high. meanwhile, some stability problems 
 happened. Through gdb, I found the client_session`s mutex can be acquired by 
 two or more threads, I believe some schedules happened during the sm 
 life_time. May be we need do some work to find these eventProcessor.schedules 
 and change them to thread schedules.
 UnixVConnecton::reenable {
 if (nh-mutex-thread_holding == t) {
   // put into ready_list
 } else {
MUTEX_TRY_LOCK(lock, nh-mutex, t);
if (!lock) {
  // put into enable_list;
} else {
  // put into ready_list;
}
 }
 remove UnixNetVConnection::reenable try_lock operations, 3 reasons
 1. try_lock operation means obj allocation and deallocation operation. 
 frequently
 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule 
 by as soon as possible)
 3. try_lock should not acquire the net-handler`s mutex. That may lead more 
 net io latency if it is an epoll event need to be processed in other threads. 
 If it is not an epoll event(time event), I don`t think putting vc in 
 ready_list has any advantage than in enable_list.
 may be we can change reenale function like this:
 UnixVConnecton::reenable {
 if (nh-mutex-thread_holding == t) {
   // put into ready_list;
 } else {
   // put into enable_list;
 }
 my buddies, any advice?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TS-980) change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable

2011-10-13 Thread Leif Hedstrom (Updated) (JIRA) 

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

Leif Hedstrom updated TS-980:
-

Fix Version/s: 3.1.2

 change client_session schedule from global  to thread local, and reduce the 
 try_locks in UnixNetVConnection::reenable
 -

 Key: TS-980
 URL: https://issues.apache.org/jira/browse/TS-980
 Project: Traffic Server
  Issue Type: Improvement
  Components: Network, Performance
Affects Versions: 3.1.0, 3.0.0
 Environment: all
Reporter: weijin
Assignee: weijin
 Fix For: 3.1.2


 I did some performance test on ats last days(disable cache, set share_server 
 session 2, pure proxy mode), I did see significant improvement on low load, 
 but it dropped rapidly when load is high. meanwhile, some stability problems 
 happened. Through gdb, I found the client_session`s mutex can be acquired by 
 two or more threads, I believe some schedules happened during the sm 
 life_time. May be we need do some work to find these eventProcessor.schedules 
 and change them to thread schedules.
 UnixVConnecton::reenable {
 if (nh-mutex-thread_holding == t) {
   // put into ready_list
 } else {
MUTEX_TRY_LOCK(lock, nh-mutex, t);
if (!lock) {
  // put into enable_list;
} else {
  // put into ready_list;
}
 }
 remove UnixNetVConnection::reenable try_lock operations, 3 reasons
 1. try_lock operation means obj allocation and deallocation operation. 
 frequently
 2. try_lock hardly can lock the net-handler`s mutex.(net-handler is schedule 
 by as soon as possible)
 3. try_lock should not acquire the net-handler`s mutex. That may lead more 
 net io latency if it is an epoll event need to be processed in other threads. 
 If it is not an epoll event(time event), I don`t think putting vc in 
 ready_list has any advantage than in enable_list.
 may be we can change reenale function like this:
 UnixVConnecton::reenable {
 if (nh-mutex-thread_holding == t) {
   // put into ready_list;
 } else {
   // put into enable_list;
 }
 my buddies, any advice?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira