| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This reverts commit 2a5515a2d2fd26b595c3dd5c9d0d905211712890.
|
|
The file is generated at build time. It was kept around for
Rebar compatibility. Since then we have been publishing
releases to Hex so Rebar arguably doesn't need to fetch
the project from Git.
|
|
Adds two options:
* max_authorization_header_value_length to configure the
maximum length of the authorization header specifically;
* max_cookie_header_value_length to configure the
maximum length of the cookie header specifically.
LH: I added the relevant tests.
|
|
|
|
This should avoid Dialyzer errors.
A CI job testing without COWBOY_QUICER has also been added.
|
|
|
|
|
|
|
|
The close reason will differ from HTTP/1.1 because we don't
have access to the socket. Also trapping exits is required
to process the 'EXIT' signal and call terminate/3.
|
|
|
|
|
|
Rescue from https://github.com/ninenines/cowboy/pull/1687
See https://erlangforums.com/t/cowboy-2-13-0-performance-bottleneck-at-8-7k-rps-on-erlang-28-0-2/5004
Co-authored-by: Zabrane <[email protected]>
|
|
Based on RabbitMQ performance testing. In RabbitMQ we start
at 128 instead but 128 is too low for typical HTTP requests.
|
|
A new data_delivery mechanism called 'relay' has been added.
It bypasses stream handlers (and the buffering in cowboy_stream_h)
and sends the data directly to the process implementing
Websocket (and should work for other similar protocols
like HTTP/2 WebTransport).
Flow control in HTTP/2 is maintained in a simpler way,
via a configured flow value that is used to maintain
the window to a reasonable value when data is received.
The 'relay' data_delivery has been implemented for both
HTTP/2 and HTTP/3. It has not been implemented for HTTP/1.1
since switching protocol there overrides the connection process.
HTTP/2 Websocket is now better tested.
A bug was fixed with the 'stream_handlers' data_delivery
where active mode would not be reenabled if it was disabled
at some point.
The Websocket performance suite has been updated to
include tests that do not use Gun. Websocket modules
used by the performance suite use the 'relay' data_delivery
now. Performance is improved significantly with 'relay',
between 10% and 20% faster. HTTP/2 Websocket performance
is not on par with HTTP/1.1 still, but the remaining
difference is thought to be from the HTTP/2 overhead and
flow control.
|
|
WEBTRANSPORT -> WT in most places. Only ENABLE_WEBTRANSPORT
remains (since it is a draft-02 setting that was later removed)
as well as internal functions and atoms about stream headers,
for greater clarity.
The draft also clarified that WT_SESSION_GONE can be sent on
the session stream and since it's what is already done a
related todo was removed.
|
|
|
|
A tool decided to use Unicode characters.
|
|
|
|
This implements the upcoming draft-13
but has bits to make it work with draft-02
that most (all?) Chromium versions use.
Data and events are not going through
cowboy_stream beyond init. Since this
approach appears to work well it may
be a good idea to do the same for
Websocket over HTTP/2+ and improve
its performance.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It is now specified as >= 1.8.0 and < 3.0.0 since Cowboy
supports both Ranch 1.8.x and 2.x.
|
|
|
|
This is meant to be used with clients such as Gun to simplify
proxying and similar operations. The set-cookie header must
not be set this way so there is still some extra processing
to be done to fully translate a Gun response into a Cowboy
response.
|
|
Not just on 405 responses or OPTIONS requests.
|
|
|
|
|
|
To avoid intermittent errors that are more likely as more
tests are calling cowboy:stop_listener.
|
|
Over cleartext TCP the `protocols` option lists the enabled
protocols. The default is to allow both HTTP/1.1 and HTTP/2.
Over TLS the default protocol to use when ALPN is not used
can now be configured via the `alpn_default_protocol` option.
Performing an HTTP/1.1 upgrade to HTTP/2 over TLS is now
rejected with an error as connecting to HTTP/2 over TLS
requires the use of ALPN (or that HTTP/2 be the default
when connecting over TLS).
|
|
|
|
Before this change invalid return values would be detected
via unhelpful error messages such as [1] and the closing
of the connection.
[1] Bad value on output port 'tcp_inet'
|
|
Because the exit reason doesn't include the stacktrace they
were ignored. Now they are properly handled. The error message
was changed slightly to accomodate.
|
|
When idle_timeout is configured we do not need a separate
timer to detect inactivity. Disabling idle_timeout is not
recommended and should not be necessary.
|
|
|
|
When enabled the connection process will automatically hibernate.
Because hibernation triggers GC, this can be used as a way to
keep memory usage lower, at the cost of performance.
|
|
|
|
|
|
When 3 or more cookies were sent the extra cookies were not
found because the binary:split on ";" stopped at the first
occurrence.
|
|
The problem was that when a request immediately following another
request with a large enough body, the data for the new request
(including headers) would be buffered waiting for more data,
instead of being processed immediately. If no more data came
in on the socket the request_timeout would eventually trigger.
Now the buffer is processed immediately.
|
|
There's not a big performance difference between 8192 and 1024
so let's use less memory at the start of the connection.
|
|
In rare cases it was possible for active mode to be disabled
when there were no streams pipelined. This resulted in the
dropping of the connection due to timeouts as no data could
be received.
We now enable active mode when necessary even if there are
no streams pipelined.
This was found while benchmarking and I have not been able
to extract a test case.
|
|
|
|
Cowboy will set the socket's buffer size dynamically to
better fit the current workload. When the incoming data
is small, a low buffer size reduces the memory footprint
and improves responsiveness and therefore performance.
When the incoming data is large, such as large HTTP
request bodies, a larger buffer size helps us avoid
doing too many binary appends and related allocations.
Setting a large buffer size for all use cases is
sub-optimal because allocating more than needed
necessarily results in a performance hit (not just
increased memory usage).
By default Cowboy starts with a buffer size of 8192 bytes.
It then doubles or halves the buffer size depending on
the size of the data it receives from the socket. It
stops decreasing at 8192 and increasing at 131072 by
default.
To keep track of the size of the incoming data Cowboy
maintains a moving average. It allows Cowboy to avoid
changing the buffer too often but still react quickly
when necessary. Cowboy will increase the buffer size
when the moving average is above 90% of the current
buffer size, and decrease when the moving average is
below 40% of the current buffer size.
The current buffer size and moving average are
propagated when switching protocols. The dynamic buffer
is implemented in HTTP/1, HTTP/2 and HTTP/1 Websocket.
HTTP/2 Websocket has it disabled because it doesn't
interact directly with the socket; in that case it
is HTTP/2 that has a dynamic buffer.
The dynamic buffer provides a very large performance improvement
in many scenarios, at minimal cost for others. Because it largely
depend on the underlying protocol the improvements are no all equal.
TLS and compression also impact the results.
The improvement when reading a large request body, with the
requests repeated in a fast loop are:
* HTTP: 6x to 20x faster
* HTTPS: 2x to 6x faster
* H2: 4x to 5x faster
* H2C: 20x to 40x faster
I am not sure why H2C's performance was so bad, especially compared
to H2, when using default buffer sizes. Dynamic buffers make H2C a
lot more viable with default settings.
The performance impact on "hello world" type requests is minimal,
it goes from -5% to +5% roughly.
Websocket improvements vary again depending on the protocol, but
also depending on whether compression is enabled:
* HTTP echo: roughly 2x faster
* HTTP send: roughly 4x faster
* H2C echo: roughly 2x faster
* H2C send: 3x to 4x faster
In the echo test we reply back, and Gun doesn't have the dynamic
buffer optimisation, so that probably explains the x2 difference.
With compression however there isn't much improvement. The results
are roughly within -10% to +10% of each other. Zlib compression
seems to be a bottleneck, or at least to modify the performance
profile to such an extent that the size of the buffer does not
matter. This happens to randomly generated binary data as well
so it is probably not caused by the test data.
|
|
Where it wasn't already async. To slightly improve performance.
|
|
|
