Apache pnotes

[Jamie Krasnoo]

The Eagle Books explanation of notes isn't very clear. Could someone point
me to a page that explains it somewhat better? In what situation would it be
beneficial to use them?

Jamie Krasnoo
[EMAIL PROTECTED]

Re: templating benchmarks...

[Tom Lancaster]

> This benchmark can be very non-representive. If you don't know how to
> optimize each and every "thing" under test, you end up with unfair
> benchmark and come to potentially wrong conclusions. Take TT, add compiled
> template caching on the disk and shared TT object and I bet TT won't be at
> the bottom.
> 
> In any case always remember that it's extremely hard to run a fair
> benchmark. I'd say it's almost impossible. The only fair benchmarking can
> be done if you know all the in's and out's of the 'things' under test and
> provide many benchmark tests each exploring a single property and not just
> 'one for all' benchmark.
> 
> Of course it's a good thing to have benchmarks, but they all should be
> taken with a grain of salt.
> 

Absolutely. But I'd like to bring up something I've noticed in benchmarking
'real' sites: many, if not all, of the templating solutions appear to 
parse the whole of an html page. This is at least true of Apache::ASP and
HTML::Mason, which I have used. Is it not ?

I have produced really dramatic differences in performance in a two-tier 
setup by judicious use of mod_include vs. wholesale proxying of pages
with dynamic content through to the mod_perl/Apache::ASP server.
For example: 
In a situation with 1 lightweight frontend proxy and two backend 
mod_perl/Apache::ASP app servers ( with load distributed evenly using 
a patched mod_rewrite and its ability to select randomly from a list in a file )
, in one part of the site the dynamic headers and footers are generated by
using , where the file being included is in fact proxied back to the app
servers to receive content; in other parts of the site similarly simple pages
are proxied in their entirety to the app servers.

The results I can produce ( granted only with 'ab' ) are stunningly different:
when I request the header and footer from the app servers using mod_include
plus my modified mod_rewrite ( the stock version refuses to rewrite proxied 
requests ), I get up to 600 requests / second. When proxying the whole page
through I get around 6 requests / second.

Granted, I have other major bottlenecks involved: using Berkeley DB v1.x
for session state, for one. Perhaps this explains some of it -- maybe the 
proxied header/footer requests never make session calls.

I suspect that the wholesale parsing/eval-ing of html pages also plays a part.

What do y'all think ?

Tom

> _



> Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
> http://stason.org/   mod_perl Guide  http://perl.apache.org/guide
> mailto:[EMAIL PROTECTED]   http://apachetoday.com http://eXtropia.com/
> http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
> 

Re: templating benchmarks...

[Stas Bekman]

On Fri, 8 Jun 2001, will trillich wrote:

> On Thu, Jun 07, 2001 at 06:48:38AM +0200, Gerald Richter wrote:
> > > regarding the tools that dovetail into the mod_perl paradigm,
> > > who's got a comparison over relative performance (and other
> > > strengths/weaknesses) of various templating methods?
> >
> > There are various discussions on the mod_perl list about this topic in the
> > past (so take a look at the archives). Also there was an start to write such
> > a comparsion, but I am not aware that anybody has really finished it. The
> > only benchmarks I know are from Joshua. I append his mail below.
> >
> > NOTE: While the hello.xxx benchmarks only prints "Hello world", so they only
> > measures the startup overhead of the toolkit, the h2000.xxx tests tends a
> > little bit more towards a real application.
>
> this is interesting information -- perhaps misleading to use the
> microscopic "hello world" but still it gives a starting point:
>
> here i sorted by hits-per-second
>
> > Test Name  Test File  Hits/sec   Bytes/Hit
> >    -- -- --
> > HTML statichello.html 1158.4 311 bytes
> > mod_include SSIhello.shtm  996.6 198 bytes
> > mod_caucho JSP hello.jsp   860.6 230 bytes
> > mod_perl handler   hello.benc  852.6 196 bytes
> > mod_php PHPhello.php   734.8 225 bytes
> > Apache::Registry v2.01 CGI Raw hello_raw.  706.4 52 bytes
> > Apache::Dispatch v0.08 handler hello/worl  656.1 196 bytes
> > HTML::Template v2.0hello.htmp  567.2 198 bytes
> > Apache::SSI v2.16  hello.shtm  559.4 199 bytes
> > Template v2.00 Toolkit hello.tt522.1 198 bytes
> > Apache::Registry v2.01 CGI.pm  hello.reg   458.5 216 bytes
> > HTML::Embperl v2.0a18  hello.epl   458.2 219 bytes
> > Apache::ASP v2.07  hello.asp   390.6 241 bytes
> > Apache::ePerl  hello.eper  344.8 217 bytes
> > HTML::Mason v0.895 hello.mas   365.3 197 bytes
>
> i bet CGI would be 200.0 or so... ?
>
> and here's the "handler actualy does some work" set:
>
> > mod_caucho JSP 2000h2000.jsp   328.9 28964 byte
> > mod_php PHP 2000   h2000.php   261.8 28865 byte
> > HTML::Embperl v2.0a18 2000 h2000.epl   247.3 28809 byte
> > Apache::ASP v2.07 2000 h2000.asp   228.0 28997 byte
> > HTML::Mason v0.895 2000h2000.mas   222.9 28798 byte
> > Template v2.00 Toolkit 2000h2000.tt 55.6 2 byte
>
> wow. template toolkil took a big hit, there. (no mod_perl on
> this list? hmm!)

