[ https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
weijin updated TS-980: ---------------------- Attachment: ts-980.diff I bind the nethandle`s mutex as thread mutex to avoid other threads try to lock it. The thread session buckets` mutex are converted back to thread mutex, because the netvc:do_io_read require the cont`s mutex should be hold by current thread. > 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 > > 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