MiniVend Akopia Services

[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



Search for: Match: Format: Sort by: