Apache Cache configuration
Dear All, I configured the Apache cache mode by following the httpd document sample. My configure is: IfModule mod_cache.c IfModule mod_mem_cache.c CacheEnable mem / CacheRoot /home/alex/apache/logs MCacheSize 4096 MCacheMaxObjectCount 1000 MCacheMinObjectSize 1 MCacheMaxObjectSize 2048 MCacheRemovalAlgorithm LRU /IfModule /IfModule Unfortunately, there is no cache in my system. And all the client requests are passed to the real server. BTW, my equipment is acted as a reverse proxy. Hope you can help me. Thanks a lot. -- View this message in context: http://www.nabble.com/Apache-Cache-configuration-tp22283418p22283418.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: Apache Cache configuration
My httpd version is 2.2.11, Is there anything wrong with that? Thanks dreamice wrote: Dear All, I configured the Apache cache mode by following the httpd document sample. My configure is: IfModule mod_cache.c IfModule mod_mem_cache.c CacheEnable mem / CacheRoot /home/alex/apache/logs MCacheSize 4096 MCacheMaxObjectCount 1000 MCacheMinObjectSize 1 MCacheMaxObjectSize 2048 MCacheRemovalAlgorithm LRU /IfModule /IfModule Unfortunately, there is no cache in my system. And all the client requests are passed to the real server. BTW, my equipment is acted as a reverse proxy. Hope you can help me. Thanks a lot. -- View this message in context: http://www.nabble.com/Apache-Cache-configuration-tp22283418p22283424.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: Apache Cache configuration
dreamice wrote: I configured the Apache cache mode by following the httpd document sample. My configure is: IfModule mod_cache.c IfModule mod_mem_cache.c CacheEnable mem / CacheRoot /home/alex/apache/logs MCacheSize 4096 MCacheMaxObjectCount 1000 MCacheMinObjectSize 1 MCacheMaxObjectSize 2048 MCacheRemovalAlgorithm LRU /IfModule /IfModule Unfortunately, there is no cache in my system. And all the client requests are passed to the real server. You're using the memory cache, so you're not going to find any cache on disk (I am assuming you expect to find it at /home/alex/apache/logs?). You're probably looking for the disk cache instead. Also, make sure your content is cacheable in the first place. Many application servers put cache control headers in that ask caches not to cache, and httpd will respect these headers. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: uninstall Makefile target
I see. Will be factible to implement these uninstall target using the method you use? Regards. 2009/2/26 Graham Leggett minf...@sharp.fm Alfonso Ruzafa Molina wrote: I noticed Apache uses autotools to be built. Since uninstall is a standard target in autotools, why that isn't available? It's seems like it would be override deliberately. Sometimes when by mistake I use --prefix=/usr and the files are installed in that path I just can't remove the lib, include, bin... directories because these contains other files. Why uninstall has been removed? uninstall was never removed, it was just never there in the first place. The uninstall target is typically put there by automake, and httpd has never used automake (or not to my knowledge anyway). Regards, Graham -- -- -= http://www.legadodekain.net =-
Re: Apache Cache configuration
Dear Graham, Thanks for your reply. Yes, I am using mem cache. When I test this case, I find that the client's request is directly passed to the real server. As I test the disk mode, there is also no data cached on my directory. I dont know why. Could any one come across with this case? The reverse proxy mode. Thanks Graham Leggett wrote: dreamice wrote: I configured the Apache cache mode by following the httpd document sample. My configure is: IfModule mod_cache.c IfModule mod_mem_cache.c CacheEnable mem / CacheRoot /home/alex/apache/logs MCacheSize 4096 MCacheMaxObjectCount 1000 MCacheMinObjectSize 1 MCacheMaxObjectSize 2048 MCacheRemovalAlgorithm LRU /IfModule /IfModule Unfortunately, there is no cache in my system. And all the client requests are passed to the real server. You're using the memory cache, so you're not going to find any cache on disk (I am assuming you expect to find it at /home/alex/apache/logs?). You're probably looking for the disk cache instead. Also, make sure your content is cacheable in the first place. Many application servers put cache control headers in that ask caches not to cache, and httpd will respect these headers. Regards, Graham -- -- View this message in context: http://www.nabble.com/Apache-Cache-configuration-tp22283418p22286836.html Sent from the Apache HTTP Server - Dev mailing list archive at Nabble.com.
Re: patch for handling headers_in and headers_out as tables in mod_lua
On 2/28/09 8:37 PM, Brian McCallister bri...@skife.org wrote: It could be just: apr_hash_set(dispatch, document_root, APR_HASH_KEY_STRING, makefun(req_content_encoding_field, APL_REQ_FUNTYPE_STRING, p)); Also, couldn't we build the dispatch has once, and only once, and then just associated it with each apache2.request? This seems more efficient than building this array every time. It would also be nice to use a dispatch hash for setters as well. --Brian
Re: mod_wombat and mod_lua
On 2/27/09 2:56 PM, Brian McCallister bri...@skife.org wrote: Maybe virtually joining :-) It maybe interesting to have a virtual extension to the hackathon. IRC is good, but misses a lot of discussion I think. Some actual voice interaction would be nice. I've see you all before, so I don't really want video :P Thoughts? I'd really like to get mod_lua standardized, fast, and in 2.2, if possible (or get 2.4 out very soon). Willing to help, just let me know how. --Brian
[PATCH] fix recognition of APR 2.x
Check out trunk. Check out APR trunk and APR-Util trunk into srclib/apr and
srclib/apr-util. ./configure --with-included-apr. See error messages
containing apr-1-config scroll by.
trunk/configure.in looks for apr-2-config, but it does so before srclib/apr
is configured, when apr-2-config doesn't exist (unless the user configures
srclib/apr first).
The attached patch checks the version after the configure. It also attempts
to handle the APR_FIND_APR() path (untested). On the APR-Util side, it
bases the apu-config path on the APR major version and tells APR_FIND_APU()
to find one that matches APR's major version (latter part untested).
I wouldn't be at all surprised if other folks are already using APR trunk
with httpd trunk daily and I've missed something basic, so comments
appreciated ;)
Index: configure.in
===
--- configure.in(revision 749280)
+++ configure.in(working copy)
@@ -73,18 +73,10 @@
AC_ARG_WITH(included-apr,
APACHE_HELP_STRING(--with-included-apr,Use bundled copies of APR/APR-Util))
-# Default to APR 1.x
-apr_version=1
-
if test x$with_included_apr = xyes; then
- # accept a bundled APR 2.x
- if test -f $srcdir/srclib/apr/apr-2-config; then
- apr_version=2
- fi
apr_found=reconfig
- apr_config=$srcdir/srclib/apr/apr-${apr_version}-config
else
- APR_FIND_APR($srcdir/srclib/apr, ./srclib/apr, 1, ${apr_version})
+ APR_FIND_APR($srcdir/srclib/apr, ./srclib/apr, 1, 1 2)
fi
if test $apr_found = no; then
@@ -98,6 +90,14 @@
dnl We must be the first to build and the last to be cleaned
AP_BUILD_SRCLIB_DIRS=apr $AP_BUILD_SRCLIB_DIRS
AP_CLEAN_SRCLIB_DIRS=$AP_CLEAN_SRCLIB_DIRS apr
+
+ dnl We have to find apr-N-config when we reconfigure APR.
+ for majorver in 1 2; do
+test_apr_config=$srcdir/srclib/apr/apr-${majorver}-config
+if test -f $test_apr_config; then
+ apr_config=$test_apr_config
+fi
+ done
fi
APR_SETIFNULL(CC, `$apr_config --cc`)
@@ -110,22 +110,15 @@
APR_INCLUDEDIR=`$apr_config --includedir`
APR_INCLUDES=`$apr_config --includes`
APR_VERSION=`$apr_config --version`
-APR_CONFIG=$APR_BINDIR/apr-`echo ${APR_VERSION} | sed 's,\..*,,'`-config
+apr_major_version=`echo ${APR_VERSION} | sed 's,\..*,,'`
+APR_CONFIG=$APR_BINDIR/apr-${apr_major_version}-config
echo $ac_n ${nl}Configuring Apache Portable Runtime Utility library...${nl}
-# Default to APR-util 1.x
-apu_version=1
-
if test x$with_included_apr = xyes; then
- # accept a bundled APU 2.x
- if test -f $srcdir/srclib/apr-util/apu-2-config; then
- apu_version=2
- fi
apu_found=reconfig
- apu_config=${srcdir}/srclib/apr-util/apu-${apu_version}-config
else
- APR_FIND_APU($srcdir/srclib/apr-util, ./srclib/apr-util, 1,
${apu_version})
+ APR_FIND_APU($srcdir/srclib/apr-util, ./srclib/apr-util, 1,
${apr_major_version})
fi
if test $apu_found = no; then
@@ -149,6 +142,8 @@
dnl We must be the last to build and the first to be cleaned
AP_BUILD_SRCLIB_DIRS=$AP_BUILD_SRCLIB_DIRS apr-util
AP_CLEAN_SRCLIB_DIRS=apr-util $AP_CLEAN_SRCLIB_DIRS
+ dnl APR and APR-Util major versions must match
+ apu_config=${srcdir}/srclib/apr-util/apu-${apr_major_version}-config
fi
APR_ADDTO(LDFLAGS, `$apu_config --ldflags`)
Re: patch for handling headers_in and headers_out as tables in mod_lua
-- Please forgive typos, sent from phone. On Mar 2, 2009, at 5:34 AM, Brian Akins br...@akins.org wrote: On 2/28/09 8:37 PM, Brian McCallister bri...@skife.org wrote: It could be just: apr_hash_set(dispatch, document_root, APR_HASH_KEY_STRING, makefun(req_content_encoding_field, APL_REQ_FUNTYPE_STRING, p)); Also, couldn't we build the dispatch has once, and only once, and then just associated it with each apache2.request? This seems more efficient than building this array every time. It would also be nice to use a dispatch hash for setters as well. Agreed. I'm thinking we can store the dispatch tables on the server conf, that way we can allow them to be modified. --Brian
Re: [PATCH] fix recognition of APR 2.x
Jeff Trawick wrote: I wouldn't be at all surprised if other folks are already using APR trunk with httpd trunk daily and I've missed something basic, so comments appreciated ;) Right, I hand-crafted this, so you have my +1 Anyhow, what about making some release apr-2 dependent so we can use apr-2 API. Don't think it's very smart to #ifdef the code. Regards -- ^(TM)
Re: [PATCH] fix recognition of APR 2.x
Jeff Trawick wrote: Check out trunk. Check out APR trunk and APR-Util trunk into srclib/apr and srclib/apr-util. ./configure --with-included-apr. See error messages containing apr-1-config scroll by. Just so you are aware, list consensus has it that apr-util falls off of trunk and becomes part of apr. So I'd suggest this is a temporary condition... fixing apr-util isn't really an interesting exercise ;-) I wouldn't be at all surprised if other folks are already using APR trunk with httpd trunk daily and I've missed something basic, so comments appreciated ;) APR-trunk is not 2.0.0 yet, so that's a serious problem. If other folks are a handful of developers, it's not a problem, but it should push us to make this transition. If someone is shipping apr trunk, that's a big mistake (theirs, not ours, we'll still ship the true apr 2.0 at some point which will be grossly incompatible to such one-offs). Part of this is the desire by Paul to move the project to scons. I'm prepared to merge the autoconf, but it's a bit more than an evening project to combine apr and apr-util. His hope was that scons is ready.
additional lbmethods in mod_proxy_balancer
Hi everyone!
I'm desperately trying to implement an additional loadbalancing
algorithm. Did anyone succeeded in declaring own methods?
The httpd-users-list did not give any reply, so I'll try it here once
again.
I'm not able to find the error since I adapted the major part from the
original. After patching and compiling my 2.2.11, the standard methods
still work fine, but mine does not seem to exist:
My error is:
ProxySet: unknown lbmethod lbmethod=byfoobar
I changed the mod_proxy_balancer.c three times, as required:
I added my function:
static proxy_worker *find_best_byfoobar(proxy_balancer *balancer,
request_rec *r)
I added the struct:
static const proxy_balancer_method byfoobar =
{
byfoobar,
find_best_byfoobar,
NULL
};
And I finally registered it by inserting:
ap_register_provider(p, PROXY_LBMETHOD, byfoobar, 0, byfoobar);
in the
static void ap_proxy_balancer_register_hook(apr_pool_t *p)
Very strange, since I did everything exactly in the same way as it had
been done for the built-in methods.
Hoping that I'm posting to the right list
and
Thanks in advance,
Florian Schröder
Re: [PATCH] fix recognition of APR 2.x
On Mon, Mar 2, 2009 at 10:31 AM, William A. Rowe, Jr. wr...@rowe-clan.netwrote: Jeff Trawick wrote: Check out trunk. Check out APR trunk and APR-Util trunk into srclib/apr and srclib/apr-util. ./configure --with-included-apr. See error messages containing apr-1-config scroll by. Just so you are aware, list consensus has it that apr-util falls off of trunk and becomes part of apr. So I'd suggest this is a temporary condition... fixing apr-util isn't really an interesting exercise ;-) No concerns here... The precious few new APR-Util lines in the patch will get chopped off with the rest of that block when that happens. (I'll commit before long unless somebody who has it working now with APR trunk has a suggestion.)
Re: additional lbmethods in mod_proxy_balancer
What's you balancer configuration leading to the cited error?
On 02.03.2009 16:34, Florian S. wrote:
Hi everyone!
I'm desperately trying to implement an additional loadbalancing
algorithm. Did anyone succeeded in declaring own methods?
The httpd-users-list did not give any reply, so I'll try it here once
again.
I'm not able to find the error since I adapted the major part from the
original. After patching and compiling my 2.2.11, the standard methods
still work fine, but mine does not seem to exist:
My error is:
ProxySet: unknown lbmethod lbmethod=byfoobar
I changed the mod_proxy_balancer.c three times, as required:
I added my function:
static proxy_worker *find_best_byfoobar(proxy_balancer *balancer,
request_rec *r)
I added the struct:
static const proxy_balancer_method byfoobar =
{
byfoobar,
find_best_byfoobar,
NULL
};
And I finally registered it by inserting:
ap_register_provider(p, PROXY_LBMETHOD, byfoobar, 0,byfoobar);
in the
static void ap_proxy_balancer_register_hook(apr_pool_t *p)
Very strange, since I did everything exactly in the same way as it had
been done for the built-in methods.
Hoping that I'm posting to the right list
and
Thanks in advance,
Florian Schröder
Re: additional lbmethods in mod_proxy_balancer
Hi,
First, thanks for your reply.
Here the outline of my config:
VirtualHost *:1234
# [...]
ProxyPass / balancer://lb/
ProxyPassReverse / balancer://lb/
/VirtualHost
Proxy balancer://lb
# That works fine:
ProxySet lbmethod=byrequests
# This would lead to the error I mentioned:
#ProxySet lbmethod=byfoobar
# And several members:
BalancerMember http://xxx.xxx.xxx.xxx loadfactor=1
ProxyHTMLURLMap http://xxx.xxx.xxx.xxx http://yyy.yyy.yyy.yyy:1234
Header edit Location ^http://xxx.xxx.xxx.xxx
http://yyy.yyy.yyy.yyy:1234
/Proxy
It could look like that my changes were lost during the entire build
process. But I checked after the configuring that the patch had been
applied. Compiling runs without any issues.
Thanks in advance,
Florian Schröder
Am Montag, den 02.03.2009, 17:46 +0100 schrieb Rainer Jung:
What's you balancer configuration leading to the cited error?
On 02.03.2009 16:34, Florian S. wrote:
Hi everyone!
I'm desperately trying to implement an additional loadbalancing
algorithm. Did anyone succeeded in declaring own methods?
The httpd-users-list did not give any reply, so I'll try it here once
again.
I'm not able to find the error since I adapted the major part from the
original. After patching and compiling my 2.2.11, the standard methods
still work fine, but mine does not seem to exist:
My error is:
ProxySet: unknown lbmethod lbmethod=byfoobar
I changed the mod_proxy_balancer.c three times, as required:
I added my function:
static proxy_worker *find_best_byfoobar(proxy_balancer *balancer,
request_rec *r)
I added the struct:
static const proxy_balancer_method byfoobar =
{
byfoobar,
find_best_byfoobar,
NULL
};
And I finally registered it by inserting:
ap_register_provider(p, PROXY_LBMETHOD, byfoobar, 0,byfoobar);
in the
static void ap_proxy_balancer_register_hook(apr_pool_t *p)
Very strange, since I did everything exactly in the same way as it had
been done for the built-in methods.
Hoping that I'm posting to the right list
and
Thanks in advance,
Florian Schröder
Re: [PATCH] fix recognition of APR 2.x
On Mon, Mar 2, 2009 at 11:07 AM, Jeff Trawick traw...@gmail.com wrote: (I'll commit before long unless somebody who has it working now with APR trunk has a suggestion.) Just confirmed that my changes were dead code with a clean tree, so no squeak here. -- Eric Covener cove...@gmail.com
Re: [PATCH] fix recognition of APR 2.x
On Mon, Mar 2, 2009 at 12:23 PM, Eric Covener cove...@gmail.com wrote: On Mon, Mar 2, 2009 at 11:07 AM, Jeff Trawick traw...@gmail.com wrote: (I'll commit before long unless somebody who has it working now with APR trunk has a suggestion.) Just confirmed that my changes were dead code with a clean tree, so no squeak here. thanks!
Re: additional lbmethods in mod_proxy_balancer
On 02.03.2009 18:02, Florian S. wrote:
Hi,
First, thanks for your reply.
Here the outline of my config:
VirtualHost *:1234
# [...]
ProxyPass / balancer://lb/
ProxyPassReverse / balancer://lb/
/VirtualHost
Proxy balancer://lb
# That works fine:
ProxySet lbmethod=byrequests
# This would lead to the error I mentioned:
#ProxySet lbmethod=byfoobar
# And several members:
BalancerMember http://xxx.xxx.xxx.xxx loadfactor=1
ProxyHTMLURLMap http://xxx.xxx.xxx.xxx http://yyy.yyy.yyy.yyy:1234
Header edit Location ^http://xxx.xxx.xxx.xxx
http://yyy.yyy.yyy.yyy:1234
/Proxy
It could look like that my changes were lost during the entire build
process. But I checked after the configuring that the patch had been
applied. Compiling runs without any issues.
Indeed, it works for me (tested with 2.2.11 on Solaris using gcc).
I used exactly your code lines:
Here's a patch format:
--- mod_proxy_balancer.c.orig 2008-12-07 19:06:34.0 +0100
+++ mod_proxy_balancer.c2009-03-02 17:58:57.0 +0100
@@ -1210,6 +1210,89 @@
}
+static proxy_worker *find_best_byfoobar(proxy_balancer *balancer,
+request_rec *r)
+{
... now copied in the contents of find_best_bybusyness
and replaced busyness by foobar in the log messages ...
+}
+
/*
* How to add additional lbmethods:
* 1. Create func which determines best candidate worker
@@ -1237,6 +1320,13 @@
NULL
};
+static const proxy_balancer_method byfoobar =
+{
+byfoobar,
+find_best_byfoobar,
+NULL
+};
+
static void ap_proxy_balancer_register_hook(apr_pool_t *p)
{
@@ -1255,6 +1345,7 @@
ap_register_provider(p, PROXY_LBMETHOD, bytraffic, 0, bytraffic);
ap_register_provider(p, PROXY_LBMETHOD, byrequests, 0,
byrequests);
ap_register_provider(p, PROXY_LBMETHOD, bybusyness, 0,
bybusyness);
+ap_register_provider(p, PROXY_LBMETHOD, byfoobar, 0, byfoobar);
}
module AP_MODULE_DECLARE_DATA proxy_balancer_module = {
It compiles and works, I can see in the DEBUG log line, that it is using
the correct method.
To check whether foobar is in the compiled module, I did:
% nm ./.libs/mod_proxy_balancer.so|grep foobar
[59]| 90348| 12|OBJT |LOCL |0|23 |byfoobar
[217] | 6696| 616|FUNC |LOCL |0|12 |find_best_byfoobar
So at least I can see, that the symbols are in there. You can check the
same with your build result.
Regards,
Rainer
Am Montag, den 02.03.2009, 17:46 +0100 schrieb Rainer Jung:
What's you balancer configuration leading to the cited error?
On 02.03.2009 16:34, Florian S. wrote:
Hi everyone!
I'm desperately trying to implement an additional loadbalancing
algorithm. Did anyone succeeded in declaring own methods?
The httpd-users-list did not give any reply, so I'll try it here once
again.
I'm not able to find the error since I adapted the major part from the
original. After patching and compiling my 2.2.11, the standard methods
still work fine, but mine does not seem to exist:
My error is:
ProxySet: unknown lbmethod lbmethod=byfoobar
I changed the mod_proxy_balancer.c three times, as required:
I added my function:
static proxy_worker *find_best_byfoobar(proxy_balancer *balancer,
request_rec *r)
I added the struct:
static const proxy_balancer_method byfoobar =
{
byfoobar,
find_best_byfoobar,
NULL
};
And I finally registered it by inserting:
ap_register_provider(p, PROXY_LBMETHOD, byfoobar, 0,byfoobar);
in the
static void ap_proxy_balancer_register_hook(apr_pool_t *p)
Very strange, since I did everything exactly in the same way as it had
been done for the built-in methods.
Hoping that I'm posting to the right list
and
Thanks in advance,
Florian Schröder
Re: svn commit: r749375 - /httpd/httpd/trunk/configure.in
traw...@apache.org wrote: Author: trawick Date: Mon Mar 2 17:40:33 2009 New Revision: 749375 URL: http://svn.apache.org/viewvc?rev=749375view=rev Log: improve acceptance of APR/APR-Util trunk/2.0-dev On my other comment earlier... -1 on this patch appearing in any alpha candidate of 1.3 yet, for the reasons I mentioned before. If it's sitting on trunk, that's fine, we'll just break things again as 2.0 nears release. Bill
Re: svn commit: r749375 - /httpd/httpd/trunk/configure.in
William A. Rowe, Jr. wrote: traw...@apache.org wrote: Author: trawick Date: Mon Mar 2 17:40:33 2009 New Revision: 749375 URL: http://svn.apache.org/viewvc?rev=749375view=rev Log: improve acceptance of APR/APR-Util trunk/2.0-dev On my other comment earlier... -1 on this patch appearing in any alpha candidate of 1.3 yet, for the reasons I mentioned before. If it's sitting on trunk, that's fine, we'll just break things again as 2.0 nears release. I meant - an alpha candidate of 2.3 yet ;-) My point being, due to the API contracts in APR, we should not be encouraging alpha testers to install 2.0. 1.3 is current and 1.4 branch exists for bleeding stuff. Bill
Re: svn commit: r749375 - /httpd/httpd/trunk/configure.in
On Mon, Mar 2, 2009 at 1:19 PM, William A. Rowe, Jr. wr...@rowe-clan.netwrote: William A. Rowe, Jr. wrote: traw...@apache.org wrote: Author: trawick Date: Mon Mar 2 17:40:33 2009 New Revision: 749375 URL: http://svn.apache.org/viewvc?rev=749375view=rev Log: improve acceptance of APR/APR-Util trunk/2.0-dev On my other comment earlier... -1 on this patch appearing in any alpha candidate of 1.3 yet, for the reasons I mentioned before. If it's sitting on trunk, that's fine, we'll just break things again as 2.0 nears release. I meant - an alpha candidate of 2.3 yet ;-) My point being, due to the API contracts in APR, we should not be encouraging alpha testers to install 2.0. 1.3 is current and 1.4 branch exists for bleeding stuff. Bill I certainly agree for httpd 2.4. It is worth stating in the alpha announcements which apr level(s) they are intended to be used with. I doubt many people will worry if the alphas have code that enforces that, or fails haphazardly with other levels, or actually builds with other levels, as long as it works with the documented level(s).
Re: svn commit: r749438 - in /httpd/httpd/trunk: CHANGES support/ab.c
On Mon, Mar 2, 2009 at 4:17 PM, traw...@apache.org wrote: Author: trawick Date: Mon Mar 2 21:17:43 2009 New Revision: 749438 URL: http://svn.apache.org/viewvc?rev=749438view=rev Log: ab: Fix maintenance of the pollset to resolve EINPROGRESS errors with kqueue (BSD/OS X) and excessive CPU with event ports (Solaris). I tested with APR trunk on Linux and OpenSolaris, and APR 1.4.x on OS X. Slightly more CPU is now consumed with the select() backend on Linux and OpenSolaris (not surprising, since that backend didn't need the pollset to be so carefully maintained). There's probably similar degradation with poll(), but it seemed a tossup in my casual checks of system and user space CPU. It looked to me that less CPU is now used with the epoll backend. The former excessive CPU with event ports was so by a factor of 4 or 5, almost all in user space. Thanks to Mladen for drastically reducing the number of required builds for testing different pollset backends! I get a small percentage of length mismatches on OS X with keepalive mode, but that happens for me with the 2.0.x branch on OS X as well. I also see an occasional timeout failure on OS X. https was only lightly tested. (I don't really like ab beyond the fact that it is always in reach, but it was a nice pollset testcase.)
