[jira] [Updated] (TS-3431) enable_read_while_writer delays requests for mis-matched HTTP methods
[
https://issues.apache.org/jira/browse/TS-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3431:
--
Component/s: Core
> enable_read_while_writer delays requests for mis-matched HTTP methods
> -
>
> Key: TS-3431
> URL: https://issues.apache.org/jira/browse/TS-3431
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
>Affects Versions: 5.2.0
>Reporter: Nick Muerdter
>Priority: Minor
> Fix For: sometime
>
>
> If enable_read_while_writer is enabled (which it is by default), then a GET
> request can hold up the processing of a POST request to the same URL
> endpoint. Since the POST request is fundamentally different, it doesn't seem
> like the POST request should be waiting for the fulfillment of the GET
> request before processing.
> An example might be the easiest way to demonstrate this: Let's say you have a
> backend that has both a GET and POST endpoint at the same URL. Each of these
> requests takes 10 seconds to complete. If you make the GET request first, and
> then quickly follow it by the POST request to the same URL, then the GET
> request will complete in 10 seconds, while the POST request will take 20
> seconds (since it first waits 10 seconds for the GET request to complete,
> then apparently realizes it can't actually use the cache, and then proceeds
> to the POST request which takes another 10 seconds). However, it's worth
> noting that if you make the requests in the opposite order (POST first, and
> then GET), then there are no delays.
> Here's some example scripts to demonstrate this. Here's a node.js backend
> that will respond to both GET and POST requests at the same URL and take 10
> seconds:
> {code}
> var http = require("http");
> http.createServer(function(request, response) {
> setTimeout(function() {
> response.writeHead(200);
> response.write('example response');
> response.end();
> }, 1);
> }).listen(3000);
> {code}
> I then took a default TrafficServer 5.2.0 install with the only change being
> to use this backend in remap.config:
> {code}
> map / http://127.0.0.1:3000/
> {code}
> Here's the output from a GET request with a POST request following shortly
> after and happening in parallel (note the POST request takes nearly 20
> seconds to complete):
> {code}
> $ time curl -v "http://127.0.0.1:8080/;
> * About to connect() to 127.0.0.1 port 8080 (#0)
> * Trying 127.0.0.1... connected
> * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> > GET / HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1
> > Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Host: 127.0.0.1:8080
> > Accept: */*
> >
> < HTTP/1.1 200 OK
> < Date: Sun, 08 Mar 2015 21:49:36 GMT
> < Age: 10
> < Transfer-Encoding: chunked
> < Connection: keep-alive
> < Server: ATS/5.2.0
> <
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection #0
> example response
> real 0m10.017s
> user 0m0.005s
> sys 0m0.002s
> $ time curl --data "foo=bar" -v "http://127.0.0.1:8080/;
> * About to connect() to 127.0.0.1 port 8080 (#0)
> * Trying 127.0.0.1... connected
> * Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> > POST / HTTP/1.1
> > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1
> > Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> > Host: 127.0.0.1:8080
> > Accept: */*
> > Content-Length: 7
> > Content-Type: application/x-www-form-urlencoded
> >
> < HTTP/1.1 200 OK
> < Date: Sun, 08 Mar 2015 21:49:46 GMT
> < Age: 10
> < Transfer-Encoding: chunked
> < Connection: keep-alive
> < Server: ATS/5.2.0
> <
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection #0
> example response
> real 0m19.531s
> user 0m0.004s
> sys 0m0.002s
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3431) enable_read_while_writer delays requests for mis-matched HTTP methods
[
https://issues.apache.org/jira/browse/TS-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3431:
--
Fix Version/s: sometime
enable_read_while_writer delays requests for mis-matched HTTP methods
-
Key: TS-3431
URL: https://issues.apache.org/jira/browse/TS-3431
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.2.0
Reporter: Nick Muerdter
Priority: Minor
Fix For: sometime
If enable_read_while_writer is enabled (which it is by default), then a GET
request can hold up the processing of a POST request to the same URL
endpoint. Since the POST request is fundamentally different, it doesn't seem
like the POST request should be waiting for the fulfillment of the GET
request before processing.
An example might be the easiest way to demonstrate this: Let's say you have a
backend that has both a GET and POST endpoint at the same URL. Each of these
requests takes 10 seconds to complete. If you make the GET request first, and
then quickly follow it by the POST request to the same URL, then the GET
request will complete in 10 seconds, while the POST request will take 20
seconds (since it first waits 10 seconds for the GET request to complete,
then apparently realizes it can't actually use the cache, and then proceeds
to the POST request which takes another 10 seconds). However, it's worth
noting that if you make the requests in the opposite order (POST first, and
then GET), then there are no delays.
Here's some example scripts to demonstrate this. Here's a node.js backend
that will respond to both GET and POST requests at the same URL and take 10
seconds:
{code}
var http = require(http);
http.createServer(function(request, response) {
setTimeout(function() {
response.writeHead(200);
response.write('example response');
response.end();
}, 1);
}).listen(3000);
{code}
I then took a default TrafficServer 5.2.0 install with the only change being
to use this backend in remap.config:
{code}
map / http://127.0.0.1:3000/
{code}
Here's the output from a GET request with a POST request following shortly
after and happening in parallel (note the POST request takes nearly 20
seconds to complete):
{code}
$ time curl -v http://127.0.0.1:8080/;
* About to connect() to 127.0.0.1 port 8080 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
GET / HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1
Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: 127.0.0.1:8080
Accept: */*
HTTP/1.1 200 OK
Date: Sun, 08 Mar 2015 21:49:36 GMT
Age: 10
Transfer-Encoding: chunked
Connection: keep-alive
Server: ATS/5.2.0
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
example response
real 0m10.017s
user 0m0.005s
sys 0m0.002s
$ time curl --data foo=bar -v http://127.0.0.1:8080/;
* About to connect() to 127.0.0.1 port 8080 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
POST / HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1
Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: 127.0.0.1:8080
Accept: */*
Content-Length: 7
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Date: Sun, 08 Mar 2015 21:49:46 GMT
Age: 10
Transfer-Encoding: chunked
Connection: keep-alive
Server: ATS/5.2.0
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
example response
real 0m19.531s
user 0m0.004s
sys 0m0.002s
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3431) enable_read_while_writer delays requests for mis-matched HTTP methods
[
https://issues.apache.org/jira/browse/TS-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Muerdter updated TS-3431:
--
Affects Version/s: 5.2.0
enable_read_while_writer delays requests for mis-matched HTTP methods
-
Key: TS-3431
URL: https://issues.apache.org/jira/browse/TS-3431
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.2.0
Reporter: Nick Muerdter
If enable_read_while_writer is enabled (which it is by default), then a GET
request can hold up the processing of a POST request to the same URL
endpoint. Since the POST request is fundamentally different, it doesn't seem
like the POST request should be waiting for the fulfillment of the GET
request before processing.
An example might be the easiest way to demonstrate this: Let's say you have a
backend that has both a GET and POST endpoint at the same URL. Each of these
requests takes 10 seconds to complete. If you make the GET request first, and
then quickly follow it by the POST request to the same URL, then the GET
request will complete in 10 seconds, while the POST request will take 20
seconds (since it first waits 10 seconds for the GET request to complete,
then apparently realizes it can't actually use the cache, and then proceeds
to the POST request which takes another 10 seconds). However, it's worth
noting that if you make the requests in the opposite order (POST first, and
then GET), then there are no delays.
Here's some example scripts to demonstrate this. Here's a node.js backend
that will respond to both GET and POST requests at the same URL and take 10
seconds:
{code}
var http = require(http);
http.createServer(function(request, response) {
setTimeout(function() {
response.writeHead(200);
response.write('example response');
response.end();
}, 1);
}).listen(3000);
{code}
I then took a default TrafficServer 5.2.0 install with the only change being
to use this backend in remap.config:
{code}
map / http://127.0.0.1:3000/
{code}
Here's the output from a GET request with a POST request following shortly
after and happening in parallel (note the POST request takes nearly 20
seconds to complete):
{code}
$ time curl -v http://127.0.0.1:8080/;
* About to connect() to 127.0.0.1 port 8080 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
GET / HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1
Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: 127.0.0.1:8080
Accept: */*
HTTP/1.1 200 OK
Date: Sun, 08 Mar 2015 21:49:36 GMT
Age: 10
Transfer-Encoding: chunked
Connection: keep-alive
Server: ATS/5.2.0
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
example response
real 0m10.017s
user 0m0.005s
sys 0m0.002s
$ time curl --data foo=bar -v http://127.0.0.1:8080/;
* About to connect() to 127.0.0.1 port 8080 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
POST / HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.1
Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: 127.0.0.1:8080
Accept: */*
Content-Length: 7
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Date: Sun, 08 Mar 2015 21:49:46 GMT
Age: 10
Transfer-Encoding: chunked
Connection: keep-alive
Server: ATS/5.2.0
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
example response
real 0m19.531s
user 0m0.004s
sys 0m0.002s
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
