[
https://issues.apache.org/jira/browse/THRIFT-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Frey updated THRIFT-265:
-----------------------------
Attachment: buffer_reset_v2.patch
Anthony you are absolutely right about the 1024 value. Here's an update.
I considered making configurable the number of reads/writes before reallocing,
but avoided doing so because above a certain number, it didn't seem to have any
performance impact. I didn't see any difference on my machines between
reallocing every 512 reads/writes, and never reallocing.
I'm not inclined to make something tunable that has no effect on performance,
but I didn't test it scientifically. For what it's worth, I tried this on some
servers that have ~1000 concurrent connections with at peak ~10,000 requests
per second.
> Buffer bloat in TNonblockingServer
> ----------------------------------
>
> Key: THRIFT-265
> URL: https://issues.apache.org/jira/browse/THRIFT-265
> Project: Thrift
> Issue Type: Improvement
> Components: Library (C++)
> Reporter: Erik Frey
> Assignee: Erik Frey
> Priority: Minor
> Attachments: buffer_reset.patch, buffer_reset_v2.patch, graph.png
>
>
> TNonBlockingServer never resets the lengths of the buffers it maintains for
> reading and writing. Servers with a long life and many concurrent
> connections eventually generate an overhead that can reach into the
> gigabytes, particularly in services that have varied message sizes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
