Re: gettimeofday calls

I had a couple of inputs here : I was talking to our specweb person, and he had the following views : 1. most modern day os'es cache the files, and not do a disk io for every single file request. (duh !!.) Part of the design of specweb was to make it difficult (but not imposible) to cache

[PATCH] flood: Fixed Win32 crash resulting from strtoll() macro.

Hi all, This patch is the first in a series that will produce a running executable on Win32 platforms with Microsoft Visual C++ 6.0. My Win32 development environment is Microsoft Windows 2000 Service Pack 3 and MS Visual C++ 6.0 Service Pack 3. My FLOOD source was checked out from CVS this

[PATCH] flood: Added error handling for failed config-file open

Summary: * Added error handling for failed config-file open. This patch adds error handling to the code that opens the configuration file. When you specify an argument to the flood program, it attempts to open it to read in configuration information. Previously, there was no error handling,

[PATCH] flood: (Win32) Fixed link error apr_pstrmemdup in flood_socket_keepalive.c

Summary: * (Win32) Fixed link error apr_pstrmemdup in flood_socket_keepalive.c. This patch addresses a link error. The code invoked apr_pstrmemdup() in flood_socket_keepalive.c without including the proper declaration. The compiler generates its own guess, which is incorrect. The code now

Re: [PATCH] flood: Fixed Win32 crash resulting from strtoll() macro.

Nice patch, ++1. At 07:52 PM 1/28/2003, [EMAIL PROTECTED] wrote: This patch is the first in a series that will produce a running executable on Win32 platforms with Microsoft Visual C++ 6.0. My Win32 development environment is Microsoft Windows 2000 Service Pack 3 and MS Visual C++ 6.0 Service

Re: [PATCH] flood: Fixed Win32 crash resulting from strtoll() macro.

--On Tuesday, January 28, 2003 5:52 PM -0800 [EMAIL PROTECTED] wrote: Hi all, This patch is the first in a series that will produce a running executable on Win32 platforms with Microsoft Visual C++ 6.0. My Win32 development environment is Microsoft Windows 2000 Service Pack 3 and MS Visual C++ 6.0

Re: [PATCH] flood: Added error handling for failed config-file open

--On Tuesday, January 28, 2003 5:56 PM -0800 [EMAIL PROTECTED] wrote: Summary: * Added error handling for failed config-file open. Applied. Thanks! -- justin

Re: [PATCH] flood: Fixed PASSTHROUGH collision in flood_round_robin.c

--On Tuesday, January 28, 2003 5:58 PM -0800 [EMAIL PROTECTED] wrote: Summary: * Fixed PASSTHROUGH collision in flood_round_robin.c. I don't really have a better idea than EPE, so it works for now. =) Applied. Thanks! -- justin

Re: [PATCH] flood: (Win32) Fixed link error apr_pstrmemdup in flood_socket_keepalive.c

--On Tuesday, January 28, 2003 6:01 PM -0800 [EMAIL PROTECTED] wrote: Summary: * (Win32) Fixed link error apr_pstrmemdup in flood_socket_keepalive.c. Applied. Thanks! -- justin

Crypt::SSLeay

Has anybody out there managed to get Crypt::SSLeay to do anything but segfault with recent OpenSSL's? I sure can't. As a result, every single SSL test fails for me. --Cliff

Re: gettimeofday calls

MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: I had a couple of inputs here : I was talking to our specweb person, and he had the following views : 1. most modern day os'es cache the files, and not do a disk io for every single file request. (duh !!.) yep. Yesterday I powered up wimp for the

RE: Crypt::SSLeay

I've been using 0.45 with a older version of openssl 0.9.6f - I can try the latest openssl today.. -Madhu -Original Message- From: Cliff Woolley To: [EMAIL PROTECTED] Sent: 1/29/03 12:50 AM Subject: Crypt::SSLeay Has anybody out there managed to get Crypt::SSLeay to do anything but

Re: gettimeofday calls

1. most modern day os'es cache the files, and not do a disk io for every single file request. (duh !!.) yep. Yesterday I powered up wimp for the first time in ages and did a mini-SPECweb experimental run in preparation for fiddling with the stat() in mod_specweb99. I got really

RE: Crypt::SSLeay

I just compiled 0.45 with OpenSSL 0.9.7, and the only error that I'm seeing is : ssl/varlookupok 27/72# Failed test 28 in /tmp/madhum.perl_framework/httpd-test/perl-framework/Apache-Test/lib/Apache/ Test.pm at line 46 fail #28 and I'm not seeing any seg fault type messages in the

RE: Crypt::SSLeay

On Wed, 29 Jan 2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: PS : I'm using Perl 5.8 though (I'm not sure if it matters, but I can try on 5.6.1) I'm using Linux, Slackware current, kernel 2.4.20, glibc 2.3.1, openssl 0.9.6h, perl 5.8.0, latest Crypt::SSLeay. --Cliff

Re: gettimeofday calls

David Hill wrote: When our specweb guys were whacking Zeus they would first run a program that would walk the file set to try and fill up the cache. hey, I like that idea! I wonder if: find /spec_docroot/file_set/ -type f | xargs cat /dev/null ...will do the job? I'll give it a try. Greg

Re: gettimeofday calls

When our specweb guys were whacking Zeus they would first run a program that would walk the file set to try and fill up the cache. Zues had some sort of internal cache that needed to be warmed on a per-process basis (they would run with one process per cpu), as well as warming the read cache

Re: Crypt::SSLeay

Cliff Woolley wrote: On Wed, 29 Jan 2003, MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote: PS : I'm using Perl 5.8 though (I'm not sure if it matters, but I can try on 5.6.1) I'm using Linux, Slackware current, kernel 2.4.20, glibc 2.3.1, openssl 0.9.6h, perl 5.8.0, latest Crypt::SSLeay. I've

[PATCH] flood: Upgraded flood_test.dsp to MS DevStudio 6 format

Summary: * Updated flood_test.dsp to MS DevStudio 6 format This patch updates the file flood_test.dsp to Developer Studio (DevStudio) version 6. Developer Studio version 6 no longer needs to upgrade the DSP file on-the-fly when you load flood.dsw. This DSP file now has the same DevStudio