> the various types of URLs. Fortunately, the client prints the URLs before it
> tests them. Cut-n-paste the failing URLs into a browser navigation bar and
> hit
> enter. What does the browser display?
Even better, the manager script dumps the result of its tests to files with
names like 'dync
Joshua Schnee wrote:
I am attempting to set up the latest Apache server and RHEL 64bit to use
in a Specweb99 run and am running into cgi issues. I am very new to
Apache, and am having difficulty getting apache to run/use/find my
cgi-script. Static content works fine, but I am getting improper
blem where server and client(s) are
>messing with each other. Threads blocking on the server could
>be tying up
>the clients, untill all clients are hanging and everything
>stops. I have
>found the SPECWeb99 clients less than wonderfully robust under these
>circumstances.
I don&#
hanging and everything stops. I have
found the SPECWeb99 clients less than wonderfully robust under these
circumstances.
S.
--
Covalent Technologies [EMAIL PROTECTED]
Engineering groupVoice: (415) 856 4214
303 Second Street #375 South Fax: (415) 856 4210
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
[SNIP]
>Two possibilities:
>
>* the command/Fetch URI is stuck also, or
I don't think the client did any Fetch when apache stopped.
>* something died holding the post lock, and it didn't get
>automagically cleaned u
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
I enabled the POST transactions, and all of a sudden, the apache process is
now hung (this is first time I'm seeing this behaviour).. The stack is :
(gdb) t 21
[Switching to thread 21 (system thread 29207)]
#0 0xc0306850:0 in _semop_sys+0x30
t: RE: Regarding Apache 2.0.48 and specweb99
>
>
>
>>-Original Message-
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>[SNIP]
>
>>I'm glad you're making progress. But I'm wondering why
>>raising the mod_cgid
>>Listen backlo
e point, either the workload is spikey or the steady state
>arrival rate of
>CGI requests is too fast for one daemon + your SPECweb99 CGI
>program to keep up.
I was probably driving the server pretty hard for CGI's. The avg. number of
forks per second were around 15..20 - but ofte
the workload is spikey or the steady state arrival rate of
CGI requests is too fast for one daemon + your SPECweb99 CGI program to keep up.
If the latter is true, you should see more and more CGI requests building up
over time in server-status with ExtendedStatus on, and a big improvement in
t
#x27;t connect" errors. I increased it to 1024.
-Madhu
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Sent: Monday, November 24, 2003 1:48 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Regarding Apache 2.0.48 and specweb99
>
>
>M
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
Hmmn. Interesting.
1. Did you include the cgid restart fix ?
I don't think so. It's the httpd-2.0.48 tarball + mod_specweb99.
2. Are you driving the server with the SPECweb99 recommended CGI load ?
DYNAMIC_CGI_GET=.005
I believe that'
: RE: Regarding Apache 2.0.48 and specweb99
>
>
>Hmmn. Interesting.
>
>1. Did you include the cgid restart fix ?
>2. Are you driving the server with the SPECweb99 recommended CGI load ?
>3. do you mind posting the httpd.conf
>
>-Madhu
>
>>-Original Message---
Hmmn. Interesting.
1. Did you include the cgid restart fix ?
2. Are you driving the server with the SPECweb99 recommended CGI load ?
3. do you mind posting the httpd.conf
-Madhu
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>Sent: Friday, November 21,
MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1) wrote:
Hi Greg,
The recent set of discussions prompted me to get some Apache numbers
out there - and when I started with the SPECweb99 run, I experienced a major
hang in the Apache, and the cgid daemon getting killed (I don't know how).
Hav
console? I would assume that once the problem
hits, there won't be many more trace entries. The relevant traces will probably
be right on the screen, or easy to scroll back to.
I'm having build problems that don't make much sense to me with 2.0.48, so I
can't tell you yet if
g
>Subject: RE: Regarding Apache 2.0.48 and specweb99
>
>
>
>>-Original Message-
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>[SNIP]
>
>>cgid should _never_ exit without something in the error log.
>>That makes it
>>sound like
;s what I did :
1. Use a large timeout and keepalive timeout, and 100 threads / process.
2. Use HTTP/1.0 as the SPECweb99 client seems to have some problem with
HTTP/1.1
(not much work done there)
3. Start SPECweb99 run
nabled all the different dynamic tests - DYNAMIC_CONTENT, DYNAMIC_POST,
DYN
ace program is called, but you want
something similar to truss/strace)
Here's what I think is happening : the SPECweb99 clients have stopped
waiting for the post log, but the CGID exited in the middle of the
processing - thus causing the SPECweb99 clients to hang (and hence Apache
also to h
ine 69 onwards. Should be able to do
catch the difference within the macro definition.
S.
> Greg
> Original Message
> Subject: Re: specweb99
> Date: Thu, 15 May 2003 11:44:16 -0400 (EDT)
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
moving to test-dev so others can review/test/comment/commit.
Greg
Original Message
Subject: Re: specweb99
Date: Thu, 15 May 2003 11:44:16 -0400 (EDT)
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
> [EMAIL PROTECTED]
t;>would be appreciated.
>>
>> Correct. I need it for HP's VirtualVault which is based on 1.3.
>>
>>>For 2.0, we don't use apxs to build mod_specweb99,
>
>> So, it wasn't at all built agains 1.3 (despite the specweb99-1.3)?
>
> It was
Sander Temme wrote:
on 5/9/03 8:22, Greg Ames at [EMAIL PROTECTED] wrote:
For 2.0, we don't use apxs to build mod_specweb99, although that is a worthy
goal.
Actually, there is a GNU Makefile in the repository that builds using
apxs... point the environment variable APXS to the apxs in your Apa
t for HP's VirtualVault which is based on 1.3.
For 2.0, we don't use apxs to build mod_specweb99,
So, it wasn't at all built agains 1.3 (despite the specweb99-1.3)?
It was _only_ built against 1.3 at one time, before it went into the apache.org
CVS. But I can't tell you which platform
> [EMAIL PROTECTED] wrote:
>
>> I have a question about the state of specweb99 module. The reason is
>> that I failed to compile the source I pulled out of CVS on RedHat 7.3
>> Linux:
>>
>> apxs -c -DLINUX -I../../mm-1.1.3 -L../../mm-1.1.3 -lmm mod_specweb99.
on 5/9/03 8:22, Greg Ames at [EMAIL PROTECTED] wrote:
> For 2.0, we don't use apxs to build mod_specweb99, although that is a worthy
> goal. We build it as if it were part of the standard httpd distribution.
> Copy
> the files from the specweb99-2.0/ directory to your
&g
[EMAIL PROTECTED] wrote:
I have a question about the state of specweb99 module. The reason is that I
failed to compile the source I pulled out of CVS on RedHat 7.3 Linux:
apxs -c -DLINUX -I../../mm-1.1.3 -L../../mm-1.1.3 -lmm mod_specweb99.c
gcc -DLINUX=22 -DMOD_SSL=208105 -DUSE_HSREGEX -DEAPI
Hi,
I have a question about the state of specweb99 module. The reason is that I
failed to compile the source I pulled out of CVS on RedHat 7.3 Linux:
apxs -c -DLINUX -I../../mm-1.1.3 -L../../mm-1.1.3 -lmm mod_specweb99.c
gcc -DLINUX=22 -DMOD_SSL=208105 -DUSE_HSREGEX -DEAPI -DEAPI_MM -fpic
Sander Temme wrote:
Does anyone have a perl script etc. to automatically convert all leading tabs
to
n blanks?
Doesn't indent do the trick, with the .indent.pro from somewhere in the
httpd-2.0 tree?
Roy T. Fielding wrote:
> Most Unices have a command called "expand" that does just that.
De-tab
Does anyone have a perl script etc. to automatically convert all
leading tabs to n blanks? I was thinking of manually de-tabifying in
the vicinity of this fix, but it would be better to do the whole thing
if I can get my hands on such a tool.
Most Unices have a command called "expand" that does
> Does anyone have a perl script etc. to automatically convert all leading tabs
> to
> n blanks? I was thinking of manually de-tabifying in the vicinity of this
> fix,
> but it would be better to do the whole thing if I can get my hands on such a
> tool.
Doesn't indent do the trick, with the .i
[EMAIL PROTECTED] wrote:
--- mod_specweb99.c 31 Oct 2002 19:39:04 - 1.16
+++ mod_specweb99.c 14 Jan 2003 15:02:00 - 1.17
@@ -765,8 +765,9 @@
line = apr_psprintf(r->pool, "%10d\n", 0);
- if (apr_file_write_full(f, line, strlen(line), NULL) != APR_SUCCESS) {
- ap_log
[EMAIL PROTECTED] wrote:
sctemme 2002/11/05 16:41:38
Modified:specweb99/specweb99-1.3 mod_specweb99.c
Log:
Disable unfinished semaphore-based IPC for checking modifications to
our database files. This gets the module to compile again.
all right! It's good to see someone
> Brian Pane wrote:
>
> > Do you have any profile data that shows where the bottlenecks are?
>
> No, sorry. At the moment I'm focusing on mod_specweb99.
>
> > From recent tests with other workloads, I anticipate that the most
> > expensive operations are likely to be: reading the HTTP headers,
Brian Pane wrote:
> Do you have any profile data that shows where the bottlenecks are?
No, sorry. At the moment I'm focusing on mod_specweb99.
> From recent tests with other workloads, I anticipate that the most
> expensive operations are likely to be: reading the HTTP headers,
> directory_wal
Greg Ames wrote:
But I can mention that my very unofficial mini-SPECweb99 runs with the client
and server both on my ThinkPad with 100% "standard dynamic GETs"* show that
prefork is the fastest, worker is about 1% slower, and leader is about another
1.5% slower. This is a noticeable i
Brian Pane wrote:
>
> [EMAIL PROTECTED] wrote:
>
> >gregames2002/06/03 11:05:50
> >
> > Modified:specweb99/specweb99-2.0 mod_specweb99.c
> >
>
> BTW, does anyone have SPECweb results for 2.0 that they're
> able to discuss?
Not that can b
[EMAIL PROTECTED] wrote:
gregames2002/06/03 11:05:50
Modified:specweb99/specweb99-2.0 mod_specweb99.c
BTW, does anyone have SPECweb results for 2.0 that they're
able to discuss?
Thanks,
--Brian
[EMAIL PROTECTED] wrote:
>
> Just rm -rf it - it is a new import anyway.
>
> Dw
OK, you & Justin talked me into it. The structure looks much simpler in ViewCVS
now.
Greg
> > Vendor Tag: init
> > Release Tags: start
> >
> > N httpd-test/specweb99/httpd.specweb.conf
> > N httpd-test/specweb99/LICENSE.txt
> > N httpd-test/specweb99/rc.byrd_ap
> > N httpd-test/specweb99/README
> > N httpd-test/specweb99/specweb9
Cliff Woolley wrote:
>
> On Thu, 2 May 2002, Justin Erenkrantz wrote:
>
> > Since this is brand new, you could always blow away the directories on
> > icarus. Your call. AIUI, if you do the "cvs rm" approach, when you
> > re-add, this version will come back out of the attic. -- justin
>
> Rig
On Thu, 2 May 2002, Justin Erenkrantz wrote:
> Since this is brand new, you could always blow away the directories on
> icarus. Your call. AIUI, if you do the "cvs rm" approach, when you
> re-add, this version will come back out of the attic. -- justin
Right. rm the ,v files. But it's really
On Thu, May 02, 2002 at 02:57:22PM -0400, Greg Ames wrote:
> [EMAIL PROTECTED] wrote:
> yuck. "cvs import" created a branch, 4 digit revision numbers, and a couple
> of
> useless tags. I'd like to blow this away and try again with cvs add. Is rm,
> cvs remove, cvs commit on all files the best w
[EMAIL PROTECTED] wrote:
>
> gregames02/05/02 10:20:10
>
> Log:
> Initial revision
>
> Status:
>
> Vendor Tag: init
> Release Tags: start
>
> N httpd-test/specweb99/httpd.specweb.conf
> N httpd-test/specweb99/LICENSE.txt
> N h
43 matches
Mail list logo
