[jira] [Updated] (TS-980) change client_session schedule from global to thread local, and reduce the try_locks in UnixNetVConnection::reenable
[ 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
[ 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
[ 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