Message6026
Since roundup is no longer distributed as a debian package, this sort
of takes on less importance.
However I did two experiments:
Change page.html. I put:
<tal:dontprocess
tal:condition="python:request.client.env['REQUEST_METHOD'] != 'HEAD'" >'
right before the <body> tag in page.html. Then I put:
</tal:dontprocess>
right after the </body> tag.
When curling I used the following framework:
time sh -c 'for i in `seq 1 100`;
do curl -sk -o/dev/null -w"%{time_total}\n"
https://rouilj.dynamic-dns.net/demo/issue3 ; done'
(wordwrapped manually). Running this takes total time of: 0m45.816s
Using the same as above but with --head added to the curl args,
it takes total time of: 0m26.533s
For anybody who can divide by 100, the following will
not be shocking.
In the GET case, curl reports average total time of 0.446s
with median of .447 and a range of 0.422, 0.456
The HEAD case returns average: 0.253s median: .253 and range
0.236, 0.259.
So we can see that there is a significant ~50% decrease in time.
The test env is running via a proxy web server (hiawatha 10.6) against
a daemonized roundup with a sqlite back end on an ASUS EB1036-B0534
Desktop with xubuntu 14.04.5. YMMV if you are using it as a cgi.
Given the original report that deciseconds was too slow this doesn't
help much as best case is still 2.5 deciseconds.
Creating an empty issue.empty.html file in the html subdir and running
the above loop with a url of:
"https://rouilj.dynamic-dns.net/demo/issue3?@template=empty"
(note the quotes to protect the ?)
returns get case: avg: 0.15966 med: 0.160 range: 0.153, 0.171
returns head case: avg: 0.15968 med: 0.160 range: 0.154, 0.169
which are pretty much indistinguishable.
However still in 1.5 decisecond range. I think just the work of
accessing the db (to validate that the issue exists) and setting up an
html response is what we are seeing. But this does get it down to 25%
of the original request time.
Note that using get on issue999 which generates a 404 error from the
server runs in 45ish seconds. Probably because it is rendering
_generic.404.html with the page border and all the rest. Running just
a head runs in 26 seconds which seems to support that supposition
since it looks similar to what was obtained with the original
modified page.html. So again slower than requested.
Putting the tal to detect a HEAD request at the top and bottom of the
_generic.404.page will probably cut that back to something similar to
(but higher than) the empty issue.empty.html template.
This is left as an exercise for the reader.
Also note there is no last-modified header generated for issues, only
attached files. So Richard's note that HEAD would not include a last
modified date is moot since I don't think any issue page has a last
modified date.
-- rouilj |
|
| Date |
User |
Action |
Args |
| 2017-10-02 23:17:17 | rouilj | set | messageid: <1506986237.69.0.213398074469.issue2550651@psf.upfronthosting.co.za> |
| 2017-10-02 23:17:17 | rouilj | set | recipients:
+ rouilj, richard, ber, tonimueller |
| 2017-10-02 23:17:17 | rouilj | link | issue2550651 messages |
| 2017-10-02 23:17:15 | rouilj | create | |
|