Re: Linux Hello World Benchmarks - 11/19/2001
Perrin Harkins wrote: > > on 11/19/01 8:05 PM, Joshua Chamas at [EMAIL PROTECTED] wrote: > > It has been a while, but here's a new set of Hello World benchmarks! > > There was a recent announcement of HTML::Template::JIT, and Template Toolkit > has an XS option now. Any chance you could put those into the next round? > - Perrin OK, I upgraded Template Toolkit to version 2.06 with XS option on for all templates, and performance is much improved!! However, HTML::Template::JIT will likely not work on my system any time soon, because it was written for perl 5.6, and I only run 5.00503 currently. Someone else can submit a test & config specifically for HTML::Template::JIT, I'd suggest the h2000 type where speed matters, and I'll add it to the test suite even it I can't run the benchmark myself. [hello]# ./bench.pl -type=2000 -ram -time=60 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - Apache::ASP 2000h2000.asp 209.4 12566 60.020.004776 28998 33200 Apache::Registry 2000 mod_perl API h2000.reg 327.0 19622 60.020.003059 28179 15300 HTML::Embperl 2000 h2000.epl 107.5 6465 60.120.009299 28841 20048 HTML::Mason 2000h2000.mas 80.8 4849 60.000.012374 28799 110292 HTML::Template 2000 h2000.htm 95.4 5724 60.010.010484 29152 49932 mod_php PHP 2000h2000.php 247.6 14862 60.020.004038 28866 10384 Template Toolkit 2000 h2000.tt 125.5 7533 60.020.007967 28889 55748 -- Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: Linux Hello World Benchmarks - 11/19/2001
on 11/19/01 8:05 PM, Joshua Chamas at [EMAIL PROTECTED] wrote: > It has been a while, but here's a new set of Hello World benchmarks! There was a recent announcement of HTML::Template::JIT, and Template Toolkit has an XS option now. Any chance you could put those into the next round? - Perrin
Linux Hello World Benchmarks - 11/19/2001
Hey, [[ NUMBERS ARE BELOW ]] It has been a while, but here's a new set of Hello World benchmarks! What took me so long in getting these out is that the java web environments that I had set up would keep crashing during the tests in ways that would not only render their benchmarks meaningless, but also skewed the results for other tests, say when a java thread would spin out of control! You can download the latest benchmark suite to run on your system at: http://www.chamas.com/bench/hello.tar.gz It seems to run on linux & solaris just fine, though the tests that are run depend on what environments you have set up. Please see the distribution README on how to run the suite for yourself. --Josh METHODOLOGY: These latest numbers come from my running the pubbench.sh script: ]# cat pubbench.sh #!/bin/bash ./bench.pl -version --ram --init-exec="perl javainit.pl -restart" -time=180 --store=results perl ./javainit.pl -stop The javainit.pl will kill any of my existing java environments, and if the current test needs java will start them up. The test run for 180 seconds total in 60 second batches, and for each 60 second run the javainit.pl script will be executed. The --ram flag attempts to calculate the RAM used by each test on my linux system during each 60 second test with the results averaged across each, so for applications with memory leaks, the RAM used only shows 60 seconds worth of them. The RAM calculation looks at RAM used & SWAP used from the linux /proc/meminfo file... as it looks at RAM before the httpd is fired up, but after the init-exec script executes, the RAM does not take into account the java web server environments being started, just memory usage that occurs after they start being used. DISCLAIMER: These numbers are just that, numbers. Please don't let them upset you. If you have a positive contribution that you would like to make, you may download the source code and submit patches ( preferably as diff -u ) to the test suite. This benchmark suite has evolved over years of benchmarking, and takes the point of view that web environments can only be well compared when run on the exact same system configuration... this is why the suite is done is such a way that you can run it on _your_ system giving you results relevant to you! NUMBERS: And without further adieu ... ( see NOTES below ) Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - Apache::ASP v2.29 2000 h2000.asp 216.8 39042180.090.004613 28998 33632 Apache::Registry v2.01 2000 mod_per h2000.reg 341.3 61442180.040.002930 28179 16081 HTML::Embperl v1.3.0 2000 h2000.epl 113.2 20391180.120.008833 28841 20418 HTML::Mason v1.03 2000 h2000.mas 84.0 15115180.030.011911 28799 112220 HTML::Template v2.4 2000h2000.htm 99.1 17848180.030.010087 29152 50292 mod_caucho JSP 2000 h2000.jsp 97.6 17617180.540.010248 28965 14057 mod_jserv JSP 2000 h2000.jsp 148.7 26773180.040.006725 29408 29613 mod_php PHP 2000h2000.php 258.2 46477180.020.003873 28866 10212 Template v2.04 Toolkit 2000 h2000.tt53.3 9604180.030.018745 28889 55629 Test Name Test File Hits/sec # of Hits Time(sec) secs/Hit Bytes/Hit Mem(KB) - - - - - - - - Apache::ASP v2.29 hello.asp 349.8 62985180.050.002859 242 29601 Apache::Dispatch v0.09 handler hello/wor 585.8105443180.010.001707 197 9205 Apache::ePerl hello.epe 347.1 62508180.080.002881 218 17477 Apache::Registry v2.01 CGI Raw hello.cgi 677.7122003180.030.001476 5213061 Apache::Registry v2.01 CGI.pm hello.cgi 449.7 80967180.050.002224 217 20717 Apache::SSI v2.16 hello.sht 546.7 98426180.030.001829 200 13061 CGI::SpeedyCGI CGI Raw hello.scg 159.6 28722180.000.006267 197 9748 CGI::SpeedyCGI CGI.pm hello.scg 145.1 26117180.010.006892 217 10648 HTML static hello.htm 879.215170.610.001137 312 1982 HTML::Embperl v1.3.0hello.epl 463.6 83471180.050.002157 221 17333 HTML::Mason v1.03 hello.mas 368.5 66348180.040.002714 198 29009 HTML::Template v2.4
Test.. Do ignore..
This is a test message..
[OT] [But fun] Cookies and Microsoft
Speaking of the risks of using cookies for auth* stuff: http://dailynews.yahoo.com/h/cn/2009/tc/microsoft_apologizes_in_security_flap_1.html ~~~ Nick Tonkin
[ANNOUNCE] AI::Menu 0.01
The uploaded file AI-Menu-0.01.tar.gz has entered CPAN as file: $CPAN/authors/id/J/JS/JSMITH/AI-Menu-0.01.tar.gz size: 5587 bytes md5: 8272d6782f0cb041e27ffd50cd38ce56 readme: http://sourceforge.net/project/shownotes.php?release_id=62025 download: http://prdownloads.sourceforge.net/perlkb/AI-Menu-0.01.tar.gz This is part of the PerlKB project: http://sourceforge.net/projects/perlkb/ This is an attempt to take a graph representing arbitrary relationships between categories and functions and turn it into a tree that can be used as a menu. This should be considered experimental at this point. See the readme for a list of known issues. +-- James Smith - [EMAIL PROTECTED] | http://www.jamesmith.com/ [EMAIL PROTECTED] | http://cis.tamu.edu/systems/opensystems/ +--
Re: Fastcgi on win [Was: Re: Documentation patch for mod_perl?]
Greetings. >> So mod_perl has a slight speed edge over fastcgi (which is overthrottled a >> little with four servers). >Really? Maybe this is because multi-process handling isn't as fast on NT. >Does it change much if you vary the number of servers? Well, I am getting a little wary of the numbers I get with ab, and on the significance of the -c[oncurrency] switch. In fact, by using different logins on the same client machine (rather than blasting the server from a single login), I get consistently lower request per second numbers than I previously posted (in the 7 rps for mod_perl, 5rps for fastcgi). Besides, as I am testing a single CPU load machine against a single CPU server machine, I am sort of measuring the ratio of the respective process/thread/whatever switching efficiency, whereas I would really need separate (or multiple CPU) clients. The gist of all this is that changing numbers of servers does not seem to matter much, but that happens at a juncture where nothing else does. For what it's worth though, mod_perl tends to be consistently a little faster. >My goal is to give some kind of useful suggestion to people who need better >performance on NT than mod_perl can currently give. That probably requires a definition of performance - not easy. If the goal is responsiveness, and response times are very variable, then anything (including CGI) would be more performant, given that a stuck mod_perl freezes the entire server. Other application domains, however, will probably warrant different metrics. From the vantage point where I am standing now, fastCGI does not look bad (but I really have to test it much more than this). For people that do not like the constraints of Apache::Registry, this solution may not be ideal at all, though... Cheers, alf
Re: Doing Authorization using mod_perl from a programmers perspective
* Randal L. Schwartz ([EMAIL PROTECTED]) [09 11:00]: > > "Jon" == Jon Robison <[EMAIL PROTECTED]> writes: > > Jon> Randall, you want to expound upon that? > > Barely ignoring the spelling of my name, I'll simply claim > > "it's not unique". > > Neither is IP address. Or anything that you haven't specifically > round-tripped to the browser. And that doesn't stop someone from > making another browser respond in the same way, or that browser > respond in a different way. > > But this is obvious. I'm confused about why I'd have to explain it. :( > I think Randal has pointed out many times, as have others, that a browser isn't a person. One doesn't want to authenticate browsers, one wants to authenticate people. Using browser specific information to authenticate a person is not only impossible to do successfully, it is silly to try. Using cookies is only a little bit less unsuccessful. Also, please be sure to note the gotcha in the mod_perl guide that gives you warning that all browsers behave differently when dealing with a 401 status code. Be sure to take that into account. Thanks, JJ -- J. J. Horner "H*","6a686f726e657240326a6e6574776f726b732e636f6d" *** "H*","6a6a686f726e65724062656c6c736f7574682e6e6574" Freedom is an all-or-nothing proposition: either we are completely free, or we are subjects of a tyrannical system. If we lose one freedom in a thousand, we become completely subjugated. msg22686/pgp0.pgp Description: PGP signature
Re: Fastcgi on win [Was: Re: Documentation patch for mod_perl?]
> So mod_perl has a slight speed edge over fastcgi (which is overthrottled a > little with four servers). Really? Maybe this is because multi-process handling isn't as fast on NT. Does it change much if you vary the number of servers? My goal is to give some kind of useful suggestion to people who need better performance on NT than mod_perl can currently give. - Perrin
Re: Doing Authorization using mod_perl from a programmers perspective
On Mon, Nov 19, 2001 at 07:51:55AM -0800, Randal L. Schwartz wrote: > But this is obvious. I'm confused about why I'd have to explain it. :( I posted this a year or two back: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/jytwortwor/[EMAIL PROTECTED] Here is the relevant part of that post: It makes sense to start with the requirements for what it means to implement those secure features. My requirements have an obvious e-commerce bias, and should probably be heavily reviewed by anyone thinking of using this design for online banking or government work. First, I'd like to introduce the notion of a secure session. Secure sessions have some subtle differences from the traditional notion of the session, and I'll point those out when they appear. The secure session has the following properties: *) The user is able to initiate a secure session by providing proper credentials (i.e., a username and password pair) via a login process. *) The user is able to terminate the secure session via a logout process. *) Secure sessions must be able to time out automatically. *) Secure sessions must *never* transmit sensitive data (such as the password) over insecure channels. *) The secure session, while it requires the use of a secure protocol (such as HTTPS), should not require the use of cookies. Cookies, however, can be employed to extend the functionality of the system. Additionally, I feel that one of the essential requirements to any enterprise quality, highly scalable, and fault-tolerant system is the ability to store session state on a tier other than the front-end. This usually means storing state in a shared database, but there are other options. A very effective method of meeting the requirements above is to use a two token architecture. The first token is a user identifier, which can be passed over insecure channels. This user identification token can be used to restore state that isn't particularly sensitive, such as a shopping cart or user preferences. The second token is a secure identifier, which is never passed over insecure channels. The secure identifier is required to access sensitive data, such as credit card data. (It is possible to create an architecture that uses *only* the secure token, but there are significant benefits in terms of flexibility afforded by using two tokens, so I won't go into the one token model here.) The fundamental goal of the secure token is to a) keep it safe from prying eyes, and b) use it is a requirement for accessing secure data. Tokens can be passed in one of two ways. First, the token can be passed as part of the URL. Second, the token can be passed in a cookie. I've found it very useful to create an initialization procedure inside applications that check both places for these tokens, and abstract the particular mechanism used to pass them. Note, however, that is important to remember how the token was passed -- if it came from a cookie, it is cosmetic to not pass it around in the URL. I also recommend creating a library used in your templates that has a function to build URLs that automatically append the tokens if necessary. Since it is critical that secure tokens are never passed in the clear, it really helps to have that function, because it can prevent the secure token from being sent via an insecure page in a URL (i.e., only setting secure tokens in URLs that contain "https"). The user identification token is typically used to restore state from the database. It is created whenever a page is viewed and the client has either not provided one (via the URL or a cookie), or the token they provide doesn't exist in the database. This token should then be set in both the URL and in a cookie. On the subsequent page request, if the user identification token is found in a cookie, it is probably safe to stop putting it in the URL. However, if the token is found only in the URL (probably meaning the client does not use cookies) the server should not try writing the cookie again. The advantage of the cookie is such that the user can insecurely identify themselves across browser sessions. This is perfectly acceptable when used to restore some insensitive state data (such as a name or shopping cart). However, the system still functions without the cookie. The user can now login to associate their client with particular stored user information. The login process is as follows: 1) The client connects to a secure page that presents a form requesting a username and password. (There has been much discussion about whether a HTTP form that POSTS to a secure page will encrypt the posted data. There is too much ambiguity here -- I recommend using HTTPS on the login form as well.) The ACTION of the form must also be a secure page. 2) On receiving the username and password, the server compares an encrypted version of the password with the stored encrypted password associated with that customer. If the passwords do not matc
Re: Cookie authentication
On Fri, Nov 16, 2001 at 02:09:25AM +0100, Tom Bille wrote: > The aim of the cookie example in the eagle book is a bit more than just >authentication. Most of the answers here to use a > session ID here are quite right for most purposes, but the code in the eagle book >offers to store information on the client side > with the security of a signature. Its NOT just authentication. > This has some advantages for applications which are on more than one server, which >have to use an expensive central DB > lookup and/or are not connected at all, since the only thing to share is the secret. [snip] And for the academically inclined, Authen::Ticket (which I need to go back and update) is based on the Eagle book's example but different :/ It uses a PKI-like solution for ensuring authenticity of the cookies (at least someone can't just make up a cookie out of thin air). If you're using FreeBSD, I believe there's even a port for it (much to my surprise). --jim
Re: Doing Authorization using mod_perl from a programmersperspective
There seems to be some confusion over exactly what we're talking about... Apache::Session may work fine for creating a unique session ID, however this thread has really been about how to ensure that a session hasn't been hijacked. People have been suggesting various bits of info they could get from the client (IP, User Agent) and set in the cookie, thereby ensuring that the cookie is coming back from the client to whom they sent it. There isn't anything you can use that will work 100%. The only way you can ensure that your cookies aren't being hijacked is to only send them over an SSL connection. > From: Jon Robison <[EMAIL PROTECTED]> > Date: Mon, 19 Nov 2001 10:47:33 -0500 > To: "Randal L. Schwartz" <[EMAIL PROTECTED]> > Cc: fliptop <[EMAIL PROTECTED]>, "Jonathan E. Paton" > <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: Re: Doing Authorization using mod_perl from a programmers perspective > > How about using an Apache::Sessions id instead of IP address?
Re: Doing Authorization using mod_perl from a programmers perspective
> "Jon" == Jon Robison <[EMAIL PROTECTED]> writes: Jon> Randall, you want to expound upon that? Barely ignoring the spelling of my name, I'll simply claim "it's not unique". Neither is IP address. Or anything that you haven't specifically round-tripped to the browser. And that doesn't stop someone from making another browser respond in the same way, or that browser respond in a different way. But this is obvious. I'm confused about why I'd have to explain it. :( -- 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: Doing Authorization using mod_perl from a programmers perspective
How about using an Apache::Sessions id instead of IP address? --Jon Robison "Randal L. Schwartz" wrote: > > > "fliptop" == fliptop <[EMAIL PROTECTED]> writes: > > fliptop> i have found that using the HTTP_USER_AGENT environment > fliptop> variable instead of ip address solves the problem with proxy > fliptop> servers and the md5 hash. anyone ever tried this as a simple > fliptop> workaround? > > Nobody with any sense. It's flawed. > > -- > 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: Doing Authorization using mod_perl from a programmers perspective
Randall, you want to expound upon that? --Jon Robison "Randal L. Schwartz" wrote: > > > "fliptop" == fliptop <[EMAIL PROTECTED]> writes: > > fliptop> i have found that using the HTTP_USER_AGENT environment > fliptop> variable instead of ip address solves the problem with proxy > fliptop> servers and the md5 hash. anyone ever tried this as a simple > fliptop> workaround? > > Nobody with any sense. It's flawed. > > -- > 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: Doing Authorization using mod_perl from a programmers perspective
> "fliptop" == fliptop <[EMAIL PROTECTED]> writes: fliptop> i have found that using the HTTP_USER_AGENT environment fliptop> variable instead of ip address solves the problem with proxy fliptop> servers and the md5 hash. anyone ever tried this as a simple fliptop> workaround? Nobody with any sense. It's flawed. -- 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!
