You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Dirk Lutzebaeck <lu...@aeccom.com> on 2001/01/23 16:48:14 UTC
Argument caching with POST if ACTION is not set
Hi,
maybe I don't understand but is there a consistent behaviour when
ACTION is not set in a FORM and submitting that form:
Eg.
x.epl:
<form method=post>
<input type=text name=a>
<input type=submit>
</form>
b is [+ $fdat{b} +]
When requesting GET x.epl?b=1 and afterwards hitting the submit button
I see a POST x.epl?b=1 in the apache log.
This is normally not a problem because embperl (CGI.pm?) ignores the
arguments given in the POST request but processes the content of the
request for arguments.
My question is if this is always the case. Considering two apache
children one serving the first request the other child the second
request. Is it always garantueed that it works as expected? Is there
some caching mechanism inbetween? I have the suspicion that maybe
there is a problem because I see sometimes a strange behaviour on my
system not processing POST requests correctly. I can't reproduce it
and it is just a thought.
Is it recommended to set ACTION in the form?
Dirk
Re: LARGE http daemons
Posted by "G.Richter" <ri...@ecos.de>.
> >
> Unfortunately I cannot afford a big luxury to do this. We have approx 135
> virtual webservers here and I'm not the developer of these despite I can
> program in perl and embperl. I simply cannot check for 100 users everyday
> work. We have some especially large projects here, which are intensively
> used and changed. I thought that in some point I should have tools or
> knobs as a server admnistrator to keep one user in certain limits and not
> stomping on resources needed for others.
>
Ok, this is another situation that I initial assumed. In this case you
should limit the life time of Apache childs with MaxRequestsPerChild. That
makes sure a child cannot endless allocate resources, also it leaks.
Additionaly you may use Apache::Resource and Apache::GTopLimit and
Apache::RLimit to control the resource usage of Apache.
As already pointed out
http://perl.apache.org/guide/performance.html#Limiting_the_Size_of_the_Proce
ss contains a description of that. The page also contains other usefull
hints, for limiting resource usage
Gerald
Re: LARGE http daemons
Posted by Neeme Vool <ne...@eenet.ee>.
>
> On the other side you should make sure that your code doesn't leak. Normaly,
> if you request the same page over and over, the httpd shouldn't grow after
> the second request. To test this you may start a httpd with -X option, so
> you have only one child to watch and request the page to test via
> ApacheBench (ab), the httpd should have a constant size, if not something
> inside your app is leaking.
>
Unfortunately I cannot afford a big luxury to do this. We have approx 135
virtual webservers here and I'm not the developer of these despite I can
program in perl and embperl. I simply cannot check for 100 users everyday
work. We have some especially large projects here, which are intensively
used and changed. I thought that in some point I should have tools or
knobs as a server admnistrator to keep one user in certain limits and not
stomping on resources needed for others.
Neeme Vool
Re: LARGE http daemons
Posted by Gerald Richter <ri...@ecos.de>.
>
> Hi, I have Solaris 2.6, 1 GB memory, apache 1.3.14, mod_perl 1.24, embperl
> 1.3b7.
> We have an Embperl+Mysql application with approx 600 simultaneous users.
> I'm suspicious that Embperl causes Apache to grow to the limit it can -
> httpds keep free physical memory limit constantly on level 30-40 MB. When
> tehere are peaks, and we have 70-80 httpds, they are about 20 MB large.
> When need for service drops, they grow to 50 MB.
Perl (mod_perl) really needs a lot of memory and Embperl caches any compiled
Perl code for performance resons. So it's not unusual that you are getting
big httpd's. How big it gets depends on the number of Perl/Embperl pages you
have. You may try to loaded your Embperl pages on server startup via
Execute, so they are shared between httpd childs. It depends on our
application if this gives a better memory usage or not.
As Gunnar already pointed out the mod_perl guide
(http://perl.apache.org/guide/performance.html) has a lot of tunning tips.
On the other side you should make sure that your code doesn't leak. Normaly,
if you request the same page over and over, the httpd shouldn't grow after
the second request. To test this you may start a httpd with -X option, so
you have only one child to watch and request the page to test via
ApacheBench (ab), the httpd should have a constant size, if not something
inside your app is leaking.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
LARGE http daemons
Posted by Neeme Vool <ne...@eenet.ee>.
Hi, I have Solaris 2.6, 1 GB memory, apache 1.3.14, mod_perl 1.24, embperl
1.3b7.
We have an Embperl+Mysql application with approx 600 simultaneous users.
I'm suspicious that Embperl causes Apache to grow to the limit it can -
httpds keep free physical memory limit constantly on level 30-40 MB. When
tehere are peaks, and we have 70-80 httpds, they are about 20 MB large.
When need for service drops, they grow to 50 MB.
pmap shows:
pmap 8331
8331: /usr/local/apache/bin/httpd
0802B000 116K read/write/exec [ stack ]
08050000 1904K read/exec /usr/local/apache/bin/httpd
0823B000 84K read/write/exec /usr/local/apache/bin/httpd
08250000 46332K read/write/exec [ heap ]
DF410000 4K read/write/exec [ anon ]
I dont blame Embperl, but do I have opportunity to tell, (if the cause is
Embperl of course) how much memory it consumes?
Neeme Vool
Tel: +372 7 302 113
Fax: +372 7 302 111
E-mail: Neeme.Vool@eenet.ee
Re: Argument caching with POST if ACTION is not set
Posted by Gerald Richter <ri...@ecos.de>.
Hi,
>
> maybe I don't understand but is there a consistent behaviour when
> ACTION is not set in a FORM and submitting that form:
>
> Eg.
>
> x.epl:
>
> <form method=post>
> <input type=text name=a>
> <input type=submit>
> </form>
> b is [+ $fdat{b} +]
>
>
> When requesting GET x.epl?b=1 and afterwards hitting the submit button
> I see a POST x.epl?b=1 in the apache log.
>
> This is normally not a problem because embperl (CGI.pm?)
Embperl does it, CGI.pm is not involved here
> ignores the
> arguments given in the POST request but processes the content of the
> request for arguments.
>
> My question is if this is always the case.
Embperl always puts the POST data into %fdat, when they are present
> Considering two apache
> children one serving the first request the other child the second
> request. Is it always garantueed that it works as expected? Is there
> some caching mechanism inbetween?
This has nothing to do with Apache. Your browser simply uses the same uses
the URL of your form as ACTION e.g. when you request your form with
x.epl?b=1
your browser will act as if you had wrote
<form method=post action"x.epl?b=1">
> I have the suspicion that maybe
> there is a problem because I see sometimes a strange behaviour on my
> system not processing POST requests correctly.
I don't know if this is your problem, but there is a problem with some
browser, because they behave different. Not all browser uses the form url as
default action. MSIE does it, but not all Netscape versions.
>
> Is it recommended to set ACTION in the form?
>
For the above reasons: Yes!
Just write
<form method=post action="$ENV{SCRIPT_NAME}">
This makes sure the form calls always itself.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------