RE: [PATCH] Add mod_gz to httpd-2.0
From: Peter J. Cranstone [mailto:[EMAIL PROTECTED]] Kiss my ass... *delurk* That'll motivate three +1's for mod_gz real quick. :^) (No need for anyone to reply. Just cluttering the list with sophomoric humor.) -Charels
RE: [PATCH] hash table for registered filter list
What type of performance improvements did you see with this (under what
workload)?
Charels
-Original Message-
From: Brian Pane [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 03, 2001 11:50 PM
To: [EMAIL PROTECTED]
Subject: [PATCH] hash table for registered filter list
The ap_add_input_filter/ap_add_output_filter functions do an O(n) scan
through the list of registered filters. This patch replaces the linear
list with a hash table for better performance.
--Brian
Index: server/util_filter.c
===
RCS file: /home/cvspublic/httpd-2.0/server/util_filter.c,v
retrieving revision 1.65
diff -u -r1.65 util_filter.c
--- server/util_filter.c2001/08/30 05:25:311.65
+++ server/util_filter.c2001/09/04 05:42:17
@@ -54,16 +54,18 @@
#define APR_WANT_STRFUNC
#include apr_want.h
+#include apr_lib.h
+#include apr_hash.h
+#include apr_strings.h
#include httpd.h
#include http_log.h
#include util_filter.h
/* ### make this visible for direct manipulation?
- * ### use a hash table
*/
-static ap_filter_rec_t *registered_output_filters = NULL;
-static ap_filter_rec_t *registered_input_filters = NULL;
+static apr_hash_t *registered_output_filters = NULL;
+static apr_hash_t *registered_input_filters = NULL;
/* NOTE: Apache's current design doesn't allow a pool to be passed thu,
so we depend on a global to hold the correct pool
@@ -92,16 +94,21 @@
static void register_filter(const char *name,
ap_filter_func filter_func,
ap_filter_type ftype,
-ap_filter_rec_t **reg_filter_list)
+apr_hash_t **reg_filter_set)
{
ap_filter_rec_t *frec = apr_palloc(FILTER_POOL, sizeof(*frec));
-frec-name = name;
+if (!*reg_filter_set) {
+*reg_filter_set = apr_hash_make(FILTER_POOL);
+}
+
+frec-name = apr_pstrdup(FILTER_POOL, name);
+ap_str_tolower((char *)frec-name);
frec-filter_func = filter_func;
frec-ftype = ftype;
+frec-next = NULL;
-frec-next = *reg_filter_list;
-*reg_filter_list = frec;
+apr_hash_set(*reg_filter_set, frec-name, APR_HASH_KEY_STRING, frec);
apr_pool_cleanup_register(FILTER_POOL, NULL, filter_cleanup,
apr_pool_cleanup_null);
}
@@ -126,12 +133,26 @@
static ap_filter_t *add_any_filter(const char *name, void *ctx,
request_rec *r, conn_rec *c,
- ap_filter_rec_t *frec,
+ apr_hash_t *reg_filter_set,
ap_filter_t **r_filters,
ap_filter_t **c_filters)
{
-for (; frec != NULL; frec = frec-next) {
-if (!strcasecmp(name, frec-name)) {
+if (reg_filter_set) {
+ap_filter_rec_t *frec;
+int len = strlen(name);
+int size = len + 1;
+char name_lower[size];
+char *dst = name_lower;
+const char *src = name;
+
+/* Normalize the name to all lowercase to match
register_filter() */
+do {
+*dst++ = apr_tolower(*src++);
+} while (--size);
+
+frec = (ap_filter_rec_t *)apr_hash_get(reg_filter_set,
+ name_lower, len);
+if (frec) {
apr_pool_t *p = r ? r-pool : c-pool;
ap_filter_t *f = apr_pcalloc(p, sizeof(*f));
ap_filter_t **outf = r ? r_filters : c_filters;
RE: Bandwidth control
As you point out, that level of granularity isn't available with general purpose traffic shaping tools. You may want to look at the Zeus server to understand the features that were product-worthy as one example. It appears that they've only implemented this at the virtual server level. As you're probably aware, thttpd also provides flexible bandwidth throttling, http://www.acme.com/software/thttpd/thttpd_man.html#THROTTLING Charles -Original Message- From: Alex Stewart [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 30, 2001 5:53 PM To: [EMAIL PROTECTED] Subject: Re: Bandwidth control Charles Randall wrote: Often times, this can be done easier at the OS level. What OS are you using? Linux, and I am aware of various kernel-level controls for traffic shaping, etc, however if you can tell me how to enforce different bandwidth limits for different name-based vhosts, different directories, etc, then I'm all ears, but I suspect I can also give you pretty good reasons why even if such decisions could somehow be done at the OS level, they really shouldn't be. -alex
RE: [PATCH] RE: make distclean doesn't
From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]] FWIW, we should not remove the config.nice files or certain generated files (exports.c seems to come to mind) under any circumstances. We also don't remove build.mk because it is like a Makefile (which we don't seem to remove). Hmm. Am I the only one who assumes that make distclean is supposed to return the directory structure to the state of distribution? Does anyone else have thoughts on this? Charles
RE: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page
Is that always true? For example, expat is not compiled with those flags. -Original Message- From: Roy T. Fielding [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 29, 2001 7:08 PM To: [EMAIL PROTECTED] Subject: Re: 2.0.25 on FreeBSD 4.2-R -- 404 returns text/plain error page As a side note, some portions of the code are compiled with -D_REENTRANT -D_THREAD_SAFE even when building using the prefork mpm. Why? Doesn't that have the potential to do the wrong thing on some platforms? No, it would do the wrong thing if they were not defined. They are required for the entire executable if any part of the exec has been compiled with those flags. In our case, since modules like PHP and others will be compiled with those flags, we must always compile with those flags or mod_php's return values for errno won't be correctly interpreted by the httpd core (a problem that was fixed in some version of 1.3.x by always setting those flags on platforms that support it). Roy
