[ 
https://issues.apache.org/jira/browse/TS-3102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157241#comment-14157241
 ] 

James Peach commented on TS-3102:
---------------------------------

I need to review this more, and I would also like comments from [~briang]. So 
far, I really don't like the additional state flags, and there are far too many 
default function parameters that make it hard to figure out what will happen. 
Even as an experimental API, {{TSFetchInit}} seems wildly dangerous.

I am having trouble following the performance argument above. Can you please 
clarify what the performance issue is, and post some before/after numbers?

> 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