You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Leif Hedstrom (JIRA)" <ji...@apache.org> on 2011/08/18 19:02:27 UTC
[jira] [Created] (TS-924) Performance improvements with second
request on same keep-alive connection
Performance improvements with second request on same keep-alive connection
--------------------------------------------------------------------------
Key: TS-924
URL: https://issues.apache.org/jira/browse/TS-924
Project: Traffic Server
Issue Type: Improvement
Components: Core
Reporter: Leif Hedstrom
Fix For: 3.1.1
This is a continuation of TS-880, it has more details. The idea is that we committed the safe, but less optimal fix already with TS-880. Ideally though, we should do something like William's first approach, and migrate origin VConns to the same EThread as the UA VConn.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-924) Performance improvements with second
request on same keep-alive connection
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099060#comment-13099060 ]
Leif Hedstrom commented on TS-924:
----------------------------------
Hmmm, sounds complicated :). Maybe we should just make this option non-reloadable? I mean, how often would you change this on a live system anyways?
> Performance improvements with second request on same keep-alive connection
> --------------------------------------------------------------------------
>
> Key: TS-924
> URL: https://issues.apache.org/jira/browse/TS-924
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.1.1
>
> Attachments: TS-924.diff
>
>
> This is a continuation of TS-880, it has more details. The idea is that we committed the safe, but less optimal fix already with TS-880. Ideally though, we should do something like William's first approach, and migrate origin VConns to the same EThread as the UA VConn.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-924) Performance improvements with second
request on same keep-alive connection
Posted by "weijin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098664#comment-13098664 ]
weijin commented on TS-924:
---------------------------
yes。 I even have a immature idea, we first acquire the session of the same thread, if not, we create new session or acquire from the global sessions, that depends on the CONFIG proxy.config.http.share_server_sessions.
> Performance improvements with second request on same keep-alive connection
> --------------------------------------------------------------------------
>
> Key: TS-924
> URL: https://issues.apache.org/jira/browse/TS-924
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.1.1
>
> Attachments: TS-924.diff
>
>
> This is a continuation of TS-880, it has more details. The idea is that we committed the safe, but less optimal fix already with TS-880. Ideally though, we should do something like William's first approach, and migrate origin VConns to the same EThread as the UA VConn.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-924) Performance improvements with second
request on same keep-alive connection
Posted by "weijin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098563#comment-13098563 ]
weijin commented on TS-924:
---------------------------
I think this patch is awesome. I have a question, when CONFIG proxy.config.http.share_server_sessions is changed, do we need to put the global server_sessions into thread local sever_sessions? opposite is also the case.
> Performance improvements with second request on same keep-alive connection
> --------------------------------------------------------------------------
>
> Key: TS-924
> URL: https://issues.apache.org/jira/browse/TS-924
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.1.1
>
> Attachments: TS-924.diff
>
>
> This is a continuation of TS-880, it has more details. The idea is that we committed the safe, but less optimal fix already with TS-880. Ideally though, we should do something like William's first approach, and migrate origin VConns to the same EThread as the UA VConn.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-924) Performance improvements with second
request on same keep-alive connection
Posted by "weijin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099733#comment-13099733 ]
weijin commented on TS-924:
---------------------------
I tend to think that making this option non-reloadable is better, or else, the incompleteness would drive me crazy. haha
> Performance improvements with second request on same keep-alive connection
> --------------------------------------------------------------------------
>
> Key: TS-924
> URL: https://issues.apache.org/jira/browse/TS-924
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.1.1
>
> Attachments: TS-924-v2.diff, TS-924.diff
>
>
> This is a continuation of TS-880, it has more details. The idea is that we committed the safe, but less optimal fix already with TS-880. Ideally though, we should do something like William's first approach, and migrate origin VConns to the same EThread as the UA VConn.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-924) Performance improvements with second
request on same keep-alive connection
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-924:
-----------------------------
Attachment: TS-924-v2.diff
Slight changes, moving bucket initialization out to thread creation.
> Performance improvements with second request on same keep-alive connection
> --------------------------------------------------------------------------
>
> Key: TS-924
> URL: https://issues.apache.org/jira/browse/TS-924
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.1.1
>
> Attachments: TS-924-v2.diff, TS-924.diff
>
>
> This is a continuation of TS-880, it has more details. The idea is that we committed the safe, but less optimal fix already with TS-880. Ideally though, we should do something like William's first approach, and migrate origin VConns to the same EThread as the UA VConn.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-924) Performance improvements with second
request on same keep-alive connection
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098590#comment-13098590 ]
Leif Hedstrom commented on TS-924:
----------------------------------
You mean for reloading the configuration on the fly? I think what will happen is that the connections would eventually time out from the per net-thread hash buckets, and we'd create new ones on the global cache. It's an excellent question though, so let me test that some more.
> Performance improvements with second request on same keep-alive connection
> --------------------------------------------------------------------------
>
> Key: TS-924
> URL: https://issues.apache.org/jira/browse/TS-924
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.1.1
>
> Attachments: TS-924.diff
>
>
> This is a continuation of TS-880, it has more details. The idea is that we committed the safe, but less optimal fix already with TS-880. Ideally though, we should do something like William's first approach, and migrate origin VConns to the same EThread as the UA VConn.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-924) Performance improvements with second
request on same keep-alive connection
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom updated TS-924:
-----------------------------
Attachment: TS-924.diff
Here's a preliminary proposed patch. I know, there's a lot of indentation changes as well, but the two fundamental changes are:
1) Fix the memory allocations for both the server and client sessions.
2) Add a new option, that allows us to specify that each net-thread should keep its own pool of origin connections.
#2 Can have slight performance drawbacks if there's very little traffic against the origin. Therefore, I'm making this option overridable per remap rule (or from a plugin via the existing APIs).
The options to enable #2 is the same as enable shared origin connections, I'm overloading it with a value of "2" meaning share connections, but per net-thread.
{code}
# Share server connections
# 0 - Never
# 1 - Share, with a single global connection pool
# 2 - Share, with a connection pool per worker thread
CONFIG proxy.config.http.share_server_sessions INT 1
{code}
I'm leaving the default as it was before, and the fixed memory allocations will help a little bit here too. But to get full benefit here, you have to set the config to 2.
Many thanks to William and weijin for doing all the work on figuring out the real problems going on here. I still think it might be worthwhile to allow for origin connections to move between net-threads, but this solution fixes that, and has some other benefits (keeping "memory" tied on the owning thread).
> Performance improvements with second request on same keep-alive connection
> --------------------------------------------------------------------------
>
> Key: TS-924
> URL: https://issues.apache.org/jira/browse/TS-924
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Fix For: 3.1.1
>
> Attachments: TS-924.diff
>
>
> This is a continuation of TS-880, it has more details. The idea is that we committed the safe, but less optimal fix already with TS-880. Ideally though, we should do something like William's first approach, and migrate origin VConns to the same EThread as the UA VConn.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (TS-924) Performance improvements with second
request on same keep-alive connection
Posted by "Leif Hedstrom (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TS-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif Hedstrom reassigned TS-924:
--------------------------------
Assignee: Leif Hedstrom
> Performance improvements with second request on same keep-alive connection
> --------------------------------------------------------------------------
>
> Key: TS-924
> URL: https://issues.apache.org/jira/browse/TS-924
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Fix For: 3.1.1
>
> Attachments: TS-924-v2.diff, TS-924.diff
>
>
> This is a continuation of TS-880, it has more details. The idea is that we committed the safe, but less optimal fix already with TS-880. Ideally though, we should do something like William's first approach, and migrate origin VConns to the same EThread as the UA VConn.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira