Improving mod_perl Sites' Performance: Part 4
by Stas Bekman
|
Pages: 1, 2, 3, 4, 5
Are My Variables Shared?
How do you find out if the code you write is shared between the processes or not? The code should be shared, except where it is on a memory page with variables that change. Some variables are read-only in usage and never change. For example, if you have some variables that use a lot of memory and you want them to be read-only. As you know the variable becomes unshared when the process modifies its value.
So imagine that you have this 10Mb in-memory database that resides in
a single variable, you perform various operations on it and want to
make sure that the variable is still shared. For example if you do
some matching regular expression (regex) processing on this variable
and want to use the pos() function, will it make the variable unshared
or not?
The Apache::Peek module comes to rescue. Let's write a module
called MyShared.pm which we preload at server startup, so all the
variables of this module are initially shared by all children.
MyShared.pm
---------
package MyShared;
use Apache::Peek;
my $readonly = "Chris";
sub match { $readonly =~ /\w/g; }
sub print_pos{ print "pos: ",pos($readonly),"\n";}
sub dump { Dump($readonly); }
1;
This module declares the package MyShared, loads the
Apache::Peek module and defines the lexically scoped $readonly
variable which is supposed to be a variable of large size (think about
a huge hash data structure), but we will use a small one to simplify
this example.
More mod_perl Articles |
|
Debugging and Profiling mod_perl Applications Integrating mod_perl with Apache 2.1 Authentication Apache::VMonitor - The Visual System and Apache Server Monitor |
The module also defines three subroutines: match() that does a simple
character matching, print_pos() that prints the current position of
the matching engine inside the string that was last matched and
finally the dump() subroutine that calls the Apache::Peek module's
Dump() function to dump a raw Perl data-type of the $readonly
variable.
Here is the script that prints the process ID (PID) and calls all
three functions. The goal is to check whether pos() makes the
variable dirty and therefore unshared.
share_test.pl
-------------
use MyShared;
print "Content-type: text/plain\r\n\r\n";
print "PID: $$\n";
MyShared::match();
MyShared::print_pos();
MyShared::dump();
Before you restart the server, in httpd.conf set:
MaxClients 2
for easier tracking. You need at least two servers to compare the print outs of the test program. Having more than two can make the comparison process harder.
Now open two browser windows and issue the request for this script several times in both windows, so you get different processes PIDs reported in the two windows and each process has processed a different number of requests to the share_test.pl script.
In the first window you will see something like that:
PID: 27040
pos: 1
SV = PVMG(0x853db20) at 0x8250e8c
REFCNT = 3
FLAGS = (PADBUSY,PADMY,SMG,POK,pPOK)
IV = 0
NV = 0
PV = 0x8271af0 "Chris"\0
CUR = 5
LEN = 6
MAGIC = 0x853dd80
MG_VIRTUAL = &vtbl_mglob
MG_TYPE = 'g'
MG_LEN = 1
And in the second window:
PID: 27041
pos: 2
SV = PVMG(0x853db20) at 0x8250e8c
REFCNT = 3
FLAGS = (PADBUSY,PADMY,SMG,POK,pPOK)
IV = 0
NV = 0
PV = 0x8271af0 "Chris"\0
CUR = 5
LEN = 6
MAGIC = 0x853dd80
MG_VIRTUAL = &vtbl_mglob
MG_TYPE = 'g'
MG_LEN = 2
We see that all the addresses of the supposedly big structure are the
same (0x8250e8c and 0x8271af0), therefore the variable data
structure is almost completely shared. The only difference is in
SV.MAGIC.MG_LEN record, which is not shared.

