[
https://issues.apache.org/jira/browse/TS-980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128043#comment-13128043
]
weijin commented on TS-980:
---------------------------
http_sm can be callback by different threads even use share sessions in thread
mode. in most cases, the callbacks happends in one thread, there may come up an
exception when http_sms(different threads) do the dns query in the same time.
Through the sources, I found HostDBContinuation::remove_trigger_pending_dns can
callsback http_sm which was created by other threads. This is an extreme
condition and have little effect on performance. I also give a patch on this
ticket because it takes me 3 days to figure out the reason.
> 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
