Hi,
I am Using apache-2.0.53.
Without SSI ( mod_include.c ) Aapache serves approximately 6500 req/sec and
with SSI apache processes approximately 2500 req/sec.
Is there any way I can increase the apache performance ?
anything that I need to take care during apache compilation on AMD 64 Bit
Rici Lake wrote:
I was taking a look at the implementation of the renamed (but still
misleading) AP_MODE_EATCRLF, in an attempt to figure out what a
conforming input filter ought to do if it's handed that mode.
I think that really depends on your filter. I have two strategies
there (setting
On Sat, Mar 26, 2005 at 11:27:27AM +0100, Alexander Lazic wrote:
Hi,
i use the 2.1 tunk ab and have found 2 segfaults, it think.
the first one was easy to find:
in ssl_print_cert_info() the buf is 64 not BUFSIZ
for eg. =X509_NAME_oneline(dn, buf, BUFSIZ);
The second one was not so
Hi,
On Fre 15.04.2005 11:54, Joe Orton wrote:
Thanks for the report, there were three segfaults actually; I've fixed
them on the trunk.
Thanks ;-)
one of the segfaults was because you're using a -c value -n, which
doesn't really make sense; I changed ab to reject that.
Ops, sorry :-(
al ;-)
On 4/13/05, Paul Querna [EMAIL PROTECTED] wrote:
Olaf van der Spek wrote:
Hi,
I originally posted this feature request to the bug tracker, but Joe
Orton suggested it'd post it here instead, so here it is.
I'd like to see a new 'MPM' that basically works like this:
A single or
Please discuss this question on the users list. (But start by including
such details as which mpm you are using and what you are using for testing.)
Nitesh Naik wrote:
Hi,
I am Using apache-2.0.53.
Without SSI ( mod_include.c ) Aapache serves approximately 6500 req/sec and
with SSI apache
hi,
look this: [EMAIL PROTECTED]
I made an enhacement to mod_include.
It simply adds an HTML table at the end of document with all the SSI calls and execution time.
It will not improve your performance, but it could help you in finding the bottlenecks.
Let me know if you (or someone else) are
On Apr 15, 2005, at 4:25 AM, Alexander Lazic wrote:
one of the segfaults was because you're using a -c value -n, which
doesn't really make sense; I changed ab to reject that.
Ops, sorry :-(
Don't be sorry, it's still a bug. (:
S.
--
[EMAIL PROTECTED] http://www.temme.net/sander/
PGP
Hi Francisco,
This question is not appropriate for this mailinglist. You may want to
ask it on users@httpd.apache.org instead, or ask IBM.
However, it seems that the SSL VirtualHost does not know that it should
direct requests for /name_of_application to the WebSphere box, and the
plaintext
Hi Sander,
I tried yesterday evening a build from the tarball, and NetWare Makefiles seem
somehow broken for me. I have just fetched the tarballs from
http://cvs.apache.org/snapshots/ and get the same result: 2.0.x-dev breaks with
the extfilter module, while 2.1.x-dev works fine
Can you
On Thu, Apr 14, 2005 at 12:02:35PM -0700, Wilfredo Snchez Vega wrote:
We're investigating possible issues in the system. One comment
from a kernel developer:
We are returning EWOULDBLOCK because the socket is in non-blocking.
Inspecting the socket, so_state is 0x182 (0x100 is
1. RFC 2616 says The response (= 205 Reset Content) MUST NOT include an
entity,
and entity would be message body.
2. p / shouldn't be used. (cf. http://www.w3.org/TR/xhtml1/#C3 )
Tsuyoshi SASAMOTO
[EMAIL PROTECTED]
--- httpd/trunk/modules/http/http_protocol.cSat Apr 16 00:00:00 2005
+++
Guenter,
I just pulled and built the 2.0.54 tarball again and I am not seeing any
problems. mod_extfilter is building without any errors or warnings. I think
that Sander can go ahead with the release and if something unexpected pops up
in the NetWare build, we will post a patch.
Brad
On Thu, Apr 14, 2005 at 04:12:25PM -0400, Geoff Thorpe wrote:
On April 13, 2005 11:46 pm, Rodent of Unusual Size wrote:
TODO ISSUES REMAINING IN MOD_SSL:
[snip]
* the shmcb code should just align its memory segment rather than
jumping through all the safe memcpy and memset hoops
Hi Brad,
I just pulled and built the 2.0.54 tarball again and I am not seeing
any problems. mod_extfilter is building without any errors or
warnings. I think that Sander can go ahead with the release and if
something unexpected pops up in the NetWare build, we will post a
Rici Lake wrote:
I was taking a look at the implementation of the renamed (but still
misleading) AP_MODE_EATCRLF,
AP_MODE_PEEK was more accurate, but whatever...
Removing the mode altogether would mean that either every request was
flushed through the filter chain even in pipelining mode, or
On Fri, Apr 15, 2005 at 10:16:29AM -0500, Rici Lake wrote:
Perhaps I wasn't being clear. AP_MODE_EATCRLF is not a renaming
of AP_MODE_GETLINE; it is a renaming of AP_MODE_PEEK. (The renaming
happened some three years ago in revision 92928, obviously I'm not
al tanto.) To be more precise, it's
On 15-Apr-05, at 11:06 AM, Justin Erenkrantz wrote:
The problem with this code is that it'll only read 8 characters worth
of
CRLFs. We'd probably want to retry the reads until we don't get more
CRLF
pairs. It's not determinate how many extra CRLFs we will get.
Are there browsers which send
On 15-Apr-05, at 10:56 AM, Greg Ames wrote:
the reason that this and the corresponding 1.3 BUFF logic exists is to
minimize tinygrams - ip packets that are less than a full mtu size.
tinygrams definately degrade network performance and trigger things
like Nagle's algorithm. in this particular
At 01:28 PM 4/14/2005, Sander Striker wrote:
Bill, do you happen to have time to get some win32 balls up on dev/dist
so I can push it out together with the other tarballs?
As soon as I get back this evening.
On Fri, Apr 15, 2005 at 11:36:07AM -0500, Rici Lake wrote:
Are there browsers which send more than four extraneous CRLF's but
still support keepalive?
If this code reads four CRLF's without finding any data, it will assume
that there is no immediate incoming request, and send a flush down
On Fri, Apr 15, 2005 at 11:56:38AM -0400, Greg Ames wrote:
Rici Lake wrote:
I was taking a look at the implementation of the renamed (but still
misleading) AP_MODE_EATCRLF,
AP_MODE_PEEK was more accurate, but whatever...
No, it certainly wasn't, but let's not re-open old wounds. ;-)
On Fri, Apr 15, 2005 at 10:09:39AM -0700, Justin Erenkrantz wrote:
This would save us from the extra round trip. I'm not sure where else we
could even place such a check besides ap_pass_brigade. -- justin
Thinking about this a little bit more:
There's no reason we couldn't do the following
Justin Erenkrantz wrote:
On Fri, Apr 15, 2005 at 11:56:38AM -0400, Greg Ames wrote:
the reason that this and the corresponding 1.3 BUFF logic exists is to
minimize tinygrams - ip packets that are less than a full mtu size.
tinygrams definately degrade network performance and trigger things
On April 15, 2005 11:28 am, Joe Orton wrote:
I've attached the copy of the replacement ssl_scache_shmcb.c which you
sent out for review. I have not had a chance to review or test though,
sorry.
Thanks Joe - heh, I'd forgotten how complex this code was ;-)
I'll attempt to take another look
Justin Erenkrantz wrote:
On Fri, Apr 15, 2005 at 10:09:39AM -0700, Justin Erenkrantz wrote:
This would save us from the extra round trip. I'm not sure where else we
could even place such a check besides ap_pass_brigade. -- justin
Thinking about this a little bit more:
There's no reason we
26 matches
Mail list logo