This benchmark can be very non-representive. If you don't know how to
optimize each and every "thing" under test, you end up with unfair
benchmark and come to potentially wrong conclusions. Take TT, add compiled
template caching on the disk and shared TT object and I bet TT won't be at
the bottom.

In any case always remember that it's extremely hard to run a fair
benchmark. I'd say it's almost impossible. The only fair benchmarking can
be done if you know all the in's and out's of the 'things' under test and
provide many benchmark tests each exploring a single property and not just
'one for all' benchmark.

Of course it's a good thing to have benchmarks, but they all should be
taken with a grain of salt.

_
Stas Bekman  JAm_pH --   Just Another mod_perl Hacker
http://stason.org/   mod_perl Guide  http://perl.apache.org/guide
mailto:[EMAIL PROTECTED]   http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/

Re: Resetting STDIN after r->read

[Rodney Broom]

From: rodney Broom <[EMAIL PROTECTED]>
> I've got this module that needs to redirect sometimes. In doing this, the
> next request misses any POST data. I was playing with saving the data to
> disk and then reloading it on the next request like this:
>
>   if ($first_pass) {
> $r->read($data, ...);
> print TEMP_FILE, $data;
> return REDIRECT;
>   }
>   else {
> open(STDIN, "<$temp_file");
> $r->subprocess_env(CONTENT_LENGTH => -s $temp_file);
>   }
>
> The idea here is that normal packages like CGI won't have to know what's
up
> and my programmers won't have to work around this. But, when I get to the
> script, STDIN is empty. Ay thouhts about how to handle this?
>

OK, here's what the solution was. According to Doug in a posting that I
found in an archive search, mod_perl's STDIN is really just a Perl glob, and
not a file handle. So instead of reading from it (and thereby emptying the
file handle named STDIN so that CGI and other things can't get this data),
now I simply assign from it:




  if ($first_pass) {
print TEMP_FILE, $STDIN;
return REDIRECT;
  }
  else {
read(TEMP_FILE, my $buf, (-s $temp_file))
$STDIN = $buf;

$r->subprocess_env(CONTENT_LENGTH => -s $temp_file);
  }


I'm obviously doing a lot more testing than that, but this is the jist.

---
Rodney Broom
Programmer: Desert.Net

Re: IP based instant throttle?

[Justin]

I'm glad I haven't got your user.. I think most any site on the
net can be brought to its knees by, for example, stuffing its
site search form with random but very common words and pressing
the post button and issuing these requests as frequently as
possible from a long list of open proxies.. or how about repeatedly
fetching random pages of very old postings such that the SQL
server index/table memory cache becomes useless... nightmare ;)

All one can do is respond with appropriate measures at the time
of the attack, which is why working in modperl is cool because
of the ease with which one can patch in defenses and modify
them while live.

Writing a short script that takes the last 20 minutes of access_log
and automatically identifies abuse based on frequency of request,
IPs and URL patterns, and drops the route to those IPs is a
good start.. to have this auto-triggered from a site monitoring
script is even better.

-Justin

