Roundup Tracker - Issues

Issue 2550651

classification
Title: HEAD requests arer very slow.
Type: resource usage Severity: major
Components: Web interface Versions: 1.4
process
Status: new Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: ber, richard, rouilj, tonimueller
Priority: Keywords:

Created on 2010-05-10 10:22 by tonimueller, last changed 2016-07-10 23:22 by rouilj.

Messages
msg4055 Author: [hidden] (tonimueller) Date: 2010-05-10 10:22
Copied from debian:540626 :

Experimental evidence suggests that HEAD requests will result in
Roundup generating the entire page, discard it, then send the headers
to the client.  This is very wasteful, particularly on large pages.

Making requests to bugs.darcs.net *from* bugs.darcs.net (to avoid
network latency), we can see that HEAD and GET take about the same
amount of time:

    $ time nc bugs.darcs.net www <<<$'HEAD /status1 HTTP/1.1\nHost:
bugs.darcs.net\n\n' | wc -l
    7

    real    0m18.549s
    user    0m0.004s
    sys     0m0.004s
    $ time nc bugs.darcs.net www <<<$'GET /status1 HTTP/1.1\nHost:
bugs.darcs.net\n\n' | wc -l
    3117

    real    0m18.324s
    user    0m0.004s
    sys     0m0.004s

This issue has practical implications for me.  I maintain a script to
interact with roundup's mailgw, and I wanted to valid status IDs
before sending emails:

    if ! curl -fsIo/dev/null http://bugs.example.net/status$N
    then error "$N is not a valid status ID!"
    fi

Currently this request can take deciseconds, and so is far too slow to
use.




I've talked to both Eric Kow of darcs.net to get 1.4.13 installed there,
and to the user, who has confirmed that the problem is still present in
the latest version of roundup.
msg4056 Author: [hidden] (tonimueller) Date: 2010-05-10 10:24
Ouch, someone has apparently disabled the Debian-BTS linking. The
original bug can be viewed here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540626
msg4094 Author: [hidden] (richard) Date: 2010-07-12 04:16
I'm not sure how this situation could be improved. It would be quite difficult in most cases to 
determine what HEAD should be testing for a "last modified" date for pages.
msg4098 Author: [hidden] (ber) Date: 2010-07-20 09:14
I'd say that the original use case should be solved differently.
Or what are other use cases for HEAD that we should support?
msg5509 Author: [hidden] (rouilj) Date: 2016-04-09 04:51
Is there a way in TAL to tell if a HEAD has been requested and abort the
generation of the tal page. Something like:

<tal:dontprocess tal:condition="python:
request.client.env['REQUEST_METHOD'] != 'HEAD'" >'

as the very first line of the page.html file
should prevent the page generation/tal processing right?

Will that have any effect on the expires time?
msg5823 Author: [hidden] (rouilj) Date: 2016-07-10 23:22
Probably too late to make any difference, but
another possibility occurred to me.

Rather than using:


  curl -fsIo/dev/null http://bugs.example.net/status$N

how about creating a template that is empty. Touch
tracker/html/issue.empty.html then use:

 curl -fsIo/dev/null 
'http://localhost:9017/demo/issue10400?@template=empty'; echo $?
22

curl -fsIo/dev/null 
'http://localhost:9017/demo/issue1?@template=empty'; echo $?
0

where issue1 exists and the other one doesn't.

This is probably as close as you can get at the moment. It does go into
the template code, but does very little work.

Alternatively you could use the xmlrpc interface.
History
Date User Action Args
2016-07-10 23:22:26rouiljsetmessages: + msg5823
2016-04-09 04:51:23rouiljsetnosy: + rouilj
messages: + msg5509
2010-07-20 09:14:34bersetnosy: + ber
messages: + msg4098
2010-07-20 09:13:18bersettitle: HEAD is ridiculously slow. -> HEAD requests arer very slow.
2010-07-12 04:16:57richardsetnosy: + richard
messages: + msg4094
2010-05-10 10:24:11tonimuellersetmessages: + msg4056
2010-05-10 10:22:45tonimuellercreate