[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
RE: mod_perl
how are you benchmarking? what program are you using?
-----Original Message-----
From: owner-minivend-users@minivend.com
[mailto:owner-minivend-users@minivend.com]On Behalf Of Jay Austad
Sent: Friday, June 18, 1999 9:19 AM
To: minivend-users@minivend.com
Subject: Re: mod_perl
****** message to minivend-users from Jay Austad <austad@fallon.com>
******
> That's not right. Have you had MV build an INDEX for your products db?
How do I do that?
I am not swapping. When I do a free, it only shows that around 117MB of ram
is being used, and no swap.
> Actually, the great thing about MV is that it doesn't spawn a perl process
> for each request. It runs one main perl process that waits for requests
from
> either vlink or tlink.
I'm not so sure this is true. When I run apache benchmark against minivend,
and watch 'top' on the server, it shows about 15 copies of perl running, and
they are all taking up a good chunk of the cpu. In total, they take up
about 180% of the CPU (dual processor). I assume the vlink program is
simply just calling perl somehow.
The machine has the latest versions of all software on it, all compile with
pentium optimizations. Perl is what is running the load up so high on the
server (it did the same thing before I compiled the latest version with
optimizations). 30 concurrent requests shouldn't bring the load up much
past 1 or so, but it goes above 10. 31 seconds on average to return a page
under that load. Otherwise, with no load, it works fine, returns pages
within 1 second or so.
Ok, just ran a quick test. I ran the benchmark against /cgi-bin/store
before, and that was the test that was running the load up to 10.72. I just
ran apache benchmark again with 150 requests, 30 concurrent, against
/cgi-bin/store/frames, and /cgi-bin/store/noframes, and then again on
/cgi-bin/store.
The results are below, first the frames, then noframes, and finally just
/cgi-bin/store. The frames and noframes options are acceptable, but the
last one is where it's really loading the server down. Isn't /cgi-bin/store
the same thing as /cgi-bin/store/noframes? They return the same thing. So
what extra stuff is happening when I don't give the frames or noframes
option?
Here are the results of the benchmark using the frames option:
Server Software:
Apache/1.3.6
Server Hostname:
www.host.com
Server Port:
80
Document Path:
/cgi-bin/store/frames
Document Length:
1371 bytes
Concurrency Level:
30
Time taken for tests:
45.844 seconds
Complete requests:
150
Failed requests:
0
Total transferred:
235650 bytes
HTML transferred:
205650 bytes
Requests per second:
3.27
Transfer rate:
5.14 kb/s received
Connnection Times (ms)
min
avg
max
Connect:
16
66
3040
Processing:
741
8205
9046
Total:
757
8271
12086
Here are the results using noframes:
Server Software:
Apache/1.3.6
Server Hostname:
www.host.com
Server Port:
80
Document Path:
/cgi-bin/store/noframes
Document Length:
2 bytes
Concurrency Level:
30
Time taken for tests:
43.238 seconds
Complete requests:
150
Failed requests:
0
Non-2xx responses:
150
Total transferred:
41550 bytes
HTML transferred:
300 bytes
Requests per second:
3.47
Transfer rate:
0.96 kb/s received
Connnection Times (ms)
min
avg
max
Connect:
18
66
3028
Processing:
661
7776
6480
Total:
679
7842
9508
Here are the results of just calling /cgi-bin/store:
Server Software:
Apache/1.3.6
Server Hostname:
www.host.com
Server Port:
80
Document Path:
/cgi-bin/store
Document Length:
16947 bytes
Concurrency Level:
30
Time taken for tests:
172.749 seconds
Complete requests:
150
Failed requests:
0
Total transferred:
2572050 bytes
HTML transferred:
2542050 bytes
Requests per second:
0.87
Transfer rate:
14.89 kb/s received
Connnection Times (ms)
min
avg
max
Connect:
17
115
3013
Processing:
7139
31040
36508
Total:
7156
31155
39521
I have the PageCache option set. Is it caching the frames and noframes
options and not caching the page when I call just the store cgi? I'd really
like to figure out why this is happening and fix it instead of just making
everyone go to /cgi-bin/store/noframes instead.
Jay
-
To unsubscribe from the list, DO NOT REPLY to this message. Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to
Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list