On Thu, Jun 07, 2001 at 08:37:04PM -0700, Jeremy Rusnak wrote:
> Hi all,
> 
> Just thought I would add my two cents...I run an online gaming site
> and the end users often decide to mess with our systems.  We service
> a pretty juvenile crowd in some regards.  So there definately is a
> need for better protection from floods.
> 
> I've had one user in particular who has been attacking our site
> regularly for the past year and a half.  He'll setup a couple
> machines with scripts to call forum posting scripts with random
> information passed into them.  He'll call a generic CGI script
> ten times a second because he can tell it slows down the server.
> He'll bombard the servers with huge UDP packets.  He bulks E-mails
> viruses and zombies to our usersIt's insane.
> 
> In short, this is a big issue for sites that get a decent amount of
> traffic.  Better flood protection is always a good thing.
> 
> We've got a great Cisco firewall that stops a lot of these kinds
> of things, but this fellow discovered open proxies and has been
> a pain ever since.  He has a script that bombards us using a
> different proxy every five seconds.  (There are lists out there
> updated in real-time with hundreds of open proxies thanks to
> the "privacy advocates" on the Net.)
> 
> By the way, the guy is in Spain so the government can't/won't do
> anything.  WE've blocked have the providers in Spain as a result
> of him getting a new IP when he has been stupid enough to use
> a real IP.
> 
> So I would suggest that rate limiting based on IP address is a
> start, but it isn't the end all.  You've got to have a big bag
> of tricks.  Don't just look for one solution.
> 
> Jeremy
> 
> -Original Message-
> From: Martin Redington [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 6:08 PM
> To: [EMAIL PROTECTED]
> Cc: Justin
> Subject: Re: IP based instant throttle?
> 
> 
> 
> Do you get flooded that frequently that this is an issue?
> 
> I've seen DOS, and various buffer overflows etc. in the real world, but 
> I've never seen this.
> 
> Unless its happening very often, I would have thought that some 
> monitoring and a 2am "Deny from ip" in your httpd.conf would be 
> enough ...
> 
> 
> On Friday, June 8, 2001, at 01:50  am, Justin wrote:
> 
> > Does anyone see the value in a Throttle module that looked at
> > the apache parent status block and rejected any request where
> > another child was already busy servicing *that same IP* ?
> > (note: the real IP is in the header in a backend setup so it
> >  is not possible to dig it out across children without
> >  creating another bit of shared memory or using the filesystem?).
> >
> > I'm still finding existing throttle modules do not pickup and
> > block parallel or fast request streams fast enough .. ok there are
> > no massive outages but 10 seconds of delay for everyone because
> > all demons are busy servicing the same guy before we can conclude
> > we're being flooded is not really great.. modperl driven forums
> > (or PHP ones even) can be killed this way since there are so
> > many links on one page, all active..
> >
> > thanks for any thoughts on this.
> >
> > -Justin
> >

Re: IP based instant throttle?

[Justin]

good ideas, thanks.

as someone said its cloggage on the backend due to either
SQL server contention or more likely largish pages draining
to the user even with all the buffers en-route helping to
mitigate this. you can't win : if they are on a modem they can
tie up 8 modperl demons, and if they are on a cable modem they
can disrupt your SQL server creating select/insert locks and
yet more stalled stuff. A cable modem, user could request
1mbit/s of dynamic content.. thats a big ask..

Since the clogging is not images (that is hopefully handled by
an image server like mathopd), its modperl pages, I'm going to
try a timed ban triggered by parallel requests from a single IP.

And yes it does happen often enough to annoy.. (often might be
two or three times a day even though as a percentage of uniques
its very tiny) since many of the culprits don't even know what
they've got installed on their PCs and are on dhcp addresses
and probably never return anyway IP bans after the event are
never any good and may hit the next user who picks up the IP.

-Justin

On Thu, Jun 07, 2001 at 07:34:45PM -0700, Randal L. Schwartz wrote:
> > "Justin" == Justin  <[EMAIL PROTECTED]> writes:
> 
> Justin> Does anyone see the value in a Throttle module that looked at
> Justin> the apache parent status block and rejected any request where
> Justin> another child was already busy servicing *that same IP* ?
> Justin> (note: the real IP is in the header in a backend setup so it
> Justin>  is not possible to dig it out across children without
> Justin>  creating another bit of shared memory or using the filesystem?).
> 
> Justin> I'm still finding existing throttle modules do not pickup and
> Justin> block parallel or fast request streams fast enough .. ok there are
> Justin> no massive outages but 10 seconds of delay for everyone because
> Justin> all demons are busy servicing the same guy before we can conclude
> Justin> we're being flooded is not really great.. modperl driven forums
> Justin> (or PHP ones even) can be killed this way since there are so
> Justin> many links on one page, all active.. 
> 
> It would be pretty simple, basing it on my CPU-limiting throttle that
> I've published in Linux Magazine
> .  Just grab a
> flock on the CPU-logging file in the post-read-request phase instead
> of writing to it.  If you can't get the flock, reject the request.
> Release the flock by closing the file in the log phase.
> 
> But this'd sure mess up my ordinary visit to you, since my browser
> makes 4 connections in parallel to fetch images, and I believe most
> browsers do that these days.
> 
> -- 
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
> <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Resetting STDIN after r->read

[rodney Broom]

From: Geoffrey Young <[EMAIL PROTECTED]>
> of course
> http://perl.apache.org/guide/snippets.html#Redirecting_POST_Requests


Heh, close. I'm using an external redirect because my purpose is to reset
the address in the client's "Location" bar. So an internal redirect won't
give me the desired effect.

---
Rodney Broom
Programmer: Desert.Net

RE: Resetting STDIN after r->read

[Geoffrey Young]

> -Original Message-
> From: rodney Broom [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 08, 2001 3:25 PM
> To: [EMAIL PROTECTED]
> Subject: Resetting STDIN after r->read
> 
> 
> 
> I've got this module that needs to redirect sometimes. In 
> doing this, the
> next request misses any POST data. I was playing with saving 
> the data to
> disk and then reloading it on the next request like this:
> 
>   if ($first_pass) {
> $r->read($data, ...);
> print TEMP_FILE, $data;
> return REDIRECT;
>   }
>   else {
> open(STDIN, "<$temp_file");
> $r->subprocess_env(CONTENT_LENGTH => -s $temp_file);
>   }
> 
> The idea here is that normal packages like CGI won't have to 
> know what's up
> and my programmers won't have to work around this. But, when 
> I get to the
> script, STDIN is empty. Ay thouhts about how to handle this?

of course
http://perl.apache.org/guide/snippets.html#Redirecting_POST_Requests

--Geoff
 

Resetting STDIN after r->read

[rodney Broom]

I've got this module that needs to redirect sometimes. In doing this, the
next request misses any POST data. I was playing with saving the data to
disk and then reloading it on the next request like this:

  if ($first_pass) {
$r->read($data, ...);
print TEMP_FILE, $data;
return REDIRECT;
  }
  else {
open(STDIN, "<$temp_file");
$r->subprocess_env(CONTENT_LENGTH => -s $temp_file);
  }

The idea here is that normal packages like CGI won't have to know what's up
and my programmers won't have to work around this. But, when I get to the
script, STDIN is empty. Ay thouhts about how to handle this?

---
Rodney Broom
Programmer: Desert.Net

Re: comparison of templating methods?

[Gerald Richter]

> At 02:26 PM 6/7/2001 +1000, Steve Smith wrote:
> > > HTML::Embperl
> >
> >For me, this has one major win over the other toolkits: auto form
> >population from a hash.  The online mortgage application system I
> >wrote has about 1,800 form fields, which have to be populated with
> >data from a database.  By making the form fields match DB column
> >names, I can reduce the code to do this to:
> >
> >my $data = $dbh->fetchrow_hashref($query);
> >%fdat = (%fdat, %$data);
> >
> >Embperl then parses the form and populates it with the matching
> >name=>value pairs in %fdat, including select options.  Beautiful!
>
> Not that it's a reality now, but this is one of the things that the Perl
> Widget Library project on source forge is hoping to accomplish for
template
> languages. It's a cross template way of organizing form information and
map
> it to db fields.
>
> The reality is that there are many fields that cannot map easily 1-1 to a
> database as you say. eg a date in a database is usually a date field. But
> in a form, it might be a combination of 3 form fields (dropdown for month,
> year and day separately).
>

Such things could be solved by using DBIx::Recordset for database access and
define some filters, which are able to transform the content of a field
to/from format you need it.

Gerald


-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:   Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131
WWW:http://www.ecos.de  Fax:  +49 6133 925152
-

Re: Apache::AutoIndex & SuppressHTMLPreamble directive

[Philippe M . Chiasson]

On Fri, Jun 08, 2001 at 05:21:31PM +0100, tim fulcher wrote:
> 
> Has anybody else noticed a bug with Apache::AutoIndex & the IndexOptions
> SuppressHTMLPreamble directive ? First time I tried using this I got a
> warning:
> 
> "IndexOptions unknown/unsupported directive suppresshtmlpreamble"
> 
> Then I noticed that  line 37 of AutoIndex.pm has a typo -
> 
> suppresshtmlperamble => SUPPRESS_PREAMBLE
>

Typo noted.

> I edited that & tried again - it worked of sorts, in that Apache didn't
> barf, but the resultant HTML contains 2 head sections:-

I see, well, as Apache::AutoIndex re-implements mod_autoindex in perl,
I probably left that part out.  A simple if() should address this.

Thanks, will try to get a patched version on CPAN this week-end.

P.S. Patch welcome ;-)

>  "http://www.w3.org/TR/REC-html40/loose.dtd";>
> 
> Directory index of
> /tools/Directory index of
> /tools/
> 
> 
> fooo
> 
> 
> can u see this header name directive?
> 
> 
> 
> I'm using v 0.08 of Apache::AutoIndex - couldn't see a later version on
> CPAN.
> 
> 
> Tim
> 
> 

-- 
+---+
| Philippe M. Chiasson  <[EMAIL PROTECTED]>|
| SmartWorker http://www.smartworker.org|
| IM : gozerhbe  ICQ : gozer/18279998   |
|   64.8% computer corrupt according to |
| http://www.freespeech.org/ljk/purity.html |
+---+
I'm always amazed at how many people expect to be both
elitist and populist simultaneously. 
-- Larry Wall

perl -e '$$=\${gozer};{$_=unpack(P26,pack(L,$$));/^Just Another Perl 
Hacker!\n$/&&print||$$++&&redo}'

