> try a different webserver
The last thing we were going to try was Apache 2.x.
Could it help? I mean the support for threads which
share common memory could reduce the overall memory
consumption. Is my assumption correct? Are MySQL libs
and other necessary libs for php thread-safe?
Also, do yo
The Apache server runs on Debian 3.1 (latest stable),
2.4.x kernel.
The following modules are loaded:
mod_php4.c, mod_ssl.c, mod_setenvif.c, mod_expires.c,
mod_auth.c, mod_access.c, mod_rewrite.c, mod_alias.c,
mod_cgi.c, mod_dir.c, mod_autoindex.c, mod_info.c,
mod_status.c, mod_negotiation.c, mod
Hello,
We are running Apache 1.3.33, PHP 4.3 and MySQL 4.1
and noticed that each Apache child process takes 5 MB
of RAM as soon as it is started (i.e. 5 MB per
connection).
Why is that? What can we do to reduce that to 1 MB or
less.
Thanks in advance.
_
> how about you define /dev/null as the page
> displayed when a user hits a 403 url ?
That seems to be the only thing we can do. This indeed
significantly reduces the bandwidth usage on
403-responses. However, we would still like to see a
zero-bandwidth solution. Thanks.
___
--- Boyle Owen <[EMAIL PROTECTED]> wrote:
> It's a constant struggle to keep ahead of them. We
> use a variety of strategies (honeytraps, user agent,
> cookies, behavioural heuristics).
Although these methods sounds cool (and we use them
too, as I wrote) they still waste the bandwidth (on
send
--- Boyle Owen <[EMAIL PROTECTED]> wrote:
> The RFC specifically
> requires the server to respond to valid requests
> with a response message (which may be 403
> Forbidden). Unfortunately, there's nothing in the
> RFC that allows for "closing a connection".
Well, these "standards" were obviousl
--- Boyle Owen <[EMAIL PROTECTED]> wrote:
> Apache is an application
> and can only block at the HTTP layer - it can't
> interfere with TCP/IP.
That is certainly true, but Apache must be capable of
closing a connection -- that seems to be an elementary
operation for a web server (and possibly
--- Rich <[EMAIL PROTECTED]> wrote:
> The 'add_httpd_block' script is something I wrote
> myself to drop the connection and block the IP for
> a while.
But how do you block it? 403 is possible, but not what
we want. Firewall is possible, but our hosting
provider doesn't allows us to configure
--- Rich <[EMAIL PROTECTED]> wrote:
> You can configure mod_securiy so that it will not
> respond at all - ie -
> it will just leave the client hanging waiting for a
> response (which it
> will never get). Much like a 'silent' firewall.
>
> As I said, not ideal (the connection is still live),
> Once it you know this, you can configure it to
> prevent further communication with the client
> (not actually killing the connection, but the
> affect will be the same - the client will give up).
Unfortunately, the "client" will not give up. The
result will be that our (very expensive) bandw
--- Rich <[EMAIL PROTECTED]> wrote:
> Have you tried mod_security? -
> http://www.modsecurity.org/
Thanks Rich. It certainly is an interesting module,
however, it does not seem to be capable of closing a
connection (it only supports the 'deny' action, which
normally is just 403).
> I'm not sure apache can do that but I have one linux
> box setup as firewall,
> patched with patch-o-matic and I do this what you
> want with iptables.
Thanks for the reply. I'm not sure I understand it
correctly, but this sounds like you are using the IP
addresses as the basis for the ban. Ho
We have been trying to cut down our bandwidth usage by
disallowing access for many spammers and malevolent
bots. We are currently doing it via .htaccess and
respond with the "403 Forbidden" code.
However, this still costs us some bandwidth. What we
would like to do is close the connection without
13 matches
Mail list logo
