How to count dropped connections

[Amos Shapira]

2009/6/9 shimi <linux-il at shimi.net>:
> On Tue, Jun 9, 2009 at 2:40 PM, Amos Shapira <amos.shapira at gmail.com> wrote
>> 2. One of the applications does lots of TCP/IP-level connection
>> sniffing so it can't be used behind an application-level proxy, it
>> must have a direct connection to the browser (LVS works for us since
>> it acts like a bridge - doesn't touch anything inside the packet
>> except for the destination MAC address).
>
> You mean that it connects back to the origin and then run stuff on it? If
> that's the problem, nginx has an option to forward the originating IP
> address via an HTTP header, which you can then use in your application.

Oops. With all the load at work I had recently I missed the questions,
so will try to answer here just to show respect to those who invest
time in answering -

It doesn't connect back but actually looks at the TCP/IP level packets
(TCP and IP header fields and such).

> I think that you can't (side of sniffing). However nginx is designed for
> tens of thousands of simultaneous keep-alive sessions, with a *very* small
> footprint. This is a very high limit. I think that above it, you'ld need
> something which is hardware assisted (like F5 BigIP)
>
> From my experience, nginx allowed to reduce the number of running Apache
> threads (apache+mod_php5 was the setup). I don't know how much of your
> content can be served directly by nginx (I dumped Apache completely, because
> nginx can do PHP via FastCGI). How much you'll reduce depends on what volume

Thanks for the recommendation. One important part of our product is
going to be moved from Perl+Catalyst to PHP+Zend Framework, so this
might be relevant there, though we don't expect huge load on it (it's
a customer service centre, not a completely public site).

> of the requests is going to your proprietary module :) But all static
> content handling can be done by nginx. When number of Apache threads go
> down, your CPU load goes down, and your memory usage goes WAY down. My
> numbers were 10-20 loadavg with 6GB RAM, down to loadavg of 1 with a few
> tens of MBs of RAM... my hardware problem became a bandwidth problem... our
> uplink couldn't sustain what we now been able to push... of course, that's
> because I was pure-PHP - so your case is different.
>
> But really, setting it up is a breeze, and very easy to test. I'll do give
> you a tip, though. nginx has static buffers set up for everything; And it
> tests them and returns an HTTP error if a request is larger than the
> buffers. So if your requests are bigger than very plain access (large
> cookies, file uploads, etc) - be advised to set up the relevant buffers in
> nginx.conf with values larger than the default (the default is VERY light on
> resources...)

Thanks for the tip, maybe it'll be relevant to watch for it if/when we
allow customers to upload large streams.

Cheers,

--Amos