Apache::AutoIndex & SuppressHTMLPreamble directive

[tim fulcher]

Has anybody else noticed a bug with Apache::AutoIndex & the IndexOptions
SuppressHTMLPreamble directive ? First time I tried using this I got a
warning:

"IndexOptions unknown/unsupported directive suppresshtmlpreamble"

Then I noticed that  line 37 of AutoIndex.pm has a typo -

suppresshtmlperamble => SUPPRESS_PREAMBLE
   

I edited that & tried again - it worked of sorts, in that Apache didn't
barf, but the resultant HTML contains 2 head sections:-

http://www.w3.org/TR/REC-html40/loose.dtd";>

Directory index of
/tools/Directory index of
/tools/


fooo


can u see this header name directive?



I'm using v 0.08 of Apache::AutoIndex - couldn't see a later version on
CPAN.


Tim

Re: mod_perl 1.25 , perl 5.6.x , Redhat7.1

[Ged Haywood]

Hi Tomas,

On Fri, 8 Jun 2001, Tomas Zeman wrote:

> Compiler in redhat 7.1 should be OK, because module
> compiles ok,

I don't follow your logic there.

> but error is in perl 5.6.x 9I think),
> because on the same platform, it worked with perl 5.5

Quite possible, all the same.  I still use 5.005_03 in my live
servers.  I recommend you do the same if it works for you.  There is
no Perl release called 5.5.  I have had no problems with 5.7.0 in
development, you might like to try it if you're adventurous...

