Re: Question on Empty GIF module

You mean “posted by Denis”?

Yes, sorry about that.

In sort: post_action registers callback that will be called after request
will be processed by usual handlers (in this case - by empty_gif
module). It evaluates after response has been sent to client,
so client sees no delay in request processing.

I see. So its not actually doing a “POST” type of operations. Rather,
it is posting (really just forwarding) the same request to the url
specified by the post_action, correct?

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, could I work
around that by running another instance of nginx on another port on the
server, setting the post_action to hit a url on that instance of nginx,
and then have that instance of nginx use proxy_pass to distribute the
requests among multiple servers? This is of course just for the backend
processing since the empty gif would already have been served.

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 what does?

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 the background work
(that post_action is talking to) would only get one request at a time?
Then I would imagine that under load the requests within nginx could
build up to a point where the backlog was too load and eventually run
out of connections or break some how?

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 this?

Docs for post_action doesn’t exist (yet). There are some relevant
russian mailing list posts, but I can’t recall anything in
English.

Are there any optional parameters or attributes that can be specified
with the post_action I should know about?

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?

Closing connection isn’t really needed since empty_gif returns
response with Content-Length set, and even HTTP/1.0 browsers will
see response before connection will be closed. This will block
subsequent requests within keep-alive connection though, see
above.

You have to return any valid response. Simple “204 No content” will do.

Perfect, I’ll change it to do that.

Thank you very much Maxim for all your help with this! It is deeply
appreciated!!

  ____________________________________________________________________________________

Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Hello!

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.

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
what does?

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
delayed.

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
[…]

No.

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
this?

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
English.

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
location, too.

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?

Yes.

Maxim D.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs