--On Sunday, October 24, 2004 8:30 PM -0600 Paul Querna <[EMAIL PROTECTED]>
wrote:
I took this patch as the starting point for my 'Event MPM'.
...
I would love feedback on all aspects of the patch. Please feel free to rip
it apart :)
I just had a conversation on #apr with Paul. But, I'll rehash
--On Monday, October 25, 2004 9:04 PM -0700 "Roy T. Fielding"
<[EMAIL PROTECTED]> wrote:
This is not an error that the server admin can solve -- it is normal
life on the Internet. We really shouldn't be logging it except when
on DEBUG level.
+1. Info loglevel is way way too high for realistic s
With all due respect, I don't think the following scenario
will be logged by the patch; it only reports when the attempt
to read the initial request line fails, not when the socket
is closed prior to data transfer terminating. At least, that
was the intent.
I'll leave it to Ivan to try and make the
--On Monday, October 25, 2004 2:17 PM -0400 Greg Ames <[EMAIL PROTECTED]>
wrote:
I am thinking of trying to find an old pentium I with PCI and putting
a GigE card in it just for benchmarking.
I'd love to find one like this too. I sometimes use a 180 MHz Pentium Pro
box. But it only has 160M of
> For example, we had a problem report on #apache a couple of days ago
> which turned out, after considerable investigation, to be the result
> of a single host ip issuing hundreds of request connections in a few
> minutes. Whether this was a deliberate attack or simply a buggy
> client is not cle
--On Tuesday, October 26, 2004 4:32 AM +0200 Graham Leggett <[EMAIL PROTECTED]>
wrote:
If mod_transform isn't supporting Etag properly, then I'd say mod_transform
was broken, and fixing it would probably solve your problem.
+1. If the content changes, so should the ETag. mod_transform could als
--On Monday, October 25, 2004 3:56 PM -0600 Jean-Jacques Clar
<[EMAIL PROTECTED]> wrote:
What about doing:
static const char *add_ignore_header(cmd_parms *parms, void *dummy,
- const char *header)
+ char *header)
Um, no, you
On 25-Oct-04, at 11:04 PM, Roy T. Fielding wrote:
This is not an error that the server admin can solve -- it is normal
life on the Internet. We really shouldn't be logging it except when
on DEBUG level.
That was my first reaction, too. However, Ivan Ristic pointed out that
(in some cases, anyway)
What would make more sense is "Error while reading HTTP request line.
(remote browser didn't send a request?)". This indicates exactly what
httpd was trying to do when the error occurred, and gives a hint of
why the error might have occurred.
We used to have such a message. It was removed from
Paul Querna wrote:
I have been doing some stuff with mod_transform (XSLT processor) and
mod_cache.
The problem is, mod_cache doesn't have any easy way to know if a request
needs to be regenerated. Right now, it just blindly caches until a
timeout. What I would prefer is that it knows what fil
I have been doing some stuff with mod_transform (XSLT processor) and
mod_cache.
The problem is, mod_cache doesn't have any easy way to know if a request
needs to be regenerated. Right now, it just blindly caches until a
timeout. What I would prefer is that it knows what files or URLs a
speci
Brian Akins wrote:
Greg Ames wrote:
one thread per connection with an active http request, plus the
listener/event thread who owns all the connections in keepalive. I
believe Paul is saying set ThreadsPerChild to 1200 to handle the worst
case behavior - 100% of the connections are doing real wo
Jean-Jacques Clar wrote:
What about doing:
static const char *add_ignore_header(cmd_parms *parms, void *dummy,
- const char *header)
+ char *header)
{
cache_server_conf *conf;
char **new;
@@ -802,7 +802,7 @@
What about doing:
static const char *add_ignore_header(cmd_parms *parms, void *dummy,- const char *header)+ char *header) { cache_server_conf *conf; char **new;@@ -802,7 +802,7 @@ * (When 'None' is pas
Paul Querna wrote:
Paul Querna wrote:
> A thread per-connection that is currently being processed.
Note that this is not the traditional 'event' model that people write
huge papers about and thttpd raves about, but rather a hybrid that
uses a Worker Thread todo the processing, and a single 'even
Paul Querna wrote:
This only works for the EPoll and KQueue backends. This allows a worker
thread to _add() or _remove() directly, without having to touch the
thread in _poll().
It could be implemented for plain Poll by having the pollset contain an
internal pipe. This Pipe could be pushed by
Greg Ames wrote:
Brian Akins wrote:
We have some home grown benchmarks that may could help,
If they simulate user think time or would otherwise cause a lot of
keepalive timeouts, great! Finding the right client/benchmark is a
problem for me right now and I believe for Paul too.
Yup. This is my
Greg Ames wrote:
Brian Akins wrote:
Can you still have multiple processes? We use 10k plus threads per
box with worker.
with my patch, yes. with Paul's, no.
Correct at the moment.
I think based on the feedback so far, I will investigate making it
multi-processed again.
Brian Akins wrote:
I can certainly provide you guys with some testing, if nothing else.
excellent!
We have some home grown benchmarks that may could help,
If they simulate user think time or would otherwise cause a lot of keepalive
timeouts, great! Finding the right client/benchmark is a probl
Greg Ames wrote:
Assuming you have a high percentage of threads in keepalive timeouts,
you will be able to cut down on the number of threads per box.
Yes, we do.
I can certainly provide you guys with some testing, if nothing else. We
have some home grown benchmarks that may could help, not to me
Brian Akins wrote:
Can you still have multiple processes? We use 10k plus threads per box
with worker.
with my patch, yes. with Paul's, no.
But Paul's has some very nice features that mine doesn't have, so I think a
hybrid is the way to go.
Assuming you have a high percentage of threads in kee
Garrett Rooney wrote:
Jean-Jacques Clar wrote:
Thanks for reporting the problem Norm,
The patch was submitted.
Is casting to (char *) really the right thing to do here? I mean why
not just make new const so the cast isn't needed at all? It seems like
Do I miss anything or would we need *new t
Greg Ames wrote:
one thread per connection with an active http request, plus the
listener/event thread who owns all the connections in keepalive. I
believe Paul is saying set ThreadsPerChild to 1200 to handle the worst
case behavior - 100% of the connections are doing real work at some
instant
Paul Querna wrote:
> A thread per-connection that is currently being processed.
Note that this is not the traditional 'event' model that people write
huge papers about and thttpd raves about, but rather a hybrid that uses
a Worker Thread todo the processing, and a single 'event' thread to
handl
Brian Pane wrote:
How about modifying ab to add a delay of a second or two between
successive read(2) calls
on the same connection (and limiting the max read size to a small value,
to make sure each
response requires multiple reads)? The throughput numbers wouldn't be
very impressive, of
course
Greg Ames wrote:
First is a patch to APR that provides an extension to apr_pollset that
optionally make some parts of it threadsafe. This patch has been
submitted to APR before, and hopefully it will get accepted there soon.
I need to catch up here. quick questions: will this event MPM work wi
Brian Pane wrote:
Paul Querna wrote:
Brian Akins wrote:
Have you tried it with higher number of clients -- i.e,. -c 1024?
Nope. I was already maxing out my 100mbit LAN at 25 clients. I don't
have a good testing area for static content request benchmarking.
I am thinking of trying to find an ol
++1 for moving this along.
For any newbies, the object of the game is to increase httpd scalability by
reducing the number of worker threads and their associated stack memory.
Paul Querna wrote:
First is a patch to APR that provides an extension to apr_pollset that
optionally make some parts of
Paul Querna wrote:
Brian Akins wrote:
Paul Querna wrote:
[...]
Have you tried it with higher number of clients -- i.e,. -c 1024?
Nope. I was already maxing out my 100mbit LAN at 25 clients. I don't
have a good testing area for static content request benchmarking.
I am thinking of trying to fin
Paul Querna wrote:
>
> Brian Akins wrote:
>
>> We are interesting in the event mpm mainly for dealing with keep alives.
>>
> Yes, this is the target the Event MPM aims at :)
If I understand the nature of the patch correctly then you don't
need to go increasing the number of clients at all. Ins
Brian Akins wrote:
Paul Querna wrote:
Non-KeepAlive:
`ab -c 25 -n 10 http://10.10.10.10:6080/index.html`
Worker MPM: 2138.28
Event MPM: 2147.95
KeepAlive:
`ab -k -c 25 -n 10 http://10.10.10.10:6080/index.html`
Worker MPM: 4396.38
Event MPM: 4119.40
Have you tried it with higher number
Jean-Jacques Clar wrote:
Thanks for reporting the problem Norm,
The patch was submitted.
Is casting to (char *) really the right thing to do here? I mean why
not just make new const so the cast isn't needed at all? It seems like
a cast in this situation is a bit ugly...
-garrett
mod_cache is a different issue. The compiler used to build the
netware NLMs is very sensitive to type mismatches.
> @@ -3793,7 +3794,7 @@
>core_net_rec *net = f->ctx;
>core_ctx_t *ctx = net->in_ctx;
>const char *str;
> -apr_size_t len;
> +apr_ssize_t len
Thanks for reporting the problem Norm,
The patch was submitted.
Jean-Jacques>>> [EMAIL PROTECTED] 10/24/04 5:08 PM >>>
Greetings All,Just trying a 'build' of current 2.1 CVS on a Windows machine for NetWare and get the following error...Calling NWGNUmod_cachCompiling cache_util.cCompiling mod_cac
Graham Leggett wrote:
Rici Lake wrote:
I believe that ap_log_rerror() inserts the OS error description,
resulting in something like:
[client 127.0.0.1] (70007)The timeout specified has expired: request
line read error
Of course, this is OS dependent.
That still means little to me as an end use
Brad Nicholes wrote:
-1 as well. This is now causing compiler errors on NetWare. Please
revert this patch!
Can you provide an indication of exactly what broke so we
will know what to avoid in future. Or was the breakage
actually due to the the mod_cache problem reported
last night?
Thanks, Allan
On 25-Oct-04, at 9:57 AM, Graham Leggett wrote:
What would make more sense is "Error while reading HTTP request line.
(remote browser didn't send a request?)". This indicates exactly what
httpd was trying to do when the error occurred, and gives a hint of
why the error might have occurred.
That
Rici Lake wrote:
I believe that ap_log_rerror() inserts the OS error description,
resulting in something like:
[client 127.0.0.1] (70007)The timeout specified has expired: request
line read error
Of course, this is OS dependent.
That still means little to me as an end user, as I would think a
On 25-Oct-04, at 3:37 AM, Graham Leggett wrote:
+else if (r->connection->keepalive !=
AP_CONN_KEEPALIVE) {
+ap_log_rerror(APLOG_MARK, APLOG_NOTICE, rv, r,
+ "request line read error.");
+}
Is it possible to put a more de
Paul Querna wrote:
Non-KeepAlive:
`ab -c 25 -n 10 http://10.10.10.10:6080/index.html`
Worker MPM: 2138.28
Event MPM: 2147.95
KeepAlive:
`ab -k -c 25 -n 10 http://10.10.10.10:6080/index.html`
Worker MPM: 4396.38
Event MPM: 4119.40
Have you tried it with higher number of clients -- i.e,
On Fri, Oct 22, 2004 at 07:31:09PM -, Jim Jagielski wrote:
> if (d == len + dest) {
> +ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR, r,
> + "mod_include: directive length exceeds limit"
> + " (%d) in %s", len+1, r->f
On 25 Oct 2004 06:40:08 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Index: protocol.c
> ===
> RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
> retrieving revision 1.155
> retrieving revision 1.156
> diff -u -r1
[EMAIL PROTECTED] wrote:
server protocol.c
Log:
This will put some messages in the error log when some people try a lame
DoS by just opening a socket, and never sending any data.
+else if (r->connection->keepalive != AP_CONN_KEEPALIVE) {
+ap_l
43 matches
Mail list logo