73,
Ged.

RE: IP based instant throttle?

[Christian Gilmore]

You'd want to look at the scoreboard. mod_throttle_access
(http://www.fremen.org/apache/) does this function based upon URI. The
only changes would be to base it upon client IP and change the scope to
allow it to be outside a  block. It would be a minor change.

Regards,
Christian

> -Original Message-
> From: Justin [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 7:51 PM
> To: [EMAIL PROTECTED]
> Subject: IP based instant throttle?
>
>
> Does anyone see the value in a Throttle module that looked at
> the apache parent status block and rejected any request where
> another child was already busy servicing *that same IP* ?
> (note: the real IP is in the header in a backend setup so it
>  is not possible to dig it out across children without
>  creating another bit of shared memory or using the filesystem?).
>
> I'm still finding existing throttle modules do not pickup and
> block parallel or fast request streams fast enough .. ok there are
> no massive outages but 10 seconds of delay for everyone because
> all demons are busy servicing the same guy before we can conclude
> we're being flooded is not really great.. modperl driven forums
> (or PHP ones even) can be killed this way since there are so
> many links on one page, all active..
>
> thanks for any thoughts on this.
>
> -Justin
>

Re: mod_perl 1.25 , perl 5.6.x , Redhat7.1

[Tomas Zeman]

Hi, I already tried to find solution in archive and on
google.com, but I wasn't succesfull.

Compiler in redhat 7.1 should be OK, because module
compiles ok, but error is in perl 5.6.x 9I think),
because on the same platform, it worked with perl 5.5
!


Tomas

>Date: Thu, 7 Jun 2001 22:17:54 +0100 (BST)
>To: Tomas Zeman <[EMAIL PROTECTED]>
>From: Ged Haywood <[EMAIL PROTECTED]>
>cc: [EMAIL PROTECTED]
>Subject: Re: mod_perl 1.25 , perl 5.6.x , Redhat7.1
>problem
>Hi there,

>On Thu, 7 Jun 2001, Tomas Zeman wrote:

> I have tried Perl 5.6.0 and 5.6.1, mod_perl 1.24 and
> 1.25, apache 1.3.9 and 1.3.20, but I am not able to
> make it work (on Redhat 7.1)
> 
> It worked OK with redhat 6.2 with perl 5.5
> 
> I compiled perl 5.6.1 and apache myself, mod_perl
> compiles OK (as DSO), but when I try to run the
> apache, it writes :

>There were problems with the compiler shipped with a
>recent version of
>RedHat, can't remeber if it was 7.0 or 7.1, but it's
>worth checking in
>the mod_perl List archives where it has been
>mentioned.  Apart from
>gcc I think there's no reason why you should not be
>able to get it
>going on that platform.  Try to keep the
>configuration to as simple  a
>minimum as you can, and I'd try static instead of DSO
>first.

>Get back to us if you've already tried a different
>compiler.

>73,
>Ged.


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Re: Help with parameters.]

