[Date Prev][Date Next][Thread Prev][Thread Next][Minivend by date
][Minivend by thread
]
Re: mod_perl
Quoting John Edstrom (edstrom@Poopsie.hmsc.orst.edu):
> >
> > 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.
> >
> > Every time you hit the server with another request, you're actually
> > launching the small tlink or vlink compiled C program, which then
> > communicates with the perl-based daemon running in the background..
> >
>
> Yes, but minivend forks child servers to handle new requests.
> Otherwise it could only handle one page at a time. If you have the
> simple demo working, do this:
>
> (from csh-like shell)
> while (1)
> > ps ax | grep vend | grep -v grep
> > sleep 1
> > echo ""
> > end
>
> Then enter the simple catalog through the 'Enter the stor' link on the
> splash page. You will initially see (assuming this is an otherwise
> idle test/demo server) one minivend server process. When you enter
> you will see two and then three. The first is the parent server that
> sits around waiting for connections (state S).
>
> Then two children spawn. Why two, I don't know. Both begin in state
> D and one goes to R later. Man sez D = uninterruptible sleep (usually
> IO) and R = runnable. I don't understand this behavior. I think it
> has to do with signals, but I don't really know.
>
> Still, this sounds worse than it really is since fork() is pretty
> efficient. It doesn't copy the whole image, it only copies the
> environment and a few other variables. The bulk of the executable
> image is only copied as needed if it is written to. My only point is
> that MiniVend does indeed spawn a perl process for each hit. Its a
> copy of the already loaded and running perl interpreter, not a cold
> start of an entirely new server image.
>
Very good summary. It forks two copies because that is the only reliable,
portable way to detach the process. If Perl did signals well, there would
only be one fork...
The key is to set MaxServers to some reasonable number. You will serve
anywhere from 2-30 requests per MiniVend server per second on the front
page, depending on your hardware, link (vlink is faster than tlink), and
most importantly page complexity. A very fast machine can serve a few more.
You can improve tlink performance by running multiple sockets
via TcpMap -- and having your tlinks rotate between them.
And you can improve performance by running multiple MV servers
for multiple catalogs or even for the same catalog -- providing
you have enough memory. 128MB is not enough for a very high capacity
system, I can tell you that much.
Here is an example of just serving requests:
bill:~% ab -c 30 -n 150 http://www.cool.com/way/cool/override/ags_test
This is ApacheBench, Version 1.2
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-1999 The Apache Group, http://www.apache.org/
Server Software: Stronghold/2.3
Server Hostname: www.cool.com
Server Port: 80
Document Path: /way/cool/override/ags_test
Document Length: 7 bytes
Concurrency Level: 30
Time taken for tests: 26.682 seconds
Complete requests: 150
Failed requests: 0
Total transferred: 69450 bytes
HTML transferred: 1050 bytes
Requests per second: 5.62
Transfer rate: 2.60 kb/s received
Connnection Times (ms)
min avg max
Connect: 159 315 591
Processing: 731 4370 6559
Total: 890 4685 7150
Followed by just Apache serving requests without MiniVend.....
bill:~% ab -c 30 -n 150 http://www.cool.com/override/ags_test
This is ApacheBench, Version 1.2
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-1999 The Apache Group, http://www.apache.org/
Server Software: Stronghold/2.3
Server Hostname: www.cool.com
Server Port: 80
Document Path: /override/ags_test
Document Length: 381 bytes
Concurrency Level: 30
Time taken for tests: 15.551 seconds
Complete requests: 150
Failed requests: 0
Non-2xx responses: 150
Total transferred: 81450 bytes
HTML transferred: 57150 bytes
Requests per second: 9.65
Transfer rate: 5.24 kb/s received
Connnection Times (ms)
min avg max
Connect: 189 1199 1780
Processing: 581 1630 1739
Total: 770 2829 3519
This test was done at peak time on minivend.com, with a 7-byte page
returned that essentially performed no parsing. I consider these results
pretty respectable. Bear in mind that I am going through a modem on this,
Here is the same thing without my satellite lag:
bill:~% ab -c 30 -n 150 http://www.cool.com/override/ags_test.html
This is ApacheBench, Version 1.2
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-1999 The Apache Group, http://www.apache.org/
Server Software: Stronghold/2.3
Server Hostname: www.cool.com
Server Port: 80
Document Path: /override/ags_test.html
Document Length: 12 bytes
Concurrency Level: 30
Time taken for tests: 10.451 seconds
Complete requests: 150
Failed requests: 0
Total transferred: 41400 bytes
HTML transferred: 1800 bytes
Requests per second: 14.35
Transfer rate: 3.96 kb/s received
Connnection Times (ms)
min avg max
Connect: 189 837 1970
Processing: 491 1085 1000
Total: 680 1922 2970
bill:~% ab -c 30 -n 150 http://www.cool.com/way/cool/override/ags_test
This is ApacheBench, Version 1.2
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 1998-1999 The Apache Group, http://www.apache.org/
Server Software: Stronghold/2.3
Server Hostname: www.cool.com
Server Port: 80
Document Path: /way/cool/override/ags_test
Document Length: 7 bytes
Concurrency Level: 30
Time taken for tests: 21.961 seconds
Complete requests: 150
Failed requests: 0
Total transferred: 69450 bytes
HTML transferred: 1050 bytes
Requests per second: 6.83
Transfer rate: 3.16 kb/s received
Connnection Times (ms)
min avg max
Connect: 159 329 748
Processing: 671 3684 4361
Total: 830 4013 5109
One reason that Yahoo has a reputation for being fast is that they
serve very lightweight HTML. This has an effect, particularly when
using tlink on a crowded network.
Also bear in mind that when you are using AB, each MiniVend session
request is spawning a new session. This requires several operations
that don't occur when the user has a session ID. Still.....
By far the biggest thing is page parsing and complexity. The fewer
MiniVend tags you have per page, the faster your catalog will be.
I know I have gone over this before, but if you do lots of [if ..]
and [calc] and [loop ...] with lots of pricing operations and
lots of database accesses each time, your requests will take much
longer to process. There are some things to look for:
[page page] is faster than [page page=page]
for the a similar reason that a Perl array is faster than a Perl hash.
And try and create UserTag definitions for complex routines; they
are faster than [perl ...] or even [calc ...] as they are pre-compiled.
If it weren't for page parsing, MV would be pretty fast. And the page
parsing is what people like about it. 8-)
MV4 will be even a bit faster -- with no parsed HTML it connects, creates
sessions, updates them, and returns in under 10ms on a Pentium Pro 200. I
consider that pretty fast. The page parser will be somewhat improved in
MV4, but the real gain will be in the improved accessibility to embedded
Perl and the fast new tag access methods.
--
Mike Heins http://www.minivend.com/ ___
Internet Robotics |_ _|____
Function in chaos, finish in 131 Willow Lane, Floor 2 | || _ \
style. -- Unknown Oxford, OH 45056 | || |_) |
<mikeh@minivend.com> |___| _ <
513.523.7621 FAX 7501 |_| \_\
