Question on Empty GIF module
mdounin at mdounin.ru
Fri Apr 25 21:43:20 MSD 2008
On Fri, Apr 25, 2008 at 07:54:48AM -0700, Rt Ibmer wrote:
>Is it possible to have the post_action be load balanced across a
>set of backend servers (like the way proxy_pass works) or will it
>only work with one specific server? If that later is the case,
You may specify any uri for proxy_pass, and it will be served almost
as regular request (with the exception that results won't be
served to client). So you may do everything you want with it -
including proxy_pass'ing to load-balanced cluster of backends.
>>The only disadvantage of post_action as of current implementation
>>is that it blocks connection, i.e. following keep-alive request
>>won't be processed until post_action terminates.
>Can you please explain the implication of this in some more
>detail, as I am not very familiar with the details on how all the
>connection stuff works under the hood?
>For instance, lets say that the server handling the post_action
>takes 500ms to execute before returning the 204 No Content
>response. What connection is actually being blocked during this
>period? The browser that originated the request has been satisfied
>immediately by empty_gif so I know it doesn't see this delay, but
The problem only manifest itself with keep-alive connections. If
browser sends requests, gets response, then sends next request
within the same connection - this next request processing will be
>Perhaps what you are saying is that no matter how many requests
>come in at the same time that are destined for post_action, that
>nginx can only process those one at a time? So that my app doing
>At any rate, how difficult of a change is it to make post_action
>so that it does not block, and are there any near-term plans for
I'm not aware of such plans.
>>Docs for post_action doesn't exist (yet). There are some relevant
>>russian mailing list posts, but I can't recall anything in
>Are there any optional parameters or attributes that can be
>specified with the post_action I should know about?
No, it takes only one parameter. As of 0.6.27 this may be named
>>And of course really best way do things is to write logs and just process them as needed.
>Depending on how this all works out, it may be worthwhile down
>the road to rewrite our app to process off the log files. Am I
>correct to assume that I can use an access_log directive inside
>the area where empty_gif is used, so that these specific gif
>requests are logged to their own log file separate from the other
>types of requests that nginx is handling?
More information about the nginx