[Issac Goldstand]

> > > I have built modperl 1.25.
> > >
> > > I could run perl scripts fine.
> > >
> > > How can I send parameters to a perl scripts?
> > >
> > > Using  http://mydomain.com/perl/foreach.pl?200+300 does not seem to
work.
> >
> > you'll need to do it as something like
> > http://mydomain.com/perl/foreach.pl?num1=200&num2=300
> >
> > then do :
> >
> > my $q=new CGI;
> > my $num1=$q->param('num1');
> > my $num2=$q->param('num2');
> >
> > Parameters work a bit different in mod_perl.
> >
> >   Issac
> >
> > PS.  Stas - you DID remember to put this into the book somewhere...
didn't
> > you?  I'm sincerely praying that I just don't remember where... :)
>
> What do you mean? Are you talking about $r->args?
> http://perl.apache.org/guide/snippets.html#CGI_params_in_the_mod_perl_ish_
> If so, yes, it handles empty values differently from CGI::param.
>

No.  Since the book is designed for newbies, as far as I can see anyway, I
think that there should be a section somewhere explaining that parameters in
the CGI world work different from parameters in the command line script
world.  You should explain how the argument array is not used in
CGI/mod_perl, but rather paramters are passed as key/value pairs which are
read from the request.  Explain the basics of it, and maybe give an example
HTML snippet like:





And explain that if the user typed in "Issac" in the first box and
"Goldstand" in the second box, his perl script would get these paramters in
a key/pair list (which can be placed into a nice little hash) and then
accessed...

Give a little example:

print "Hello $form{givenName} $form{lastName}.  Your email address is
$form{emailAddress}.\n";

That's what I was referring to.  And I don't _think_ it's in the book.  And
if you'll look at the original question, it apparatly IS a newbie issue.

  Issac

Internet is a wonderful mechanism for making a fool of
yourself in front of a very large audience.
  --Anonymous

Moving the mouse won't get you into trouble...  Clicking it might.
  --Anonymous

PGP Key 0xE0FA561B - Fingerprint:
7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B

Re: comparison of templating methods?

[will trillich]

On Fri, Jun 08, 2001 at 06:52:14PM +0800, Gunther Birznieks wrote:
> At 02:26 PM 6/7/2001 +1000, Steve Smith wrote:
> > > HTML::Embperl
> >
> >For me, this has one major win over the other toolkits: auto form
> >population from a hash.  The online mortgage application system I
> >wrote has about 1,800 form fields, which have to be populated with
> >data from a database.  By making the form fields match DB column
> >names, I can reduce the code to do this to:
> >
> >my $data = $dbh->fetchrow_hashref($query);
> >%fdat = (%fdat, %$data);
> >
> >Embperl then parses the form and populates it with the matching
> >name=>value pairs in %fdat, including select options.  Beautiful!
> 
> Not that it's a reality now, but this is one of the things that the Perl 
> Widget Library project on source forge is hoping to accomplish for template 
> languages. It's a cross template way of organizing form information and map 
> it to db fields.
> 
> The reality is that there are many fields that cannot map easily 1-1 to a 
> database as you say. eg a date in a database is usually a date field. But 
> in a form, it might be a combination of 3 form fields (dropdown for month, 
> year and day separately).

which of the existing paradigms will the widget farm most
closely resemble? and what are your expectations for tradeoff in
functionality/modularity-vs-performance?

-- 
I figure: if a man's gonna gamble, may as well do it
without plowing.   -- Bama Dillert, "Some Came Running"

[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!

templating benchmarks...

[will trillich]

On Thu, Jun 07, 2001 at 06:48:38AM +0200, Gerald Richter wrote:
> > regarding the tools that dovetail into the mod_perl paradigm,
> > who's got a comparison over relative performance (and other
> > strengths/weaknesses) of various templating methods?
> 
> There are various discussions on the mod_perl list about this topic in the
> past (so take a look at the archives). Also there was an start to write such
> a comparsion, but I am not aware that anybody has really finished it. The
> only benchmarks I know are from Joshua. I append his mail below.
> 
> NOTE: While the hello.xxx benchmarks only prints "Hello world", so they only
> measures the startup overhead of the toolkit, the h2000.xxx tests tends a
> little bit more towards a real application.

this is interesting information -- perhaps misleading to use the
microscopic "hello world" but still it gives a starting point:

here i sorted by hits-per-second 

> Test Name  Test File  Hits/sec   Bytes/Hit
>    -- -- --
> HTML statichello.html 1158.4 311 bytes
> mod_include SSIhello.shtm  996.6 198 bytes
> mod_caucho JSP hello.jsp   860.6 230 bytes
> mod_perl handler   hello.benc  852.6 196 bytes
> mod_php PHPhello.php   734.8 225 bytes
> Apache::Registry v2.01 CGI Raw hello_raw.  706.4 52 bytes
> Apache::Dispatch v0.08 handler hello/worl  656.1 196 bytes
> HTML::Template v2.0hello.htmp  567.2 198 bytes
> Apache::SSI v2.16  hello.shtm  559.4 199 bytes
> Template v2.00 Toolkit hello.tt522.1 198 bytes
> Apache::Registry v2.01 CGI.pm  hello.reg   458.5 216 bytes
> HTML::Embperl v2.0a18  hello.epl   458.2 219 bytes
> Apache::ASP v2.07  hello.asp   390.6 241 bytes
> Apache::ePerl  hello.eper  344.8 217 bytes
> HTML::Mason v0.895 hello.mas   365.3 197 bytes

i bet CGI would be 200.0 or so... ?

and here's the "handler actualy does some work" set:

> mod_caucho JSP 2000h2000.jsp   328.9 28964 byte
> mod_php PHP 2000   h2000.php   261.8 28865 byte
> HTML::Embperl v2.0a18 2000 h2000.epl   247.3 28809 byte
> Apache::ASP v2.07 2000 h2000.asp   228.0 28997 byte
> HTML::Mason v0.895 2000h2000.mas   222.9 28798 byte
> Template v2.00 Toolkit 2000h2000.tt 55.6 2 byte

wow. template toolkil took a big hit, there. (no mod_perl on
this list? hmm!)

-- 
I figure: if a man's gonna gamble, may as well do it
without plowing.   -- Bama Dillert, "Some Came Running"

