From mcd at daviesinc.com Thu Nov 4 06:07:39 2004 From: mcd at daviesinc.com (Chris Davies) Date: Thu, 04 Nov 2004 01:07:39 -0500 Subject: Strange Bug with compression=1 Message-ID: <1099548459.2748.53.camel@mcdlp.pbi.daviesinc.com> I was testing something that I wrote over the weekend and when I put it on a server running tux, something odd happened. Escape character is '^]'. GET / HTTP/1.0 Host: domain.com Accept-Encoding: gzip,deflate HTTP/1.1 200 OK Content-Type: text/html Date: Thu, 04 Nov 2004 05:49:45 GMT Content-Encoding: gzip Server: TUX/2.0 (Linux) Content-Length: 3204 [compressed data here] -rw-r--r-- 1 daviesinc daviesinc 3204 Nov 3 16:50 index.html -rwxrwxrwx 1 daviesinc daviesinc 1411 Nov 3 16:50 index.html.gz It appears that tux is sending the Content-Length of the uncompressed file, even though it is sending the compressed file. tux3-2.4.27-A3.diff Can someone point us in the direction of where this is set? Based on the patch dates, it appears that we are running the latest 2.4 patch, but, I thought I had seen a bug report somewhere that dealt with this in the 2.6 patchset. Thanks! From ahodgson at simkin.ca Thu Nov 4 15:41:53 2004 From: ahodgson at simkin.ca (Alan Hodgson) Date: Thu, 4 Nov 2004 07:41:53 -0800 Subject: Strange Bug with compression=1 In-Reply-To: <1099548459.2748.53.camel@mcdlp.pbi.daviesinc.com> References: <1099548459.2748.53.camel@mcdlp.pbi.daviesinc.com> Message-ID: <20041104154153.GA12111@simkin.ca> On Thu, Nov 04, 2004 at 01:07:39AM -0500, Chris Davies wrote: > Can someone point us in the direction of where this is set? Based on > the patch dates, it appears that we are running the latest 2.4 patch, > but, I thought I had seen a bug report somewhere that dealt with this in > the 2.6 patchset. I had to fix this in an RHEL kernel recently, it's in the following bit of code: /* * Content-Length: */ if (!req->lookup_dir) { if (tux_noid) COPY_STATIC_PART(3BX, curr); else COPY_STATIC_PART(3BY, curr); if (partial) curr += sprintf(curr, "%Ld", req->output_len); else { + if (req->content_gzipped) + curr += sprintf(curr, "%Ld", req->total_file_len); + else { memcpy(curr, &req->etag, req->lendigits); curr += req->lendigits; + } } if (tux_generate_etags && (req->status != 404)) -- "Windows XP is the most reliable Windows ever. To me, this is like saying that asparagus is ``the most articulate vegetable ever.'' But still, I am tempted." - Dave Barry From mcd at daviesinc.com Thu Nov 4 17:25:44 2004 From: mcd at daviesinc.com (Chris Davies) Date: Thu, 04 Nov 2004 12:25:44 -0500 Subject: Checking performance with tux/apache, tux, apache Message-ID: <1099589144.2000.51.camel@mcdlp.pbi.daviesinc.com> Linux Kernel 2.4.27-A3 Tux 3.0 userland Apache 1.3 two machines connected via 100 TX full duplex private LAN on Cisco Cat 2948g-l3. This weekend while working with Tux on another machine I noticed a very strange trait. While it didn't make a lot of sense at the time, I chalked it up to my wifi network and benchmarks run at home on a 'less than perfect' setup. But, something just didn't feel right. With a site with a standard page, I run ab 10 times in a row with the same parameters and take the average of the last 5 runs. ab -n 1000 -c 20 http://url.com/ ab -n 1000 -c 20 http://url.com/? (to send it to the backend) Tux consistently performs around 2400 transactions per second Apache fairly consistently performs around 960 transactions per second However, Tux handing the request to the backend can barely manage 280 transactions per second. Apache2-prefork as a backend managed 330 tps and Apache2-mpm-worker handled about 400 tps. Conversely, Apache2-prefork handled 1240 tps and Apache2-mpm-worker handled 1225 tps when acting as the frontend. Keepalives seemed to make no real difference in any of the results. Even -n 10000 -c 50 made little difference to apache, but Tux actually served even faster. Passing to the backend with -n 10000 -c 50 really made little difference compared to the prior results for each run of Apache on the backend. Granted there should be some overhead to handing the request to the backend, but that is a considerable performance hit -- its a little more than 3x slower for any request that needs to be handed to the backend. I'll redo the testing using Tux 2.6, but cannot deploy with 2.6 currently. I don't recall there being this much separation before -- I thought I remmebered a difference of 50-100 transactions per second for requests handed to the backend. sysctl.tux net/tux/virtual_server = 1 net/tux/clientport = 81 net/tux/referer_logging = 1 net/tux/compression = 0 net/tux/logging = 0 net/tux/max_keepalives = 1000 net/tux/keepalive_timeout = 30 net/tux/nonagle = 0 net/tux/TDprintk = 0 net/tux/Dprintk = 0 # these do seem to make it faster net/tux/generate_cache_control = 1 net/tux/generate_etags = 1 net/tux/generate_last_mod = 0 net/tux/defer_accept = 0 From mcd at daviesinc.com Mon Nov 8 21:32:31 2004 From: mcd at daviesinc.com (Chris Davies) Date: Mon, 08 Nov 2004 16:32:31 -0500 Subject: charset Message-ID: <1099949551.2978.4.camel@mcdlp.pbi.daviesinc.com> I've looked through the documentation, and I know that you can set extra headers for the expire time, but is there a way to set the charset for documents served text/html ? From mcd at daviesinc.com Sat Nov 13 05:35:58 2004 From: mcd at daviesinc.com (Chris Davies) Date: Sat, 13 Nov 2004 00:35:58 -0500 Subject: 301 redirect Message-ID: <1100324158.2080.13.camel@mcdlp.pbi.daviesinc.com> What part of the code should I look at to get the 301 redirect that tux does to be sent to the backend rather than the continual redirects? i.e. /var/www/domain.com if someone surfs http://wwww.domain.com (note the extra w), since we have the wildcard dns entry, they get a redirect to http://wwww.domain.com/ http://wwww.domain.com// http://wwww.domain.com/// http://wwww.domain.com//// http://wwww.domain.com///// http://wwww.domain.com////// http://wwww.domain.com/////// etc any way to pass that directly to the backend for the backend to handle? As it is, the user gets a redirect loop until the browser stops -- google somehow has these incorrect domain names in their index. -- Chris Davies E-Commerce/Colocation http://daviesinc.com/ +1.561.333.6946 Florida, USA Currently 71F, Partly Cloudy, Wind from the Southeast @ 6 mph From grendel at caudium.net Tue Nov 16 03:28:07 2004 From: grendel at caudium.net (Marek Habersack) Date: Tue, 16 Nov 2004 04:28:07 +0100 Subject: userspace modules configuration problem and an oops Message-ID: <20041116032807.GF16475@beowulf.thanes.org> Hello list, We've got a problem making userspace modules work to handle a single extension instead of handling all the requests. Here's the setup: /etc/tux.mime.types: TUX/module htm module name: qreplace.htm.so, loaded: opening shared library /usr/lib/tux/modules/qreplace.htm.so handle: 0x804efb0 TUXAPI_init: 0xb7dea029 TUXAPI_handle_events: 0xb7dea06d register {qreplace.htm} - TUX returned 0... tux configured to handle virtual hosts Module gets initialized but never gets called for requests referencing .htm files. If I read the Chapter 5 of the tux docs correctly, the above setup should result in the qreplace.htm module being called to handle, e.g., test.htm request. What happens instead is that on the _first_ request to any .htm file, tux keeps the browser busy and the connection open. Once the connection is forcibly closed on the client side and the next request is made, tux serves the referenced file without passing it to the userspace module and with the text/plain type (a curious thing here: if I turn virtual hosts off, tux will serve the same file with the text/html mime type instead of text/plain). The above happens with tux A3 for 2.4 and tux A6 for 2.6. Running tux userland without -d doesn't reveal any problems, syslog has no messages from the kernel tux code either. While testing the above, I've also came across another problem, this time an oops (tux A6): Nov 15 21:50:14 colo6 kernel: kernel BUG at fs/namei.c:481! Nov 15 21:50:14 colo6 kernel: invalid operand: 0000 [#1] Nov 15 21:50:14 colo6 kernel: Modules linked in: Nov 15 21:50:14 colo6 kernel: CPU: 0 Nov 15 21:50:14 colo6 kernel: EIP: 0060:[link_path_walk+2269/2944] Not tainted VLI Nov 15 21:50:14 colo6 kernel: EFLAGS: 00010216 (2.6.9) Nov 15 21:50:14 colo6 kernel: EIP is at link_path_walk+0x8dd/0xb80 Nov 15 21:50:14 colo6 kernel: eax: dde20560 ebx: dd669e68 ecx: dc4d5410 edx: dc4d5470 Nov 15 21:50:14 colo6 kernel: esi: 00000000 edi: dd668000 ebp: dd669eac esp: dd669e30 Nov 15 21:50:14 colo6 kernel: ds: 007b es: 007b ss: 0068 Nov 15 21:50:14 colo6 kernel: Process async IO 0/1 (pid: 715, threadinfo=dd668000 task=dde20560) Nov 15 21:50:14 colo6 kernel: Stack: dd669e68 dd669e6c dd669e68 00000000 dc4d5410 00000000 00000000 ffffffd8 Nov 15 21:50:14 colo6 kernel: 00000000 00000000 00000000 00000000 00000001 00000000 dfe81080 dc4d5410 Nov 15 21:50:14 colo6 kernel: ed5c7610 00000009 df53f9b0 dfd107e0 dd669eac 00000001 00000001 00000000 Nov 15 21:50:14 colo6 kernel: Call Trace: Nov 15 21:50:14 colo6 kernel: [__tux_lookup+16/48] __tux_lookup+0x10/0x30 Nov 15 21:50:14 colo6 kernel: [tux_lookup+179/272] tux_lookup+0xb3/0x110 Nov 15 21:50:14 colo6 kernel: [lookup_url+112/1520] lookup_url+0x70/0x5f0 Nov 15 21:50:14 colo6 kernel: [schedule+670/1168] schedule+0x29e/0x490 Nov 15 21:50:14 colo6 kernel: [http_process_message+108/800] http_process_message+0x6c/0x320 Nov 15 21:50:14 colo6 kernel: [tux_schedule_atom+29/48] tux_schedule_atom+0x1d/0x30 Nov 15 21:50:14 colo6 kernel: [cachemiss_thread+424/464] cachemiss_thread+0x1a8/0x1d0 Nov 15 21:50:14 colo6 kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 Nov 15 21:50:14 colo6 kernel: [ret_from_fork+6/20] ret_from_fork+0x6/0x14 Nov 15 21:50:14 colo6 kernel: [default_wake_function+0/32] default_wake_function+0x0/0x20 Nov 15 21:50:14 colo6 kernel: [cachemiss_thread+0/464] cachemiss_thread+0x0/0x1d0 Nov 15 21:50:14 colo6 kernel: [kernel_thread_helper+5/24] kernel_thread_helper+0x5/0x18 Nov 15 21:50:14 colo6 kernel: Code: 1a 01 22 c1 34 c0 eb ec 0f 0b 1a 01 22 c1 34 c0 eb 98 89 2c 24 e8 74 f2 ff ff 8 9 f0 e9 4c fe ff ff e8 d8 b8 1e 00 e9 a7 fd ff ff <0f> 0b e1 01 ec ec 34 c0 e9 8f fd ff ff 89 2c 24 e8 4e f2 ff ff It happens whenever a request is made that resolves to a symlink on the filesystem (XFS in our case). After the oops tux cannot be stopped and the machine must be rebooted. Any clues as to what might be wrong with either the module setup and the above oops? Thanks in advance, marek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jlirochon at cyanide-studio.com Fri Nov 26 17:37:02 2004 From: jlirochon at cyanide-studio.com (Julien Lirochon) Date: Fri, 26 Nov 2004 18:37:02 +0100 Subject: tux compilation problem on linux-2.6.9 Message-ID: <41A769BE.7040503@cyanide-studio.com> I patched a plain linux-2.6.9 kernel with the tux3-2.6.9-rc3-A6 patch At compile time I got this error : net/ipv4/tcp_output.c:448: error: `tcp_set_skb_tso_factor' undeclared here (not in a function) net/ipv4/tcp_output.c:448: error: initializer element is not constant net/ipv4/tcp_output.c:448: error: (near initialization for `__ksymtab_tcp_set_skb_tso_factor.value') net/ipv4/tcp_output.c:448: error: __ksymtab_tcp_set_skb_tso_factor causes a section type conflict make[2]: *** [net/ipv4/tcp_output.o] Error 1 make[1]: *** [net/ipv4] Error 2 make: *** [net] Error 2 If you have this error you should edit net/ipv4/tcp_output.c and replace at line 448 EXPORT_SYMBOL_GPL(tcp_set_skb_tso_factor); by EXPORT_SYMBOL_GPL(tcp_set_skb_tso_segs); Maybe it will help someone :) From kees at tweakers.net Sun Nov 28 01:23:31 2004 From: kees at tweakers.net (Kees Hoekzema) Date: Sun, 28 Nov 2004 02:23:31 +0100 Subject: userspace modules configuration problem and an oops In-Reply-To: <20041116032807.GF16475@beowulf.thanes.org> References: <20041116032807.GF16475@beowulf.thanes.org> Message-ID: <200411280223.31952.kees@tweakers.net> On Tuesday 16 November 2004 04:28, Marek Habersack wrote: > While testing the above, I've also came across another problem, this time > an oops (tux A6): > > Nov 15 21:50:14 colo6 kernel: kernel BUG at fs/namei.c:481! [snip] > kernel_thread_helper+0x5/0x18 Nov 15 21:50:14 colo6 kernel: Code: 1a 01 22 > c1 34 c0 eb ec 0f 0b 1a 01 22 c1 34 c0 eb 98 89 2c 24 e8 74 f2 ff ff 8 9 f0 > e9 4c fe ff ff e8 d8 b8 1e 00 e9 a7 fd ff ff <0f> 0b e1 01 ec ec 34 c0 e9 > 8f fd ff ff 89 2c 24 e8 4e f2 ff ff > > It happens whenever a request is made that resolves to a symlink on the > filesystem (XFS in our case). After the oops tux cannot be stopped and the > machine must be rebooted. I have the same problem discribed here, the box stays up, but tux cant be stopped and I need to reboot the server. As we have quite a lot symlinks it is quite a showstopper at the moment. I tried to run tux with debugging, Dprintk seems not to send enough debug info, TDprintk does, but creates an kernel panic (after which my system freezes and needs a remote powercycle). Than I tried to get some debugging with only Dprintk, and changing a few lines in input.c and http_proto.c so it used printk instead of Dprintk. This somehow fixed the problem where tux crashed.. I added some printk's when this tux_lookup was called and somehow that fixed my problem. I'm not sure what exactly is fixed; The only thing I changed was on line 781 in proto_http.c where I changed 'Dprintk' to 'printk'. (which is now filling up my dmesg ;)) Changing it back resulted in the same bug returning. Maybe someone more experienced in Tux-hacking can explain it. -kees info: My complete message: kernel BUG at fs/namei.c:481! invalid operand: 0000 [#1] SMP Modules linked in: CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010286 (2.6.9) EIP is at link_path_walk+0x493/0xd60 eax: e4b270d0 ebx: f28e33c8 ecx: c01abfe0 edx: eb597e60 esi: eb597000 edi: f2c49288 ebp: f4f2d1c5 esp: eb597e00 ds: 007b es: 007b ss: 0068 Process tux (pid: 502, threadinfo=eb597000 task=e4b270d0) Stack: 00000040 eb597e18 00000272 f3b03d74 eb597e4c ffffffd8 8e711f53 00000001 00000040 eb597e60 f6d83780 f28e33c8 db6490ae 00000007 f4f2d1bd 00000000 eb597e60 f4f2d1b0 00000040 f4f2d000 c02f783f f4f2d000 c02f7930 eb597ee4 Call Trace: [] __tux_lookup+0xc/0x1d [] tux_lookup+0xa6/0xf0 [] task_rq_lock+0x36/0x64 [] try_to_wake_up+0x1ce/0x24d [] lookup_url+0x52/0x54e [] add_req_to_workqueue+0x2c/0x43 [] unidle_req+0x68/0x6a [] http_process_message+0x61/0x2de [] tux_schedule_atom+0xe/0x10 [] process_requests+0xad/0xb8 [] event_loop+0x131/0x18c [] __sys_tux+0x1f7/0x841 [] sys_chdir+0x5d/0x6b [] syscall_call+0x7/0xb Code: eb d1 0f 0b 1a 01 f1 31 33 c0 e9 49 ff ff ff 8b 44 24 24 e8 91 f7 ff ff 8b 44 24 10 e9 e2 fd ff ff e8 3e 9f 1c 00 e9 2b fd ff ff <0f> 0b e1 01 b9 66 33 c0 e9 13 fd ff ff 8b 44 24 24 e8 68 f7 ff System config: Dual Xeon 2.8GHz w/ 1GB ram 60G IDE disk uname -a: Linux argus 2.6.9 #6 SMP Sun Nov 28 01:37:10 CET 2004 i686 unknown unknown GNU/Linux 2.6.9 is running tux, with the small change Julien Lirochon suggested in his mail to this list. From shiner_chen at yahoo.com.cn Tue Nov 30 07:43:45 2004 From: shiner_chen at yahoo.com.cn (shiner chen) Date: Tue, 30 Nov 2004 15:43:45 +0800 (CST) Subject: How does tux redirect the request to the secondary server? Message-ID: <20041130074345.33465.qmail@web15507.mail.cnb.yahoo.com> I found tux redirect the request to the secondary server when the method is not GET. The Tux redirect the request by puting the socket into the queue of secondary server's socket,but I wonder whether it is true . I don't know how does the secondary server send response to tux. does the secondary server send the response to client directly ? if tux does like that ,I want to know how does it do that! thanks ! Shiner Chan 30th Nov 2004 --------------------------------- Do You Yahoo!? ??????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From shiner_chen at yahoo.com.cn Tue Nov 30 07:46:17 2004 From: shiner_chen at yahoo.com.cn (shiner chen) Date: Tue, 30 Nov 2004 15:46:17 +0800 (CST) Subject: How does tux redirect the request to the secondary server? Message-ID: <20041130074617.59801.qmail@web15506.mail.cnb.yahoo.com> I found tux redirect the request to the secondary server when the method is not GET. The Tux redirect the request by puting the socket into the queue of secondary server's socket,but I wonder whether it is true . I don't know how does the secondary server send response to tux. does the secondary server send the response to client directly ? if tux does like that ,I want to know how does it do that! thanks ! Shiner Chan 30th Nov 2004 --------------------------------- Do You Yahoo!? ??????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: