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 the doc tree. As your ops scale up, so does the size of the doc tree. If you want to test caching use ab (apache bench) or flood :-) This ususally mean that you want a lot of memory, my borrowed test machine had 8gb 3. caching the fd's would be more than sufficient (than caching the contents). This helps avoid the disk tree traversal and the open, so yes, it would cut down on a lot of processing. 4. on hp-ux, eliminating the stat/fstat would not make a lot of difference.. I dont know about other os'es - but, based on his logic, since the fd for that file is already available, fstat should not take a lot of time. I would be surprised if the stat/fstat removal would make no difference but it might be small. Any system call is a context switch which adds up. Of course on a suped up box here, running full out, I was seeing apache use ~4% of the cpu which says that savings in apache (user space) may not add up to any significant savings... 5. Another interesting question : why do we need the poll everytime ?. Instead do a accept, and if there's no request available, accept would return EWOULDBLOCK. For a benchmark, accept would *never* return EWOULDBLOCK, and for a normal server, it's okay - because the server is idle. You don't want a busy wait state which is what you would need with ewouldblock. chews up lots of cpu time that someone else might want. Poll is a better general solution to the problem which is why apache does it. Dave
[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 morning. Sincerely, Phi-Long Tran Summary: * Fixed Win32 crash resulting from strtoll() macro. This patch addresses a crash caused by the Win32 implementation of the strtoll() macro in config.h, which is generated from config.h.in. This patch fixes config.h.in. The change will affect files using strtoll() on Win32 builds with an old enough Microsoft Visual C/C++ compiler. The addition operator (+) has higher precedence than the conditional operator (a ? b : c). The portion of the Win32 implementation of the strtoll() macro in question is below: *(e) = (char*)(p) + ((b) == 10) ? strspn((p), 0123456789) : 0 The compiler will evaluate the expression like this: *(e) = ( (char*)(p) + ((b) == 10) ) ? strspn((p), 0123456789) : 0 The code was meant to evaluate like this: *(e) = (char*)(p) + ( ((b) == 10) ? strspn((p), 0123456789) : 0 ) The code is effectively pointing e to the first nondigit character starting at where p points to. Because of the precendence rules, the invocation of strtoll() in set_seed() in file flood.c effectively compiled to this code: *(e) = strspn((p), 0123456789) which yields an invalid address. The above assignment triggers the compiler warning below. flood.c(105) : warning C4047: '=' : 'char *' differs in levels of indirection from 'const unsigned int ' The build produces seven occurrences of this warning. After the code fix, those seven occurrences disappear. When applying this fix, you should rebuild all files to ensure they re-evaluate the corrected strtoll() macro from a newly generated config.h file. Index: config.h.in === RCS file: /home/cvspublic/httpd-test/flood/config.h.in,v retrieving revision 1.25 diff -u -r1.25 config.h.in --- config.h.in 16 Sep 2002 09:55:07 - 1.25 +++ config.h.in 29 Jan 2003 00:20:00 - @@ -74,7 +74,7 @@ #ifdef WIN32 /* Gross Hack Alert */ #if _MSC_VER 1300 -#define strtoll(p, e, b) ((*(e) = (char*)(p) + ((b) == 10) ? strspn((p), 0123456789) : 0), _atoi64(p)) +#define strtoll(p, e, b) ((*(e) = (char*)(p) + (((b) == 10) ? strspn((p), 0123456789) : 0)), _atoi64(p)) #else #define strtoll(p, e, b) _strtoi64(p, e, b) #endif
[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, so
the code proceeded to use an invalid file handle when the
file open fails. The code now detects the failure and displays
an error message.
The standard error and output file-opens were moved earlier
in the program in case we need to display error messages
to standard error.
On Windows, using the invalid file handle results in an
access violation. The program now displays a message like
this:
Error opening configuration file: The system cannot find
the file specified. .
Index: flood.c
===
RCS file: /home/cvspublic/httpd-test/flood/flood.c,v
retrieving revision 1.8
diff -u -r1.8 flood.c
--- flood.c 31 May 2002 07:59:26 - 1.8
+++ flood.c 29 Jan 2003 00:09:37 -
@@ -144,16 +144,20 @@
ssl_init_socket(local_pool);
#endif /* FLOOD_HAS_OPENSSL */
+apr_file_open_stdout(local_stdout, local_pool);
+apr_file_open_stderr(local_stderr, local_pool);
+
if (argc == 1)
apr_file_open_stdin(local_stdin, local_pool);
-else
+else if ((stat = apr_file_open(local_stdin, argv[1], APR_READ,
+ APR_OS_DEFAULT, local_pool)) != APR_SUCCESS)
{
-apr_file_open(local_stdin, argv[1], APR_READ, APR_OS_DEFAULT,
- local_pool);
+char buf[256];
+apr_strerror(stat, (char*) buf, sizeof(buf));
+apr_file_printf(local_stderr, Error opening configuration file:
%s.\n,
+(char*)buf);
+exit(-1);
}
-
-apr_file_open_stdout(local_stdout, local_pool);
-apr_file_open_stderr(local_stderr, local_pool);
/* parse the config */
config = parse_config(local_stdin, local_pool);
[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 includes the file: apr_strings.h so that it picks up the proper declaration of apr_pstrmemdup. Below are examples of the compile-time warning and the link failures that this patch addresses. flood_socket_keepalive.c(407) : warning C4013: 'apr_pstrmemdup' undefined; assuming extern returning int flood_socket_keepalive.obj : error LNK2001: unresolved external symbol _apr_pstrmemdup Index: flood_socket_keepalive.c === RCS file: /home/cvspublic/httpd-test/flood/flood_socket_keepalive.c,v retrieving revision 1.15 diff -u -r1.15 flood_socket_keepalive.c --- flood_socket_keepalive.c22 Jul 2002 05:50:05 - 1.15 +++ flood_socket_keepalive.c28 Jan 2003 23:50:58 - @@ -53,6 +53,7 @@ */ #include apr.h +#include apr_strings.h #if APR_HAVE_STDLIB_H #include stdlib.h /* rand/strtol */
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 Pack 3. My FLOOD source was checked out from CVS this morning. Summary: * Fixed Win32 crash resulting from strtoll() macro. This patch addresses a crash caused by the Win32 implementation of the strtoll() macro in config.h, which is generated from config.h.in. This patch fixes config.h.in. The change will affect files using strtoll() on Win32 builds with an old enough Microsoft Visual C/C++ compiler. Index: config.h.in === RCS file: /home/cvspublic/httpd-test/flood/config.h.in,v retrieving revision 1.25 diff -u -r1.25 config.h.in --- config.h.in 16 Sep 2002 09:55:07 - 1.25 +++ config.h.in 29 Jan 2003 00:20:00 - @@ -74,7 +74,7 @@ #ifdef WIN32 /* Gross Hack Alert */ #if _MSC_VER 1300 -#define strtoll(p, e, b) ((*(e) = (char*)(p) + ((b) == 10) ? strspn((p), 0123456789) : 0), _atoi64(p)) +#define strtoll(p, e, b) ((*(e) = (char*)(p) + (((b) == 10) ? strspn((p), 0123456789) : 0)), _atoi64(p)) #else #define strtoll(p, e, b) _strtoi64(p, e, b) #endif
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 Service Pack 3. My FLOOD source was checked out from CVS this morning. Applied. Thanks! Note: I had to moderate your posts through. Did you send the posts from the same address that you subscribed as? Regardless, posts from [EMAIL PROTECTED] should get through now... -- justin
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 first time in ages and did a mini-SPECweb experimental run in preparation for fiddling with the stat() in mod_specweb99. I got really horrible results at first and couldn't figure out what was wrong. It turned out that I just needed to warm up the kernel's disk cache more. The results got 50% better after an hour or so. 2. when doing writes, do a 64M block writes, instead of write to disk every time.. (Lazy write) I would hope a smart file system/kernel would take care of that for us. 3. caching the fd's would be more than sufficient (than caching the contents). yep, it actually would be better for big files because we can do sendfile. If your NIC has hardware checksum, a smart kernel/device driver can just do DMA from the file cache. But how many fd's can you cache? 4. on hp-ux, eliminating the stat/fstat would not make a lot of difference.. I dont know about other os'es - but, based on his logic, since the fd for that file is already available, fstat should not take a lot of time. Some of my buddies in IBM's Linux Technology Center who run SPECweb99 say that one of the things that inhibits our SMP scalability with out-of-the-box Linux kernels is contention on the dcache spinlock. That comes into play every time you do a syscall and pass a file path that the kernel has to walk. So open()s and stat()s are the prime suspects. I'm wondering why we need the stat() at all in mod_specweb99? It looks like the only thing we use from it is s.size. But IIRC the sendfile() syscall is happy if you give it a size of zero, which means send the whole thing. This obviously needs to be tested to see how our code reacts to EAGAIN + size == 0. If we can't get rid of it altogether, I would prefer to use fstat() a.k.a. apr_file_info_get() The LTC guys use a dcache RCU (read-copy-update) patch that eliminates the spinlock contention, but I doubt if a high percentage of our users are willing to build custom kernels. The kernel still has to walk the file path, lock or no lock. 5. Another interesting question : why do we need the poll everytime ?. Instead do a accept, and if there's no request available, accept would return EWOULDBLOCK. If your box supports SINGLE_LISTEN_UNSERIALIZED_ACCEPT, you shouldn't have any polls before the accepts, barring bugs. SPECweb99 does a lot of keepalive requests, and we poll for new data between requests on the same connection. That's probably what you're seeing. Greg
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 segfault with recent OpenSSL's? I sure can't. As a result, every single SSL test fails for me. --Cliff
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 horrible results at first and couldn't figure out what was wrong. It turned out that I just needed to warm up the kernel's disk cache more. The results got 50% better after an hour or so. 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. This made a big difference with Zeus, but I never saw much of a change, but then again I was shooting for a much lower specweb. Dave
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 error_log. -Madhu PS : I'm using Perl 5.8 though (I'm not sure if it matters, but I can try on 5.6.1) -Original Message- From: Cliff Woolley [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 29, 2003 12:50 AM To: [EMAIL PROTECTED] Subject: 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: 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 in the kernel. 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. You may want to restrict yourself to the smaller classes depends on your memory. If you don't have enough, you will just shove everything through the kernel into the bit bucket :-) Other than that - yes it should :-) Dave
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 Mandrake9/linux with updates: libopenssl0.9.7-0.9.7-3mdk libopenssl0.9.7-devel-0.9.7-3mdk openssl-0.9.7-3mdk kernel 2.4.19-16mdksmp. Crypt::SSLeay's make test has passed with perl 5.8.0 (with ithreads and without). The build generates the following warning: SSLeay.xs: In function `XS_Crypt__SSLeay__Conn_new': SSLeay.xs:237: warning: passing arg 2 of `SSL_set_info_callback' from incompatible pointer type but it's not a problem, since it's invoked only in the debug mode. Though I can't even start the perl-framework, I get: using Apache/2.1.0-dev (prefork MPM) waiting for server to start: 00:00[Thu Jan 30 10:37:27 2003] [warn] _default_ VirtualHost overlap on port 8534, the first has precedence [Thu Jan 30 10:37:27 2003] [warn] _default_ VirtualHost overlap on port 8535, the first has precedence (98)Address already in use: make_sock: could not bind to address 0.0.0.0:8534 no listening sockets available, shutting down Unable to open logs Do you have the same problem with an updated Apache::Test? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[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 version as flood.dsp and flood.dsw (which includes flood_test.dsp). This change is for the sake of convenience. If we need to modify flood_test.dsp in the future, we can do so as a separate step from upgrading the DSP. CVS will also no longer identify flood_test.dsp as modified after DevStudio upgrades it. Index: flood_test.dsp === RCS file: /home/cvspublic/httpd-test/flood/flood_test.dsp,v retrieving revision 1.1 diff -u -r1.1 flood_test.dsp --- flood_test.dsp 31 May 2002 08:27:07 - 1.1 +++ flood_test.dsp 29 Jan 2003 23:29:57 - @@ -1,5 +1,5 @@ # Microsoft Developer Studio Project File - Name=flood_test - Package Owner=4 -# Microsoft Developer Studio Generated Build File, Format Version 5.00 +# Microsoft Developer Studio Generated Build File, Format Version 6.00 # ** DO NOT EDIT ** # TARGTYPE Win32 (x86) Console Application 0x0103 @@ -22,6 +22,7 @@ !MESSAGE # Begin Project +# PROP AllowPerConfigDependencies 0 # PROP Scc_ProjName # PROP Scc_LocalPath CPP=cl.exe
