Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Invalid offload() log messages #80

Closed
prymitive opened this Issue · 6 comments

2 participants

@prymitive
Collaborator
{address space usage: 19288064 bytes/18MB} {rss usage: 7012352 bytes/6MB} [pid: 5054|app: 0|req: -1/1] 192.168.10.92 () {26 vars in 433 bytes} [Fri Dec  7 12:33:48 2012] GET /URL => generated 0 bytes in 7 msecs via offload() (HTTP/1.0 -30) 2 headers in 92 bytes (0 switches on core 0)

7 msecs this file is big (~600MB) so it wasn't fetched so fast, this is probably the time between request start and sending it to offload thread

(HTTP/1.0 -30) - since offload is taking care of this file, than I think it's safe to just hardcode it to 200 (or 304 if static offloading takes care of that)

@unbit
Owner

fixed (or better, 'improved') in 1.9

@prymitive
Collaborator

[pid: 16500|app: 0|req: -1/1] 172.16.110.48 () {28 vars in 355 bytes} [Fri Feb 8 21:45:48 2013] GET /bigfile => generated 536870912 bytes in 0 msecs via offload() (HTTP/1.1 200) 2 headers in 92 bytes (0 switches on core 0)

I'm getting proper HTTP status code, but message is logged immediately and shows 0 msecs, shouldn't this be logged by offload thread itself once it finishes sending file?
Not a big issue but request duration is lost in logs this way.

@prymitive
Collaborator

To have proper time reporting for offloaded request, we would have to:
a) move logging to sendfile functions in core/offload.c
b) add callback support to offload function and add log callbacks if requests are offloaded
c) some other/better way

it's very very unimportant for me

@prymitive
Collaborator

I've created new milestone "Future Ideas" to track such feature requests

@unbit
Owner

This is an interesting problem, as offloading is becaming present in more and more areas. For proxy offloaders (http, uwsgi) the backend node will log normally, so the information is not lost. Response offloaders (cache, and the new 'offload' transformation) refers only to data transfer time (as well as sendfile()), so we need to evaluate if such information is relevant (considering kernel buffering all over the place) to a level needing a new logging category.

@prymitive
Collaborator

I don't care for upload time for static files so let's close it

@prymitive prymitive closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.