Apache-ASP
view release on metacpan or search on metacpan
Sessions are easy to understand. When visiting a page in a
web application, each user has one unique $Session. This
session expires, after which the user will have a new
$Session upon revisiting.
A web application starts when the user visits a page in that
application, and has a new $Session created. Right before
the first $Session is created, the $Application is created.
When the last user $Session expires, that $Application
expires also. For some web applications that are always busy,
the Application_OnEnd event may never occur.
=head2 Script_OnStart & Script_OnEnd
The script events are used to run any code for all scripts
in an application defined by a global.asa. Often, you would
like to run the same code for every script, which you would
otherwise have to add by hand, or add with a file include,
but with these events, just add your code to the global.asa,
and it will be run.
Triggered by a user session ending, Session_OnEnd can be useful
for cleaning up and analyzing user data accumulated during a session.
Sessions end when the session timeout expires, and the StateManager
performs session cleanup. The timing of the Session_OnEnd does not
occur immediately after the session times out, but when the first
script runs after the session expires, and the StateManager allows
for that session to be cleaned up.
So on a busy site with default SessionTimeout (20 minutes) and
StateManager (10 times) settings, the Session_OnEnd for a particular
session should be run near 22 minutes past the last activity that Session saw.
A site infrequently visited will only have the Session_OnEnd run
when a subsequent visit occurs, and theoretically the last session
of an application ever run will never have its Session_OnEnd run.
Thus I would not put anything mission-critical in the Session_OnEnd,
just stuff that would be nice to run whenever it gets run.
=head2 Script_OnFlush
starts set to 1, and will be updated whenever a
$Response->Flush() is called. If BufferingOn is
set, by default $Response->Flush() will only be
called at the end of the HTML output.
As of version 2.23 this value is updated correctly
before global.asa Script_OnStart is called, so
global script termination may be correctly handled
during that event, which one might want to do
with excessive user STOP/RELOADS when the web
server is very busy.
An API extension $Response->IsClientConnected
may be called for refreshed connection status
without calling first a $Response->Flush
=item $Response->{PICS}
If this property has been set, a PICS-Label HTTP header will be
sent with its value. For those that do not know, PICS is a header
that is useful in rating the internet. It stands for
On Win32 systems, where mod_perl requests are serialized, you
can freely use SessionSerialize to make your $Session requests
faster, and you can achieve similar performance benefits for
$Application if you call $Application->Lock() in your
global.asa's Script_OnStart.
=head2 Low MaxClients
Set your MaxClients low, such that if you have that
many httpd servers running, which will happen on busy site,
your system will not start swapping to disk because of
excessive RAM usage. Typical settings are less than 100
even with 1 gig RAM! To handle more client connections,
look into a dual server, mod_proxy front end.
=head2 High MaxRequestsPerChild
Set your max requests per child thread or process (in httpd.conf) high,
so that ASP scripts have a better chance being cached, which happens after
they are first compiled. You will also avoid the process fork penalty on
insert font tags on the fly into the output.
+Highlighting and linking of line error when Debug is set to 2 or -2.
--removed fork() call from flock() backup routine? How did
that get in there? Oh right, testing on Win32. :(
Very painful lesson this one, sorry to whom it may concern.
+$Application->SessionCount support turned off by default
must enable with SessionCount config option. This feature
puts an unnecessary load on busy sites, so not default
behavior now.
++XMLSubsMatch setting that allows the developer to
create custom tags XML style that execute perl subroutines.
See ./site/eg/xml_subs.asp
+MailFrom config option that defaults the From: field for
mails sent via the Mail* configs and $Server->Mail()
+$Server->Mail(\%mail, %smtp_args) API extension
$Application->{$Session->SessionID()} = started;
}
Sessions are easy to understand. When visiting a page in a web application,
each user has one unique $Session. This session expires, after which the
user will have a new $Session upon revisiting.
A web application starts when the user visits a page in that application,
and has a new $Session created. Right before the first $Session is created,
the $Application is created. When the last user $Session expires, that
$Application expires also. For some web applications that are always busy,
the Application_OnEnd event may never occur.
Script_OnStart & Script_OnEnd
The script events are used to run any code for all scripts in an application
defined by a global.asa. Often, you would like to run the same code for
every script, which you would otherwise have to add by hand, or add with a
file include, but with these events, just add your code to the global.asa,
and it will be run.
There is one caveat. Code in Script_OnEnd is not guaranteed to be run when
Session_OnEnd
Triggered by a user session ending, Session_OnEnd can be useful for cleaning
up and analyzing user data accumulated during a session.
Sessions end when the session timeout expires, and the StateManager performs
session cleanup. The timing of the Session_OnEnd does not occur immediately
after the session times out, but when the first script runs after the
session expires, and the StateManager allows for that session to be cleaned
up.
So on a busy site with default SessionTimeout (20 minutes) and StateManager
(10 times) settings, the Session_OnEnd for a particular session should be
run near 22 minutes past the last activity that Session saw. A site
infrequently visited will only have the Session_OnEnd run when a subsequent
visit occurs, and theoretically the last session of an application ever run
will never have its Session_OnEnd run.
Thus I would not put anything mission-critical in the Session_OnEnd, just
stuff that would be nice to run whenever it gets run.
Script_OnFlush
$Response->{IsClientConnected}
1 if web client is connected, 0 if not. This value starts set to 1, and
will be updated whenever a $Response->Flush() is called. If BufferingOn
is set, by default $Response->Flush() will only be called at the end of
the HTML output.
As of version 2.23 this value is updated correctly before global.asa
Script_OnStart is called, so global script termination may be correctly
handled during that event, which one might want to do with excessive
user STOP/RELOADS when the web server is very busy.
An API extension $Response->IsClientConnected may be called for
refreshed connection status without calling first a $Response->Flush
$Response->{PICS}
If this property has been set, a PICS-Label HTTP header will be sent
with its value. For those that do not know, PICS is a header that is
useful in rating the internet. It stands for Platform for Internet
Content Selection, and you can find more info about it at:
http://www.w3.org
job caching its file systems, so pick a StateDir for ease of system
administration.
On Win32 systems, where mod_perl requests are serialized, you can freely use
SessionSerialize to make your $Session requests faster, and you can achieve
similar performance benefits for $Application if you call
$Application->Lock() in your global.asa's Script_OnStart.
Low MaxClients
Set your MaxClients low, such that if you have that many httpd servers
running, which will happen on busy site, your system will not start swapping
to disk because of excessive RAM usage. Typical settings are less than 100
even with 1 gig RAM! To handle more client connections, look into a dual
server, mod_proxy front end.
High MaxRequestsPerChild
Set your max requests per child thread or process (in httpd.conf) high, so
that ASP scripts have a better chance being cached, which happens after they
are first compiled. You will also avoid the process fork penalty on UNIX
systems. Somewhere between 50 - 500 is probably pretty good. You do not want
to set this too high though or you will risk having your web processes use
insert font tags on the fly into the output.
+Highlighting and linking of line error when Debug is set to 2 or -2.
--removed fork() call from flock() backup routine? How did
that get in there? Oh right, testing on Win32. :(
Very painful lesson this one, sorry to whom it may concern.
+$Application->SessionCount support turned off by default
must enable with SessionCount config option. This feature
puts an unnecessary load on busy sites, so not default
behavior now.
++XMLSubsMatch setting that allows the developer to
create custom tags XML style that execute perl subroutines.
See ./site/eg/xml_subs.asp
+MailFrom config option that defaults the From: field for
mails sent via the Mail* configs and $Server->Mail()
+$Server->Mail(\%mail, %smtp_args) API extension
lib/Apache/ASP/GlobalASA.pm view on Meta::CPAN
$asp->{Internal}{SessionCount} = 1;
$zero_sessions = 1;
} else {
$asp->{Internal}{SessionCount} = $session_count + 1;
}
$asp->{Internal}->UNLOCK();
}
#X: would like to run application startup code here after
# zero sessions is true, but doesn't seem to account for
# case of busy server, then 10 minutes later user comes in...
# since group cleanup happens after session, Application
# never starts. Its only when a user times out his own
# session, and comes back that this code would kick in.
$asp->Debug("Session_OnStart", {session => $asp->{Session}->SessionID});
$self->ExecuteEvent('Session_OnStart');
}
sub SessionOnEnd {
my($self, $id) = @_;
lib/Apache/ASP/Response.pm view on Meta::CPAN
# is initialized, then aborted will return true, even under normal use.
# This causes a file upload script to not render any output. It may be that this
# check was done too fast for apache, where it might have still been setting
# up the upload, so not to check the outbound client connection yet
#
unless($self->{asp}{Request}) {
$self->{asp}->Out("need to init Request object before running Response->IsClientConnected");
return 1;
}
# IsClientConnected ? Might already be disconnected for busy site, if
# a user hits stop/reload
my $conn = $self->{r}->connection;
my $is_connected = $conn->aborted ? 0 : 1;
if($is_connected) {
my $fileno = eval { $conn->fileno };
if(defined $fileno) {
# sleep 3;
# my $s = IO::Select->new($fileno);
# $is_connected = $s->can_read(0) ? 0 : 1;
lib/Apache/ASP/StateManager.pm view on Meta::CPAN
$self->Debug("forcing groups cleanup") if ($self->{dbg} && $force);
# each apache process has an internal time in which it
# did its last check, once we have passed that, we check
# $Internal for the last time the check was done. We
# break it up in this way so that locking on $Internal
# does not become another bottleneck for scripts
if($force || ($Apache::ASP::CleanupGroups{$state_dir} || 0) < time()) {
# /8 to keep it less bursty... since we check groups every group_refresh/2
# we'll average 1/4 of the groups everytime we check them on a busy server
$Apache::ASP::CleanupGroups{$state_dir} = time() + $self->{group_refresh}/8;
$self->{dbg} && $self->Debug("testing internal time for cleanup groups");
if($self->CleanupMaster) {
$internal->LOCK();
if($force || ($internal->{CleanupGroups} < (time - $self->{group_refresh}/8))) {
$internal->{CleanupGroups} = time;
$cleanup = 1;
}
$internal->UNLOCK;
}
site/changes.html view on Meta::CPAN
insert font tags on the fly into the output.
+Highlighting and linking of line error when Debug is set to 2 or -2.
--removed fork() call from flock() backup routine? How did
that get in there? Oh right, testing on Win32. :(
Very painful lesson this one, sorry to whom it may concern.
+$Application->SessionCount support turned off by default
must enable with SessionCount config option. This feature
puts an unnecessary load on busy sites, so not default
behavior now.
++XMLSubsMatch setting that allows the developer to
create custom tags XML style that execute perl subroutines.
See <a href=eg/xml_subs.asp>./site/eg/xml_subs.asp</a>
+MailFrom config option that defaults the From: field for
mails sent via the Mail* configs and $Server->Mail()
+$Server->Mail(\%mail, %smtp_args) API extension
site/events.html view on Meta::CPAN
}
</pre></font>Sessions are easy to understand. When visiting a page in a
web application, each user has one unique $Session. This
session expires, after which the user will have a new
$Session upon revisiting.
<font face="courier new" size=3><pre>
</pre></font>A web application starts when the user visits a page in that
application, and has a new $Session created. Right before
the first $Session is created, the $Application is created.
When the last user $Session expires, that $Application
expires also. For some web applications that are always busy,
the Application_OnEnd event may never occur.</font>
<p>
<a name=Script_OnSta6a4cfa7f></a>
<font face=verdana><font class=title size=+0 color=#555555><b>Script_OnStart & Script_OnEnd</b></font>
<font face="courier new" size=3><pre>
</pre></font>The script events are used to run any code for all scripts
in an application defined by a global.asa. Often, you would
like to run the same code for every script, which you would
otherwise have to add by hand, or add with a file include,
site/events.html view on Meta::CPAN
<font face="courier new" size=3><pre>
</pre></font>Triggered by a user session ending, Session_OnEnd can be useful
for cleaning up and analyzing user data accumulated during a session.
<font face="courier new" size=3><pre>
</pre></font>Sessions end when the session timeout expires, and the StateManager
performs session cleanup. The timing of the Session_OnEnd does not
occur immediately after the session times out, but when the first
script runs after the session expires, and the StateManager allows
for that session to be cleaned up.
<font face="courier new" size=3><pre>
</pre></font>So on a busy site with default SessionTimeout (20 minutes) and
StateManager (10 times) settings, the Session_OnEnd for a particular
session should be run near 22 minutes past the last activity that Session saw.
A site infrequently visited will only have the Session_OnEnd run
when a subsequent visit occurs, and theoretically the last session
of an application ever run will never have its Session_OnEnd run.
<font face="courier new" size=3><pre>
</pre></font>Thus I would not put anything mission-critical in the Session_OnEnd,
just stuff that would be nice to run whenever it gets run.</font>
<p>
site/objects.html view on Meta::CPAN
starts set to 1, and will be updated whenever a
$Response->Flush() is called. If BufferingOn is
set, by default $Response->Flush() will only be
called at the end of the HTML output.
<font face="courier new" size=3><pre>
</pre></font>As of version 2.23 this value is updated correctly
before global.asa Script_OnStart is called, so
global script termination may be correctly handled
during that event, which one might want to do
with excessive user STOP/RELOADS when the web
server is very busy.
<font face="courier new" size=3><pre>
</pre></font>An API extension $Response->IsClientConnected
may be called for refreshed connection status
without calling first a $Response->Flush</font>
<p>
<a name=%24Response-%3E%7Bc48a3e9e></a>
<font face=verdana><font class=title size=-1 color=#555555><b>$Response->{PICS}</b></font>
<font face="courier new" size=3><pre>
</pre></font>If this property has been set, a PICS-Label HTTP header will be
site/tuning.html view on Meta::CPAN
can freely use SessionSerialize to make your $Session requests
faster, and you can achieve similar performance benefits for
$Application if you call $Application->Lock() in your
global.asa's Script_OnStart.</font>
<p>
<a name=Low%20MaxClien5a8237ea></a>
<font face=verdana><font class=title size=+0 color=#555555><b>Low MaxClients</b></font>
<font face="courier new" size=3><pre>
</pre></font>Set your MaxClients low, such that if you have that
many httpd servers running, which will happen on busy site,
your system will not start swapping to disk because of
excessive RAM usage. Typical settings are less than 100
even with 1 gig RAM! To handle more client connections,
look into a dual server, mod_proxy front end.</font>
<p>
<a name=High%20MaxRequ0724a06d></a>
<font face=verdana><font class=title size=+0 color=#555555><b>High MaxRequestsPerChild</b></font>
<font face="courier new" size=3><pre>
</pre></font>Set your max requests per child thread or process (in httpd.conf) high,
( run in 1.753 second using v1.01-cache-2.11-cpan-87723dcf8b7 )