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

["weijin (Updated) (JIRA)" <ji...@apache.org>]

     [ 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