[
https://issues.apache.org/jira/browse/COUCHDB-1986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13955355#comment-13955355
]
Oriol commented on COUCHDB-1986:
--------------------------------
Hello,
We encountered a similar issue while uploading files to couchdb. For us, what
made it really slow is the fact that we have couchdb behind an nginx proxy,
which means that all connections go through the 'loopback' interface.
The issue was due to the MTU of the 'loopback' interface in linux (MTU:16436)
that it is set much bigger than on a physical ethernet nic (MTU:1500). This has
a consequence on the MSS on the TCP layer which in turn has a consequence on
the amount of data that couchdb receives.
When sending a big file, all TCP packets are loaded with maximum payload up
until the MSS size, so more data is sent without any ACK from the server. That
means that the receiver buffer will fill up quicker on a 'loopback' interface
than it does on a physical one. The default socket parameters set in couchdb
prevent couchdb to fetch data quick enough from the TCP layer ending up on a
'TCP window full' situation. Ultimately, the connection is throttling at TCP
level making it really slow.
Increasing the 'recv_buffer size to 131072' prevents the TCP layer to throttle
and the file upload went, in our case, from 90 sec down to 0.7 secs.
Reducing the MTU size of the interface should also work though we haven't check
that.
I don't really know if it is related to your specific issue but it may not be
really onto couchdb code but more on the way the connection is made at a TCP
level.
Cheers, Oriol
> 04-replication-large-atts.t times out
> -------------------------------------
>
> Key: COUCHDB-1986
> URL: https://issues.apache.org/jira/browse/COUCHDB-1986
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
> Affects Versions: 1.5.0
> Reporter: Jan Lehnardt
>
> 04-replication-large-atts.t gets stuck around 558, sometimes a little earlier
> or later, but it times out eventually, regardless of the timeout. I tried
> doubling and such.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
