[jira] [Commented] (TS-998) Broken ClientReq in TSAPI
[ https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187240#comment-13187240 ] Leif Hedstrom commented on TS-998: -- So, I'm not sure I like this approach. What are the advantages here of making a stringified copy of the pristine request headers, instead of making a copy of the request object? If we made a copy of the original request object, and leave it immutable (static), we can keep using the normal APIs for getting headers etc. out of it, no? In a similar fashion, we already have TSHttpTxnPristineUrlGet(). So, we'd add something like TSHttpTxnPristineReqGet() or some such. Broken ClientReq in TSAPI - Key: TS-998 URL: https://issues.apache.org/jira/browse/TS-998 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.1 Environment: any Reporter: Nick Kew Assignee: Nick Kew Fix For: 3.1.2 Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request line. Expected behaviour: In a PRE_REMAP hook it should return the client request line and headers, ideally verbatim. Observed behaviour: http://; is prepended to the request URL: GET /path/ HTTP/1.1 becomes GET http:///path/ HTTP/1.1 (yes, that's three slashes) Pseudo-code to reproduce from a PRE_REMAP hook: TSHttpTxnClientReqGet(txnp, buf, hdr); TSHttpHdrPrint(buf, hdr, iobuf); reader = TSIOBufferReaderAlloc(iobuf); block = TSIOBufferReaderStart(reader); len = TSIOBufferBlockReadAvail(block, reader); data = TSIOBufferBlockReadStart(block, reader, len); Now examine the contents of data. Assigned to AMC as suggested yesterday on-list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-998) Broken ClientReq in TSAPI
[ https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187287#comment-13187287 ] Nick Kew commented on TS-998: - Hang on! All this patch is doing in my tests is to keep a pointer to the buf in url_parse. I'm not sure when copy_strings is required, but I haven't encountered it in any test. AFAICS the most expensive operation in the patch is the strstr ! My memory could be at fault here, but I think I encountered the same bug with PristineUrlGet as first reported: namely an incorrectly-reconstructed URL. Unfortunately an instant-test of it on reading your comment fails a sanity check ( *url_loc is NULL), and it's the time of evening when I'm going to run around in fruitless circles if I dig deeper. Broken ClientReq in TSAPI - Key: TS-998 URL: https://issues.apache.org/jira/browse/TS-998 Project: Traffic Server Issue Type: Bug Affects Versions: 3.0.1 Environment: any Reporter: Nick Kew Assignee: Nick Kew Fix For: 3.1.2 Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request line. Expected behaviour: In a PRE_REMAP hook it should return the client request line and headers, ideally verbatim. Observed behaviour: http://; is prepended to the request URL: GET /path/ HTTP/1.1 becomes GET http:///path/ HTTP/1.1 (yes, that's three slashes) Pseudo-code to reproduce from a PRE_REMAP hook: TSHttpTxnClientReqGet(txnp, buf, hdr); TSHttpHdrPrint(buf, hdr, iobuf); reader = TSIOBufferReaderAlloc(iobuf); block = TSIOBufferReaderStart(reader); len = TSIOBufferBlockReadAvail(block, reader); data = TSIOBufferBlockReadStart(block, reader, len); Now examine the contents of data. Assigned to AMC as suggested yesterday on-list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-998) Broken ClientReq in TSAPI
[
https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187345#comment-13187345
]
Leif Hedstrom commented on TS-998:
--
I'm assuming that
{code}
if (must_copy s_str) {
s_str = heap-duplicate_str(s_str, s_len);
}
{code}
will have to copy the string version of something (sounds like the entire
request URL + header). Maybe that is cheap. As for the logging, that string is
only used (afaik) if you use the cquuc tag in a custom log (it would not be
used in the default logs, or error logs). We could perhaps change that if/where
it makes sense.
What I'm saying is, what would make most sense to me personally would be to
keep an immutable request object before remap happens, and then we can use
normal APIs on that. This would remove the need for the PristineUrl API, and
this string version of the request URL for logging (which is created solely for
logging, if someone uses the cquuc tag in a custom log).
Broken ClientReq in TSAPI
-
Key: TS-998
URL: https://issues.apache.org/jira/browse/TS-998
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.1
Environment: any
Reporter: Nick Kew
Assignee: Nick Kew
Fix For: 3.1.2
Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request
line.
Expected behaviour: In a PRE_REMAP hook it should return the client request
line and headers, ideally verbatim.
Observed behaviour: http://; is prepended to the request URL:
GET /path/ HTTP/1.1
becomes
GET http:///path/ HTTP/1.1
(yes, that's three slashes)
Pseudo-code to reproduce from a PRE_REMAP hook:
TSHttpTxnClientReqGet(txnp, buf, hdr);
TSHttpHdrPrint(buf, hdr, iobuf);
reader = TSIOBufferReaderAlloc(iobuf);
block = TSIOBufferReaderStart(reader);
len = TSIOBufferBlockReadAvail(block, reader);
data = TSIOBufferBlockReadStart(block, reader, len);
Now examine the contents of data.
Assigned to AMC as suggested yesterday on-list.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-998) Broken ClientReq in TSAPI
[
https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187434#comment-13187434
]
Leif Hedstrom commented on TS-998:
--
Ok, I re-ran all the benchmarks (with and without the latest patch here):
Before:
{code}
tinkerballa (20:22) 256/0 $ ~/benchit.sh 100 300
48759110 fetches on 482907 conns, 300 max parallel, 4.875910E+09 bytes, in 300
seconds
100 mean bytes/fetch
162530.2 fetches/sec, 1.625302E+07 bytes/sec
msecs/connect: 0.266 mean, 9.225 max, 0.042 min
msecs/first-response: 1.329 mean, 294.947 max, 0.083 min
{code}
After:
{code}
http_load -parallel 100 -seconds 300 -keep_alive 100 /tmp/URL
43633453 fetches on 432166 conns, 300 max parallel, 4.363350E+09 bytes, in 300
seconds
100 mean bytes/fetch
145444.9 fetches/sec, 1.454449E+07 bytes/sec
msecs/connect: 0.188 mean, 10.545 max, 0.041 min
msecs/first-response: 1.528 mean, 234.828 max, 0.082 min
{code}
So yeah, pretty sure there's a noticeable cost of doing this copy, no?
Broken ClientReq in TSAPI
-
Key: TS-998
URL: https://issues.apache.org/jira/browse/TS-998
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.1
Environment: any
Reporter: Nick Kew
Assignee: Nick Kew
Fix For: 3.1.2
Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request
line.
Expected behaviour: In a PRE_REMAP hook it should return the client request
line and headers, ideally verbatim.
Observed behaviour: http://; is prepended to the request URL:
GET /path/ HTTP/1.1
becomes
GET http:///path/ HTTP/1.1
(yes, that's three slashes)
Pseudo-code to reproduce from a PRE_REMAP hook:
TSHttpTxnClientReqGet(txnp, buf, hdr);
TSHttpHdrPrint(buf, hdr, iobuf);
reader = TSIOBufferReaderAlloc(iobuf);
block = TSIOBufferReaderStart(reader);
len = TSIOBufferBlockReadAvail(block, reader);
data = TSIOBufferBlockReadStart(block, reader, len);
Now examine the contents of data.
Assigned to AMC as suggested yesterday on-list.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TS-998) Broken ClientReq in TSAPI
[
https://issues.apache.org/jira/browse/TS-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13187434#comment-13187434
]
Leif Hedstrom edited comment on TS-998 at 1/17/12 4:22 AM:
---
Ok, I re-ran all the benchmarks (with and without the latest patch here):
Before:
{code}
48759110 fetches on 482907 conns, 300 max parallel, 4.875910E+09 bytes, in 300
seconds
100 mean bytes/fetch
162530.2 fetches/sec, 1.625302E+07 bytes/sec
msecs/connect: 0.266 mean, 9.225 max, 0.042 min
msecs/first-response: 1.329 mean, 294.947 max, 0.083 min
{code}
After:
{code}
43633453 fetches on 432166 conns, 300 max parallel, 4.363350E+09 bytes, in 300
seconds
100 mean bytes/fetch
145444.9 fetches/sec, 1.454449E+07 bytes/sec
msecs/connect: 0.188 mean, 10.545 max, 0.041 min
msecs/first-response: 1.528 mean, 234.828 max, 0.082 min
{code}
So yeah, pretty sure there's a noticeable cost of doing this copy, no?
was (Author: zwoop):
Ok, I re-ran all the benchmarks (with and without the latest patch here):
Before:
{code}
tinkerballa (20:22) 256/0 $ ~/benchit.sh 100 300
48759110 fetches on 482907 conns, 300 max parallel, 4.875910E+09 bytes, in 300
seconds
100 mean bytes/fetch
162530.2 fetches/sec, 1.625302E+07 bytes/sec
msecs/connect: 0.266 mean, 9.225 max, 0.042 min
msecs/first-response: 1.329 mean, 294.947 max, 0.083 min
{code}
After:
{code}
http_load -parallel 100 -seconds 300 -keep_alive 100 /tmp/URL
43633453 fetches on 432166 conns, 300 max parallel, 4.363350E+09 bytes, in 300
seconds
100 mean bytes/fetch
145444.9 fetches/sec, 1.454449E+07 bytes/sec
msecs/connect: 0.188 mean, 10.545 max, 0.041 min
msecs/first-response: 1.528 mean, 234.828 max, 0.082 min
{code}
So yeah, pretty sure there's a noticeable cost of doing this copy, no?
Broken ClientReq in TSAPI
-
Key: TS-998
URL: https://issues.apache.org/jira/browse/TS-998
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.0.1
Environment: any
Reporter: Nick Kew
Assignee: Nick Kew
Fix For: 3.1.2
Extracting a Request using TSHttpTxnClientReqGet API yields a bogus Request
line.
Expected behaviour: In a PRE_REMAP hook it should return the client request
line and headers, ideally verbatim.
Observed behaviour: http://; is prepended to the request URL:
GET /path/ HTTP/1.1
becomes
GET http:///path/ HTTP/1.1
(yes, that's three slashes)
Pseudo-code to reproduce from a PRE_REMAP hook:
TSHttpTxnClientReqGet(txnp, buf, hdr);
TSHttpHdrPrint(buf, hdr, iobuf);
reader = TSIOBufferReaderAlloc(iobuf);
block = TSIOBufferReaderStart(reader);
len = TSIOBufferBlockReadAvail(block, reader);
data = TSIOBufferBlockReadStart(block, reader, len);
Now examine the contents of data.
Assigned to AMC as suggested yesterday on-list.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
