[ 
https://issues.apache.org/jira/browse/TS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sudheer Vinukonda updated TS-3102:
----------------------------------
    Attachment: TS-3102.diff

Note1: This patch allows for reuse of context memory and buffers associated 
with a spdy session (mainly via reusing FetchSM/PluginVC buffers). However, it 
seems like a popular idea to completely get rid of FetchSM layer, so, I am 
actually thinking about a solution to let SpdySession directly interface 
HttpClientSession via SpdyRequests. Will work on it after this interim fix.

Note2: This patch is based off of our internal 5.0.1 branch and may not apply 
as it is to the master. 

> Reuse context memory for SPDY streams within a SPDY connection
> --------------------------------------------------------------
>
>                 Key: TS-3102
>                 URL: https://issues.apache.org/jira/browse/TS-3102
>             Project: Traffic Server
>          Issue Type: Improvement
>          Components: SPDY
>    Affects Versions: 5.0.1
>            Reporter: Sudheer Vinukonda
>            Assignee: Sudheer Vinukonda
>              Labels: yahoo
>             Fix For: 5.2.0
>
>         Attachments: TS-3102.diff
>
>
> In the present SPDY implementation in ATS, there is no client context reuse. 
> Though the spdy session is reused, each stream (even the non-concurrent ones) 
> is allocated a set of new/separate context buffers (including internal 
> plugin_vc, client_session, SM object, header heap, transaction buffers, 
> server session objects etc). Some of these objects are allocated from global 
> pool, while some are from per-thread pool. The context memory is not reused 
> unlike the non-spdy session, where there can be at most one transaction on a 
> given connection/session at a time.
> Besides being very inefficient (the allocation/deallocation) this also leads 
> to larger memory foot print over time, due to the relatively poor reuse of 
> per thread pool objects (especially, when there are a high number of threads 
> - e.g 100+ like we have).
> I am currently testing a patch that does not deallocate the streams when the 
> transaction completes and reuses those for new/subsequent streams.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to