 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
11 messages in ru.sysoev.nginxRe: [ANNOUNCE] ngx_http_upstream_keep...| From | Sent On | Attachments |
|---|---|---|
| Maxim Dounin | Oct 24, 2008 8:21 am | |
| Maxim Dounin | Oct 24, 2008 8:41 am | |
| Grzegorz Nosek | Oct 24, 2008 8:57 am | |
| Maxim Dounin | Oct 24, 2008 9:21 am | |
| Grzegorz Nosek | Oct 24, 2008 9:33 am | |
| Maxim Dounin | Oct 24, 2008 9:56 am | |
| Kon Wilms | Oct 24, 2008 10:22 am | |
| Grzegorz Nosek | Oct 24, 2008 10:27 am | |
| Maxim Dounin | Oct 24, 2008 11:12 am | |
| Chavelle Vincent | Jan 26, 2009 10:33 am | |
| Maxim Dounin | Jan 26, 2009 11:40 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [ANNOUNCE] ngx_http_upstream_keepalive | Actions... |
|---|---|---|
| From: | Grzegorz Nosek (grze...@gmail.com) | |
| Date: | Oct 24, 2008 10:27:47 am | |
| List: | ru.sysoev.nginx | |
On pią, paź 24, 2008 at 08:56:28 +0400, Maxim Dounin wrote:
Request to upstream is created in ngx_http_proxy_module, so no filters there.
Right. But it was worth asking ;)
You may try to use proxy_set_header though, and then use proxy_hide_header to filter out Keep-Alive header from the response. It may even work - if backend handle HTTP/1.0 keepalive connections and won't try to sent chunked encoding to nginx.
That was my idea too but I thought about encapsulating it somehow so that the keepalive support would be transparent.
But in fact nginx should be modified to support HTTP/1.1 to backends.
True. It can be a pain especially when your backend is a stupid embedded device that only talks pidgin HTTP/1.1.
For FastCGI it should be as simple as not setting appropriate close bit in request created by ngx_http_fastcgi_module (and using my patches for connection closing), but I've not checked it yet.
I think keepalive support would fit best in Nginx core (not as an external module) with some infrastructure to support it. Consumers of the upstream functionality (memcached, fastcgi, proxy) could provide a "want keepalive" flag which would mean that they are aware of keepalive and handle it at the protocol level.
As Nginx is as much a proxy as it is a web server, maybe it makes sense to make the upstream layer stackable, like:
- session affinity support (or something; influences peer choice, can skip the real load balancer) - the real load balancer (ip_hash, rr, fair; influences peer choice) - keepalive support (does not influence peer choice--usually)
We could also e.g. pass the request data to the load balancer while we're at it so it can be a bit smarter (e.g. POSTs to a single "master" backends, GETs balanced over a pool of "slaves", a'la databases). The common cases could then be simpler and faster than handcrafting a config file.
Best regards, Grzegorz Nosek