:
signverifysign/s verify/s
rsa 1024 bits 0.0033s 0.0002s306.7 6264.2
see hacked patch below.
-dean
Date: Sun, 23 Mar 2003 22:08:25 -0800 (PST)
From: dean gaudet [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: SSE2 inner loop for bn_mul_add_words
for kicks i decided
for kicks i decided to see if it really was possible to get RSA speedups
using the SSE2 PMULUDQ and PADDQ instructions ... and i'm seeing a 30%+
1024-bit sign/s improvement on the p4 systems i've measured on.
but i'm too lazy to try to understand the perl asm generation crud, and
don't want to
i was actually getting a segfault from apt-get update on my woody system
which happens to also have testing and unstable entries in sources.list.
it was reproduceable until i went and removed those sources... now i can't
seem to get it back even after adding the sources. so treat this as a
fyi.
can anyone remember, or explain why, redirect /foo /bar isn't permitted,
but redirectmatch /foo /bar is? (i haven't looked to see if this
bizarreness is fixed in 2.0 or not.)
-dean
[a little birdie said folks were quoting me ;) hi!]
On 16 Sep 2002, Brian Pane wrote:
Linux kernel modules are a special case due to some characteristics
that don't apply to Apache:
* Most Linux kernel modules are available in source form
most are available in source form simply because
#128027 -- man pages installed in wrong directory
+ * remove the cat man pages... since it doesn't appear like any
+other packages install cat pages
+
+ -- dean gaudet [EMAIL PROTECTED] Mon, 22 Apr 2002 20:30:48 -0700
+
elm-me+ (2.4pl25ME+95-3) unstable; urgency=low
* Orphaning this package
hey -- i was just cleaning out my [EMAIL PROTECTED] mailbox (so much spam :)
and found this. it appears to be a bug i fixed in 1.3 but the fix wasn't
applied to 2.0? is there any general plan to sweep through 1.3 fixes and
merge them into 2.0?
-dean
-- Forwarded message --
Package: dpkg
Version: 1.9.19
man dpkg-deb refers to a subdirectory named DEBIAN, but the actual
subdirectory name appears to be debian.
-dean
in the past it was trivial to do a full install. now it appears to be a
royal pain in the ass -- i have to click every package and guess what
version i should be installing (the UI doesn't really make it obvious what
versions i should be installing).
a search for full install on this mailing
and trying to get a single block
to handle many common requests ...
On a thought from Dean Gaudet, how would performance be helped if
we #define'd apr_pcalloc to be:
#define apr_pcalloc(pool, size) memset(apr_palloc(pool, size), '\0', size);
When out of mem, this will segfault at the point where
fyi: in 1.3.x this used to give an informative error on linux telling the
user to recompile their kernel for sysv ipc support.
(i'm assuming ap_mm_create is a 2.0 symbol name...?)
-dean
-- Forwarded message --
Date: Tue, 20 Nov 2001 20:30:34 -0500
To: [EMAIL PROTECTED]
From:
On Sun, 18 Nov 2001, Brian Pane wrote:
Good point--it's possible to construct an O(n^2) attack with this
patch. The same is true of qsort, which is O(n^2) in the worst
case, but it's admittedly a lot harder to construct the worst-case
data set with qsort.
hmm yeah i guess that's true.
The
On Sat, 17 Nov 2001, Brian Pane wrote:
* A rewrite of apr_table_overlap() that uses a hash
table (sort of) instead of qsort
i'm not sure this part of the patch is a good idea. the reason
apr_table_overlap() uses qsort is to prevent various O(n^2) DoS attacks
(both time space). with
On Wed, 14 Nov 2001, Stipe Tolj wrote:
I have reported such hanginf keepalive childs on the Cygwin 1.x
platform.
These come up after some days of load and ussually go up to 50-60
blocked keepalive childs. Recently (after 16 days httpd uptime) the
whole scoreboard flushed and the hanging
On Sun, 4 Nov 2001, Brian Pane wrote:
3. Keep using apr_table_t for the fields in request_rec, and redesign
the internals of apr_table_t to support O(log(n)) access
whatever you do please remember to make sure you don't consume lots of
extra memory for the many tables which have only 1 or 2
On Sun, 4 Nov 2001, Brian Pane wrote:
3. Keep using apr_table_t for the fields in request_rec, and redesign
the internals of apr_table_t to support O(log(n)) access
whatever you do please remember to make sure you don't consume lots of
extra memory for the many tables which have only 1 or
On Mon, 12 Nov 2001, Ryan Bloom wrote:
I am trying to remove the network logic from the MPMs, so that modules can
implement different transport layers.
are you referring to multiplexing transport layers? 'cause what's there
already should work fine for non-multiplexed transports... i.e.
i tend to agree with greg... this all seems to be contrary to the original
MPM goals which was to provide a method of accessing the fastest and most
scalable socket - worker mapping on each platform. it looks like you're
making all the world have to function like unix.
-dean
On Tue, 13 Nov
On Tue, 13 Nov 2001, Ryan Bloom wrote:
On Tuesday 13 November 2001 04:35 pm, dean gaudet wrote:
On Mon, 12 Nov 2001, Ryan Bloom wrote:
I am trying to remove the network logic from the MPMs, so that modules
can implement different transport layers.
are you referring to multiplexing
On Fri, 9 Nov 2001, Bill Stoddard wrote:
Curious what insite Dean had into suggesting a change from SIGALRM to
SIGUSR2.
the two places the children were hanging (in PR#3906) were in places that
the parent was supposed to deliver SIGALRM. they weren't hard hangs
because the SIGHUP was
my personal opinion is that most uses of pcalloc() are just lazy
programming.
if maintainability is an issue then make a creator function or macro for
your data structures.
the only thing empirical here is that the person doing the pcalloc to
palloc change wasn't thorough enough. it doesn't
fwiw, i've never used calloc. if i really need to memset something to 0
then i do it explicitly after the allocation.
why? the reason has nothing to do with the maintainability arguments
being presented here, and has everything to do with performance.
study the following code and assembly.
On Thu, 27 Sep 2001, Brian Pane wrote:
The other big complication is that we'd need a way to avoid blocking
on disk reads if a client requests a file that isn't currently in the
filesystem cache. I guess mincore(2) would work in cases where we happen
to have the file mmap'ed, but is there a
you're misreading the RFC. spaces after the chunk-size are permitted,
look at section 2.1, Implied *LWS. the reason apache uses them is an
optimisation within the buffering routines to avoid an extra memcpy, and
this is one of the reasons the whitespace is permitted.
it's unfortunate, i would
yeah i considered that, but i don't think rr-filename can be NULL in
1.3... 'cause i don't think you can get rr-status == OK with a NULL
filename...
the only calls to ap_translate_name() which succeed are followed by
ap_directory_walk() which tests for a NULL filename and sets it to a copy
of
On Thu, 20 Sep 2001, Ian Morgan wrote:
RecvTimeout 5
This will cause any incoming request to timeout if not completed within 5
seconds. This will cause the above null connections to timeout very
quickly, thereby significantly reducing the number of wasted waiting server
instances.
so the
On Tue, 18 Sep 2001, RCHAPACH Rochester wrote:
Yes, FD_SETSIZE is defined in sys/types.h on UNIX flavored
systems. If you set it to a high enough value
(i.e. #DEFINE FD_SETSIZE 65535 ) before sys/types.h gets included,
it will override the value set in sys/types.h.
this isn't portable.
On 12 Sep 2001, Ian Holsman wrote:
What I am suggesting is to move some of these configurations to
Location / where they belong.
+1.
-dean
On Tue, 11 Sep 2001, Greg Stein wrote:
On Tue, Sep 11, 2001 at 12:06:13AM -0500, William A. Rowe, Jr. wrote:
...
where the code uses a pid (getpid()) you need to use a concatenation of
pid and thread id.
otherwise you violate some of the uniqueness guarantees.
i just didn't
On Wed, 12 Sep 2001, Günter Knauf wrote:
For NetWare I found this definition in ./netware/os.h:
#define getpid GetThreadID
and in the NetWare header nwthread.h GetThreadID() is defined as:
int GetThreadID( void );
for Win32 platform getpid() is defined in process.h:
_CRTIMP int __cdecl
On Thu, 13 Sep 2001, Brad Nicholes wrote:
I checked with our CLIB people and they tell me that GetThreadID is
*not* unique. In other words, if a thread is created, it is assigned
an ID. If that thread is terminated and a new thread is created, the
new thread may reuse the ID from the
why is there a need for 15 entries? if it's a multiprocess server then
there's only a need for 1 or 2 entries. if it's a multithreaded server
then you need to lock the cache (which you're not doing :)
isn't the real win in eliminating both the divisions required by the
explode time functions
On Thu, 30 Aug 2001, Dirk-Willem van Gulik wrote:
On Wed, 29 Aug 2001, Marc Slemko wrote:
There is nothing to test. Using the 1.3 process based model, you need
serialized accepts if you have multiple listening sockets. Period.
Unless your kernel socket or higher level accept filter's
On Tue, 28 Aug 2001, Ryan Bloom wrote:
Creating a pool requires locking a mutex. The more we scale, the worse we
perform.
a mutex is not a requirement... as i explained several months ago. (and
as greg mentioned, this patch just moves the mutex to the queue from the
pool code, which makes
On Mon, 10 Sep 2001, Brian Pane wrote:
dean gaudet wrote:
why is there a need for 15 entries? if it's a multiprocess server then
there's only a need for 1 or 2 entries. if it's a multithreaded server
then you need to lock the cache (which you're not doing :)
The whole point
On Wed, 15 Aug 2001, William A. Rowe, Jr. wrote:
. If the pool argument passed in merge_dir_configs doesn't match the base config,
it's out of scope! You must copy when the pool argument differs from the base!
. Likewise, if you are changing parts of the add config, and the add
On Tue, 4 Sep 2001, Brian Pane wrote:
* Collectively, stat and open comprise 5% of the total CPU time.
It would be faster to do open+fstat rather than stat+open (as
long as the server is delivering mostly 200s rather than 304s),
but that might be too radical a change. Anybody have
On Tue, 4 Sep 2001, Ryan Bloom wrote:
On Tuesday 04 September 2001 09:16, Justin Erenkrantz wrote:
Ryan, you may veto this commit. However, if you wish to repeal or
modify our style guide, I suggest you call a vote. -- justin
That is complete BS. We have a long standing tradition of
On Tue, 21 Aug 2001, Martin Kraemer wrote:
I don't know whether Dean Gaudet is still lurking, maybe he knows
whether there are reasons which forbid the use of the
-DNO_SEM_UNDO alternative in apache itself. I was under the
impression that nobody implemented it yet, but it would be useful
On Mon, 23 Jul 2001, Aaron Bannert wrote:
Just on a side note, I also tried to reproduce this bug with my non-SMP
rh71 (linux 2.4.3) machine, and could not.
redhat 7.1's 2.4.3 includes a lot of the patches that eventually made it
into kernels as recent as 2.4.6. this is pretty typical of
On Tue, 17 Jul 2001, Brian Pane wrote:
dean gaudet wrote:
you might want to disassemble the functions in gdb (or using objdump) to
make sure that gcc emits a single division instruction for the x / 10,
x % 10 expressions -- i forget the cases where it can and can't do this.
the low level
On Tue, 17 Jul 2001, Luke Kenneth Casson Leighton wrote:
therefore, i conclude that the dce/rpc codebase has successfully
implemented thread cancellation in their POSIX/Draft4 thread
library.
yes cancellation is in the spec. i've never denied that. the problem is
libraries and code over
On Tue, 17 Jul 2001, Justin Erenkrantz wrote:
And, from what I can tell, Dean Gaudet has mentioned this morning that
he is willing to veto async notification. Dean, would that include
cancellation of threads? I have a suspicion it might. Dean has
commit access on httpd as well, so if you
implementations of this mechanism will leak resources (aparently in the
kernel), and that is bad.
-aaron
On Tue, Jul 17, 2001 at 01:32:52AM -0700, dean gaudet wrote:
On Sat, 14 Jul 2001, Sander Striker wrote:
The way I see it, each process has a single pool instance
you might want to disassemble the functions in gdb (or using objdump) to
make sure that gcc emits a single division instruction for the x / 10,
x % 10 expressions -- i forget the cases where it can and can't do this.
the low level div instruction is a two result opcode, quotient and
remainder. if
On Tue, 17 Jul 2001, Aaron Bannert wrote:
On Tue, Jul 17, 2001 at 01:29:47AM -0700, dean gaudet wrote:
On Sun, 15 Jul 2001, Sander Striker wrote:
Why are we so desperate in opting out the child-pool creation?
I don't really have problems with a child pool for each thread. Actually
On Tue, 17 Jul 2001, William A. Rowe, Jr. wrote:
We agree. APR_INHERIT is the 'option', APR_NON_INHERIT is a zero (usual
case) value.
my complaint is that you're modifying all the handle creation APIs with
another parameter...
-dean
+1 from me too (although i don't know that i necessarily have a vote in
APR :)
-dean
On Tue, 17 Jul 2001, Justin Erenkrantz wrote:
On Tue, Jul 17, 2001 at 08:32:47PM -0500, William A. Rowe, Jr. wrote:
Then, I'm +1 on _not_ passing this as an argument to the creation fn,
rather assuming
On Sat, 14 Jul 2001 [EMAIL PROTECTED] wrote:
Having multiple processes each with multiple threads provides for FAR
more robustness than just a single process with multiple threads.
ya know, i'm not really convinced of the desirability of this explanation
anymore. maybe the hypothetical buggy
On Sat, 14 Jul 2001, Aaron Bannert wrote:
On Sat, Jul 14, 2001 at 12:10:30PM -0700, [EMAIL PROTECTED] wrote:
On Sat, 14 Jul 2001, Sander Striker wrote:
The way I see it, each process has a single pool instance as the parent
for all the threads. Resetting or destroying that pool should
On Sun, 15 Jul 2001, Sander Striker wrote:
Why are we so desperate in opting out the child-pool creation?
I don't really have problems with a child pool for each thread. Actually,
it will make the dynamic locking a lot easier to implement if it stays.
all threads MUST have their own private
On Sat, 14 Jul 2001, Sander Striker wrote:
The way I see it, each process has a single pool instance as the parent
for all the threads. Resetting or destroying that pool should effectively
kill all threads. What am I missing?
how does a thread kill another thread?
-dean
On Sat, 14 Jul 2001, Roy T. Fielding wrote:
The correct fix, as I see it, is to kill off the interprocess
accept lock by removing the possibility of having other processes
in a *threaded* MPM. -- justin
That architecture was explored in detail by Netscape. It isn't reliable
and
OS
implementations of this mechanism will leak resources (aparently in the
kernel), and that is bad.
-aaron
On Tue, Jul 17, 2001 at 01:32:52AM -0700, dean gaudet wrote:
On Sat, 14 Jul 2001, Sander Striker wrote:
The way I see it, each process has a single pool instance
you might want to disassemble the functions in gdb (or using objdump) to
make sure that gcc emits a single division instruction for the x / 10,
x % 10 expressions -- i forget the cases where it can and can't do this.
the low level div instruction is a two result opcode, quotient and
remainder.
see modules/mappers/mod_negotiation.c search for fast redirect.
no comment on how clean this is :)
it's something that should be moved to a core routine.
-dean
On Tue, 17 Jul 2001, Brian Pane wrote:
Is there anything that actually uses the
headers_out or err_headers_out fields in
the
On Tue, 17 Jul 2001, Aaron Bannert wrote:
On Tue, Jul 17, 2001 at 01:29:47AM -0700, dean gaudet wrote:
On Sun, 15 Jul 2001, Sander Striker wrote:
Why are we so desperate in opting out the child-pool creation?
I don't really have problems with a child pool for each thread. Actually
On Tue, 17 Jul 2001, William A. Rowe, Jr. wrote:
Fine... but does that mean we don't want to actually clean out the
dozens of file descriptors that aren't needed from a threaded parent
process when we spawn a child (such as a CGI)?
we do already (or we're supposed to) through all the
On Sat, 14 Jul 2001, Aaron Bannert wrote:
On Sat, Jul 14, 2001 at 12:10:30PM -0700, [EMAIL PROTECTED] wrote:
On Sat, 14 Jul 2001, Sander Striker wrote:
The way I see it, each process has a single pool instance as the parent
for all the threads. Resetting or destroying that pool should
On Sun, 15 Jul 2001, Sander Striker wrote:
Why are we so desperate in opting out the child-pool creation?
I don't really have problems with a child pool for each thread. Actually,
it will make the dynamic locking a lot easier to implement if it stays.
all threads MUST have their own private
On Sun, 8 Jul 2001, Roy T. Fielding wrote:
[clean_child_exit]
It is only called when the child exits and not per-thread. I think the
threads are already dead by that point, or locked-up due to some fatal
error that is the reason why clean_child_exit is being called.
when you say the
On Sun, 8 Jul 2001, Brian Pane wrote:
So I guess the ideal algorithm for retrieving the initial request
from a client is:
OS with working TCP_DEFER_ACCEPT or equivalent: select first, then read
OS without working TCP_DEFER_ACCEPT or equivalent: read first
isn't it the other way
On Tue, 10 Jul 2001, Dirk-Willem van Gulik wrote:
0 Change the 'exit' when the sockopt fails for SO_ACCEPTFILTER
to a warning;.
1 Leave as is; but provide an AcceptFilter on/off directive
to switch it off - if SO_ACCPETFILTER is defined.
2.Have AcceptFitler on/off
On Tue, 10 Jul 2001, Brian Pane wrote:
1. Add a 2nd create function for apr_hash_t that lets the caller
supply three callback functions:
- a hash function
- an equality-check function
- a concatenation function (if non-NULL, setting x=y followed by
x=y results
On Mon, 9 Jul 2001, Luke Kenneth Casson Leighton wrote:
HOWEVER! supporting the data types that apr_pool_xxx() USES
is a different matter.
shm can be at different memory locations in all processes. pointers don't
work. you'd need to radically change the basic data types, which would
affect
On Mon, 9 Jul 2001, Roy T. Fielding wrote:
Tables are in APR, because were originally moved from Apache to APR before
APR-util existed. They should really move to apr-util. They should never
be removed from Apache. Tables are useful because they garuantee a
general order to the data,
On 9 Jul 2001, Ian Holsman wrote:
maybe there needs to be a method of registering error numbers/functions
so that apr_sterror knows that error 1230981 is from apr-util and would
call apr-util's function it registered to show the error message.
hee!
sorry, just thinking back to discussions
On Sat, 7 Jul 2001, Bill Stoddard wrote:
On Sat, 7 Jul 2001, Brian Pane wrote:
If I'm reading the code right, there's one problem with this approach: the
APR_INCOMPLETE_READ flag doesn't get set until after the first
read on a socket, so the first read on a new connection (the
On Sun, 8 Jul 2001, dean gaudet wrote:
On Sat, 7 Jul 2001, Bill Stoddard wrote:
Humm... If you use TCP_DEFER_ACCEPT, how to you handle clients
connecting but not sending any bytes?
i'm not sure what happens if they connect and close before the timeout.
the socket is passed to accept
so while hacking up that patch to eliminate the block_freelist i thought i
could also get rid of the alloc_mutex entirely. but it appears that
currently the pool code sort of supports multithreaded access to the same
pool.
i say sort of because cleanups don't support multithreaded access -- no
On Sun, 8 Jul 2001, Roy T. Fielding wrote:
The last time I looked at the pool code it was bogus because clean_child_exit
how can clean_child_exit ever hope to work in a multithreaded server
without async notification?
in particular, what happens when modules start creating their own thread
On Sun, 8 Jul 2001, Justin Erenkrantz wrote:
Yup. I've brought this up to Sander and David before, but this is how
pools
woah. no way really?
that's not at all how it was in 1.3 or in early 2.0 ...
in 2.0 as of uh a year ago say, there was one free list per process,
and locks were used
On Sun, 8 Jul 2001, Jon Travis wrote:
I talked to rbb about this not too long ago, and he told me that you
did a lot of performance work, and that is why pools use their own
allocation scheme (8k blocks, freelists, etc.) instead of using a
total malloc() oriented scheme.
yes and no. i can't
On Sun, 8 Jul 2001, Justin Erenkrantz wrote:
Also, I did try having the pools use malloc/free directly
(ALLOC_USE_MALLOC) and the performance was dreadful. At least on
Solaris. -- justin
yes, ALLOC_USE_MALLOC is dreadful -- that's not what i meant.
what i mean is something like the below
so while hacking up that patch to eliminate the block_freelist i thought i
could also get rid of the alloc_mutex entirely. but it appears that
currently the pool code sort of supports multithreaded access to the same
pool.
i say sort of because cleanups don't support multithreaded access -- no
On Sun, 8 Jul 2001, Ian Holsman wrote:
dean gaudet wrote:
it removes block_freelist and uses malloc/free for blocks. this is much
less expensive than malloc/free on each allocation (amortization).
If you can wait till monday, and you are interested, I'll put it through
the ringer on a 8
On Sun, 8 Jul 2001, Brian Pane wrote:
dean gaudet wrote:
On Sun, 8 Jul 2001, Ian Holsman wrote:
dean gaudet wrote:
it removes block_freelist and uses malloc/free for blocks. this is much
less expensive than malloc/free on each allocation (amortization).
If you can wait till monday
i was digging around for info on TCP_DEFER_ACCEPT and found this claim in
the thttpd mailing list archive:
> Alexey Kuznestov mentioned to me that on SMP servers, this option may
> not be desired as it creates a new contention point
is this still the case?
i haven't played with it yet, but i
On Sat, 7 Jul 2001, Brian Pane wrote:
If I'm reading the code right, there's one problem with this approach: the
APR_INCOMPLETE_READ flag doesn't get set until after the first
read on a socket, so the first read on a new connection (the one that
usually
returns EAGAIN) doesn't get skipped
i was digging around for info on TCP_DEFER_ACCEPT and found this claim in
the thttpd mailing list archive:
Alexey Kuznestov mentioned to me that on SMP servers, this option may
not be desired as it creates a new contention point
is this still the case?
i haven't played with it yet, but i was
hi!
why aren't basic bit manipulations being done directly? the function call
overhead is enormous compared to the operations being performed.
also... when i saw the field named netmask i kind of assumed it was a
network address mask, which is usually what netmask refers to. why does
it appear
On Wed, 4 Jul 2001 [EMAIL PROTECTED] wrote:
On Wed, 4 Jul 2001, Ian Holsman wrote:
I'm looking at the shared memory functions (in unix), and am struggling
to find out how one can attach to
a shared memory segment already created by another process.
Currently you can't, because MM
On Sat, 7 Jul 2001, Aaron Bannert wrote:
I don't think there is any benefit to this. But, someone else might
be able to chime in and say why we need this functionality. -- justin
how do you handle out of memory?
palloc is not permitted to return NULL for performance reasons.
On Mon, 2 Jul 2001, Brian Pane wrote:
On Mon, 2 Jul 2001, Brian Pane wrote:
then it should be possible to eliminate a system call by not doing the
initial read before the select.
Here's a patch that disables the read before the select, but only for
the HTTP client socket.
hey brian, i
On Sat, 7 Jul 2001, Brian Pane wrote:
If I'm reading the code right, there's one problem with this approach: the
APR_INCOMPLETE_READ flag doesn't get set until after the first
read on a socket, so the first read on a new connection (the one that
usually
returns EAGAIN) doesn't get skipped
this is expected behaviour ... well, it may be a bug if you didn't see
this before apache 1.3.20.
a bunch of configuration info is duplicated for each VirtualHost. i
forget all the exact details now, but what you want to be careful about
are any configuration statements within the VirtualHost
On Fri, 6 Jul 2001, Harrie Hazewinkel wrote:
Attached is a patch that adds more dynamic configuration.
It places some of the MPM variables such as 'ap_max_daemons_limit',
'ap_daemons_limit', 'ap_daemons_min_free' and 'ap_daemons_max_free'
in the scoreboard.
-1.
the concept is ok, but the
On 3 Jul 2001, Jeff Trawick wrote:
dean gaudet [EMAIL PROTECTED] writes:
there should be no reason to tweak TCP_NODELAY except at socket creation
time.
on at least some levels of Linux TCP_NODELAY and TCP_CORK are mutually
exclusive...
er sorry i meant O_NDELAY, not TCP_NODELAY.
-dean
is this across loopback?
if so then it's useless for performance tuning/measurement. you gotta use
a real network, and a beefy enough client to get any meaningful results.
or is it a single 100baseT segment? if so then this is too little network
to give meaningful results as well. unless you
drivers are still under development.
anyhow, to see the difference with zero-copy enabled you'll probably need
to study idle cpu (especially if it's only 100baseT).
-dean
On Mon, 2 Jul 2001, Cliff Woolley wrote:
On Mon, 2 Jul 2001, dean gaudet wrote:
is this across loopback?
if so
On Mon, 2 Jul 2001, Cliff Woolley wrote:
static file local threaded:
No keepalives Keepalives
--
no cache 154.54 req/s 879.06 KB/s 2432.63 req/s 13924.84 KB/s
CacheFile 155.53 req/s 881.38
On Mon, 2 Jul 2001, Bill Stoddard wrote:
For example, if you have three responses to serve pipelined, each with
three file handles, how do you make all the packets go out optimally
filled?
TCP_CORK...
On Linux, can you TCP_CORK, call sendfile() x times then do an uncork
and have all the
On Mon, 2 Jul 2001, Brian Pane wrote:
dean gaudet wrote:
[...]
a mostly optimal syscall sequence for responses to a keep-alive
connection on linux should look something like:
sockfd = accept();
fcntl(sockfd, F_SETFL, O_NDELAY)
setsockopt(sockfd, TCP_CORK = 1
On Mon, 2 Jul 2001, dean gaudet wrote:
On Mon, 2 Jul 2001, Brian Pane wrote:
then it should be possible to eliminate a system call by not doing the
initial read before the select.
that sounds correct and a desirable change. i think the current behaviour
goes all the way back
On Mon, 2 Jul 2001, Sander van Zoest wrote:
Tony Finch http://www.apache.org/~fanf/ work on this and his patch,
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_usrreq.c#rev1.53
to FreeBSD 5.0-CURRENT, makes TCP_NOPUSH behave in the manner of
Linux's TCP_CORK.
woo!
that makes
On Mon, 25 Jun 2001, William A. Rowe, Jr. wrote:
One consideration, depending on module authorship, is if a module
author chooses to 'do something' in the directory merge operation,
relative to the request (uri, query elements, etc.) Does anyone know
of such a module?
the merge functions
i did something similar ages ago... and i think manoj did some followon
work to my patch. my idea was to use a wrapper much like innd uses, just
to open the socket.
if you look at http://arctic.org/~dean/apache/1.3/arctic_mods_v2.patch
and search for pre_opened_socket, permanent_listeners, and
On Sat, 23 Jun 2001 [EMAIL PROTECTED] wrote:
On Sat, 23 Jun 2001, Bill Stoddard wrote:
Just a heads up, because I know he's off-list this weekend. Will Rowe has
been looking at some of this stuff recently. He has basically re-worked
directory walk to take advantage of a lot of the
love to see a patch, especially if it can
be generalized at all!
Ryan
On Sat, 23 Jun 2001, dean gaudet wrote:
that sounds good.
it's just like constant-folding :)
can you generalise it any? Alias and mod_userdir can add more constant
factors in the path.
-dean
On Fri, 22 Jun
On Thu, 21 Jun 2001, Bill Stoddard wrote:
This can be implemented just as well with the table implementation. The
only thing you have to do is pad the scoreboard entry size to make it
equal to one cache line.
And waste more storage? I am not a CPU designer...how big are cache lines on
601 - 700 of 1643 matches
Mail list logo