[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!

-- 
I figure: if a man's gonna gamble, may as well do it
without plowing.   -- Bama Dillert, "Some Came Running"

[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!

Re: IP based instant throttle?

[Roman Maeder]

[EMAIL PROTECTED] said:
> Well, if the reason you're throttling is to block excessive usage of
> the machine, the full monty of CPU limiting will do that just fine, 

one kind of DOS would not be caught by looking at CPU usage, it is one
that I have experienced a number of times, namely the use of some
misconfigured offline browsing tool that would just open as many
concurrent connections as it can until it has read all pages on your
server. I don't know whether some of these tools are misconfigured out of
the box, or users changed the settings. Some idiots do that even
behind a modem, so the limit is not CPU but bandwidth, as all of
these connections go through the same slow wire. Your CPU
will then be mostly idle, with full IP output queues and all Apache
processes in the "W" sate. As soon one of the requests times out, the
tool opens a new one.

It should be easy to hack Apache::SpeedLimit to count concurrent
accesses instead of number of accesses over a certain time and
lock out the client if it reaches some max number. Is this the
best way to do this or are there better ideas?

Roman Maeder

Re: comparison of templating methods?

[will trillich]

On Fri, Jun 08, 2001 at 10:49:39AM +0800, Stas Bekman wrote:
> This is your "ultimate" answer :) :
> 
> Choosing a Templating System.
> http://conferences.oreillynet.com/cs/os2001/view/e_sess/1263
> 
> Hopefully Perrin will release his paper close to the conference.

looking forward to that! thanks.

-- 
I figure: if a man's gonna gamble, may as well do it
without plowing.   -- Bama Dillert, "Some Came Running"

[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!

Re: IP based instant throttle?

[Randal L. Schwartz]

> "Ken" == Ken Williams <[EMAIL PROTECTED]> writes:

Ken> [EMAIL PROTECTED] (Randal L. Schwartz) wrote:
>> It would be pretty simple, basing it on my CPU-limiting throttle that
>> I've published in Linux Magazine
>> .  Just grab a
>> flock on the CPU-logging file in the post-read-request phase instead
>> of writing to it.  If you can't get the flock, reject the request.
>> Release the flock by closing the file in the log phase.
>> 
>> But this'd sure mess up my ordinary visit to you, since my browser
>> makes 4 connections in parallel to fetch images, and I believe most
>> browsers do that these days.

Ken> I was thinking about that too, and concluded that you'd only want to
Ken> throttle the back-end server in a 2-server setup.  That would usually
Ken> (save for subrequests) only be 1 request throttled per page-load.  I
Ken> tend not to care about the front-end, because overload is rarely a
Ken> problem there.

Well, if the reason you're throttling is to block excessive usage of
the machine, the full monty of CPU limiting will do that just fine,
since images are delivered quickly, but anything that eats CPU starts
pushing the counter up to the max.  That's why I have my CPU
throttler, and it worked fine to prevent me from being "slashdotted"
that one day I was mentioned there.  I'm told that my CPU throttler
was used at etoys.com for a similar purpose, and permitted them to
keep from losing millions of dollars of revenue due to people
spidering their catalog.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

RE: Running Mod_Perl on Windows

[Geoffrey Young]

In general, questions on installation, etc are best 
directed to the mod_perl list ([EMAIL PROTECTED]) after searching through 
the other resources available to you from
http://perl.apache.org
especially
http://perl.apache.org/guide
and
http://perl.apache.org/#maillists
 
using a binary distribution for mod_perl on win32 seems 
to be the solution of choice:
http://perl.apache.org/distributions.html
 
but if you need to compile from source, check out 

INSTALL.win32
in the mod_perl distribution
 
HTH
 
--Geoff
 

  -Original Message-From: Antoine E. Hall 
  [mailto:[EMAIL PROTECTED]]Sent: Friday, June 08, 2001 2:14 
  AMTo: [EMAIL PROTECTED]Subject: Running Mod_Perl on 
  Windows
  Geoff,  
   
  I got your information off of the take23.org 
  website.  I am trying to configure Mod_Perl to run under Apache.  I 
  installed the ActiveState Perl Build 626 and I Installed Apache 1.3.20.  
  I also downloaded Mod_Perl 1.25, but I cannot figure out how to configure my 
  httpd.conf file for Apache.  When I try to make a reference to 
  PerlHandler or PerlRequire, I get an error saying something like, I didn't 
  load a module.  Any idea what I may be doing wrong?
   
  Thanks,
   
  Antoine

Re: comparison of templating methods?

[Gunther Birznieks]

At 02:26 PM 6/7/2001 +1000, Steve Smith wrote:
> > HTML::Embperl
>
>For me, this has one major win over the other toolkits: auto form
>population from a hash.  The online mortgage application system I
>wrote has about 1,800 form fields, which have to be populated with
>data from a database.  By making the form fields match DB column
>names, I can reduce the code to do this to:
>
>my $data = $dbh->fetchrow_hashref($query);
>%fdat = (%fdat, %$data);
>
>Embperl then parses the form and populates it with the matching
>name=>value pairs in %fdat, including select options.  Beautiful!

Not that it's a reality now, but this is one of the things that the Perl 
Widget Library project on source forge is hoping to accomplish for template 
languages. It's a cross template way of organizing form information and map 
it to db fields.

The reality is that there are many fields that cannot map easily 1-1 to a 
database as you say. eg a date in a database is usually a date field. But 
in a form, it might be a combination of 3 form fields (dropdown for month, 
year and day separately).

Later,
Gunther