Re: Content compression FAQ
Slava Bizyayev wrote: Oops, sorry for that. It should be OK now. http://devl4.outlook.net/devdoc/FAQ/compression.pod Thanks, committed __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: templating system opinions
Just wondering what the best templating system is to use and/or learn. Hi, I'm just wondering why no one recommended Embperl. Like Mason, it's more than a templating system, but I find it's inheritance features great. I'm using it for a personal project and haven't really checked it's performance, but there's no doubt it integrates well with mod_perl and allows you to use existing perl code, packages/objects on your site with ease. What do you guys think about it? Cameron
Re: templating system opinions
On Fri, 18 Jul 2003, Dave Rolsky wrote: On Fri, 18 Jul 2003, Patrick Galbraith wrote: TT was ok, but it did use a bunch of ram ;) So does Mason. HTML::Template is no doubt much leaner, but it's also lean on features. Nothing wrong with that if it suits your needs, though. Most Perl templating systems are probably slower and/or bulkier than PHP. The best counter for PHP folks is one word, CPAN ;) Also, Mason at least provides lots of features beyond templating, and is as much of an app framework as anything. This may be true of TT and the others, I'm not really sure. Just to chime in here, Mason is very much a framework. It expresses a particular view of web site development. I'm a huge fan of it, personally, but putting that aside, Mason is mainly about finding the proper balance between code monkey and html monkey. The slightly amusng thing, and what I take as a vote for Mason having found the balance, is that radically different styles of coding have evolved - I recently downloaded the code behind www.masonhq.com, and compared it to how we do things, and was shocked and appalled. And picked up some really good ideas... In general, Mason allows an HTMLer to become more of a programmer, and also requires programmers to be HTML savvy, or at least HTML sensitive. I find this a good thing. H::T is much more programmer-centric. In a lot of contexts, that makes sense. Informally (as in, I haven't done a systematic comparison), it is also faster than Mason. Mason isn't slow, but if you need every last gram of performance, well, you probably shouldn't be using a general framework anyway. And yes, they're all RAM-intensive. I don't actually care that much - RAM is cheap for general purpose servers. Just buzzing in with opinion - which is what I think the original poster was soliciting. HTH, my $.02, not a holy warrior, etc. -j -- Jamie Lawrence[EMAIL PROTECTED] The significant problems we face cannot be solved by the same level of thinking that created them. - Albert Einstein
Re: templating system opinions
On Sun, 20 Jul 2003, Jamie Lawrence wrote: H::T is much more programmer-centric. In a lot of contexts, that makes sense. Informally (as in, I haven't done a systematic comparison), it is also faster than Mason. Mason isn't slow, but if you need every last gram of performance, well, you probably shouldn't be using a general framework anyway. And yes, they're all RAM-intensive. I don't actually care that much - RAM is cheap for general purpose servers. Actually, H::T is almost certainly _much_ faster and less RAM-intensive than Mason, at least when you measure the time it takes to serve a single page/component. OTOH, if you were to try to replicate some of Mason's more powerful features with H::T, like autohandlers, inheritance, etc., then I'm sure that'd bring H::T's speed down to Mason's level ;) In other words, you generally get what you pay for. The most powerful and flexible systems are generally slower and more RAM-hungry. One exception to this might be Embperl, which has large chunks written in C. In that case, the cost is paid for in development time. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: templating system opinions
Barry Hoggard wrote: I used to use HTML::Template for projects, but I moved to Template::Toolkit because I felt the former's syntax was just too limited. I know we want to separate code and logic, but H::T keeps me [skip] JE Jesse Erlbaum JE Programmer: Get object, Get object attribute JE HTML Designer: Display attribute JE This is no more than a philosophical difference. HTML::Template assumes JE HTML designers should never do programming tasks, and implements this JE philosophy by not opening the code floodgate at all. TT believes that JE there is some amount of code you want your designer to do. [skip] Hello. Absolutely agree with Jesse. I've started with my own simple templating module, but step by step I've come to HT. Why HT? 1) It isn't framework, just templates. I'm trying to write my own framework. 2) Relatively fast. 3) Separate code and design. 4) Enough simple syntax to designers. When I was doing selection I just read comparison from perl.apache.org. Satisfied with the choice still. Best regards, Ruslan.
Re: templating system opinions
On Sun, 20 Jul 2003, Dave Rolsky wrote: Actually, H::T is almost certainly _much_ faster and less RAM-intensive than Mason, at least when you measure the time it takes to serve a single page/component. OTOH, if you were to try to replicate some of Mason's more powerful features with H::T, like autohandlers, inheritance, etc., then I'm sure that'd bring H::T's speed down to Mason's level ;) Fair enough. I haven't actually deployed anything under H::T. I've played with it, and some of it I like. I have stolen part of it for deployment, but it ended up really mangled and site specific, so that doesn't count. Mason isn't fast. It is, however, fast enough for high volume sites - that I will assert. From my view, the utility of autohandlers and dhandlers, in terms of code written vs. cost and time, is an enormous win. Add to that the flexibility between library developmers and HTML coders, in that there's a constant feedback loop that enforces reasonable development and interaction to ensure that all roles are working for the same goal. And in general, I don't care about RAM. A 1G server is cheap. Tune apache properly and you have no problems for sites approaching .25M visits/day. If you need to exceed that, you need multiple front-end boxes. But if you're doing that amount of traffic, you probably need redundancy anyway, so the issue is moot. In other words, you generally get what you pay for. The most powerful and flexible systems are generally slower and more RAM-hungry. One exception to this might be Embperl, which has large chunks written in C. In that case, the cost is paid for in development time. Agreed. In general, I love Mason, but still do write mod_perl interfaces for some things, when performance is important. For that matter, I push a lot of work onto the database, and then write C extensions to it to handle specific performance problems. Apache, perl, mason, postgres is a kickass combination, where you can fix almost any problem, quickly and cheaply. As usual, this pushes back at the developer, who is obligated to make the right choice. It is certainly not the only choice, but it is the right one(tm) for me. Again, I'm offering opinion, based on my particular experiences. Nothing more, nothing less. -j, who used to run custom NSAPI modules talking to Oracle under NES under high loads, and is an unabashed fan of mod_perl. shudder -- Jamie Lawrence[EMAIL PROTECTED] People should be allowed to keep midgets as pets. - Gov. Jesse Ventura
Re: templating system opinions
I've been working at Classmates.com for a couple months contracting, and they use Text::Forge. I've been impressed by the performance, and wish it was a big player. Part of the reason it isn't is guys like me should contribute to it and make it a bigger player. I really like the syntax - it looks a lot like JSP. They serve out around 12-13M pageviews a day using it. It just doesn't have a lot of active contributors to it now. Eventually, they will switch to java/atg dynamo. ... All of this said, what is the most commonly used system out there? Jesse Erlbaum wrote: Hi Chris, Patrick -- I post on this topic with some reluctance. Asking which templating system is best is like asking which operating system is best -- or which political party is best (or political system, I suppose). It's Jihad, baby! OTOH, I've never met a flamethrower I didn't like. What's best depends on what your requirements are. As far as I can tell, the big ones are Template::Toolkit, Mason, and HTML::Template One picky point: Mason is NOT a templating system. It is a programming system. If you're going to call Mason a templating system, you might as well refer to Perl as a templating system: my $name = Jesse; print Hello, my name is $name\n; Presto, blammo -- a new templating system! The big players are Template::Toolkit and HTML::Template. It's no secret that I'm a fan of HTML::Template -- Sam and I worked together when he wrote it, and my module, CGI::Application, uses it out of the box (although it does support TT). I use HTML::Template because designers can't be trusted to set variables. Boolean logic is about all their simple minds can handle. Anything which doesn't look like HTML is likely to cause them to have a stroke. Yes, I'm a programmer-snob and a fascist, and I like to take sharp objects away from the gentle creative types. Aside from the fact that HTML::Template uses less RAM and is faster than TT, this is the foremost reason I continue to use it. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226 -- -- Patrick Galbraith Senior Software Developer [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] 206.719.2461
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
It is supposed to be something like the following: C05 -- S06 GET /html/wowtmovie.html HTTP/1.1 C05 -- S06 Accept: */* C05 -- S06 Accept-Language: en-us C05 -- S06 Accept-Encoding: gzip, deflate C05 -- S06 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98) C05 -- S06 Host: devl4.outlook.net C05 -- S06 Pragma: no-cache C05 -- S06 Accept-Charset: ISO-8859-1 == Body was 0 bytes == C05 -- S06 HTTP/1.1 200 OK C05 -- S06 Date: Fri, 31 May 2002 17:36:57 GMT C05 -- S06 Server: Apache/1.3.22 (Unix) Debian GNU/Linux mod_perl/1.26 C05 -- S06 X-Module-Sender: Apache::Dynagzip C05 -- S06 Transfer-Encoding: chunked C05 -- S06 Expires: Friday, 31-May-2002 17:41:57 GMT C05 -- S06 Vary: Accept-Encoding C05 -- S06 Content-Type: text/html; charset=iso-8859-1 C05 -- S06 Content-Encoding: gzip C05 -- S06 == Incoming Body was 9411 bytes == == Transmission: text gzip chunked == == Chunk Log == a (hex) = 10 (dec) 1314 (hex) = 4884 (dec) 3ed (hex) = 1005 (dec) 354 (hex) = 852 (dec) 450 (hex) = 1104 (dec) 5e6 (hex) = 1510 (dec) 0 (hex) = 0 (dec) == Latency = 0.170 seconds, Extra Delay = 0.440 seconds == Restored Body was 149208 bytes == Not necessarily the same... To measure it you might want to use a proxy, or a sniffer. I can measure it myself if you can provide me with URLs to your resources and identify them in terms of which one is mod_CGI and which is mod_perl. Thanks, Slava - Original Message - From: Bill Marrs [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED]; Stas Bekman [EMAIL PROTECTED]; Philippe M. Chiasson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, July 20, 2003 6:22 PM Subject: Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified) At 11:07 AM 7/19/2003, Slava Bizyayev wrote: May I see your client side HTTP log of the request-response transaction through mod_cgi vs. mod_perl? I'm not sure what you mean. Do you mean my access_log? I have a deflate_log as well (that shows the compression stats as well). But, maybe you're talking about something else? If so, how do I get what you want?
ANNOUNCE: Apache::Dynagzip 0.10
This version is all about the unnecessary warnings on some systems. Thanks to Rob Bloodgood and Damyan Ivanov those complained about uninitialized value warnings from unused HTTP headers, and about the pack mode c, which generated warnings in logs on their systems (running -w). Everyone provided own patch. I just did my best to satisfy both patches in one version. It is not necessary to upgrade immediately (from the version 0.09) unless you suffer from the mentioned warnings. The uploaded file Apache-Dynagzip-0.10.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SL/SLAVA/Apache-Dynagzip-0.10.tar.gz size: 30927 bytes md5: be50955ac5130134b68c9af8cd0bae04 Thanks, Slava
ANNOUNCE: Apache::CompressClientFixup 0.07
This version is all about the unnecessary warnings on some systems. Thanks to Rob Bloodgood, who complained about uninitialized value warnings from unused HTTP headers and provided a patch. It is not necessary to upgrade immediately (from the version 0.06) unless you suffer from the mentioned warnings. The uploaded file Apache-CompressClientFixup-0.07.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SL/SLAVA/Apache-CompressClientFixup-0.07.tar.gz size: 5729 bytes md5: b38dcf93078579fc1ad91282e60dd0ff Thanks, Slava
Re: templating system opinions
On Sun, 20 Jul 2003, Patrick Galbraith wrote: I've been working at Classmates.com for a couple months contracting, and they use Text::Forge. I've been impressed by the performance, and wish it was a big player. Part of the reason it isn't is guys like me should contribute to it and make it a bigger player. I'd say the big reason it's not a big player is that it doesn't offer anything new. It also doesn't seem to be very actively developed and has very little documentation. I really like the syntax - it looks a lot like JSP. Yeah, just like Apache::ASP ;) All of this said, what is the most commonly used system out there? The biggest players are Mason and Template Toolkit, judging from big companies that have used them, as well as job posting. HTML::Template, Embperl, and Apache::ASP all seem to have reasonably active user bases as well. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: Apache::Dynagzip 0.10
Why does Apache/Dynagzip.pm call $r-content_type('text/html') in
several places? My apache module earlier in the Apache::Filter chain
sets $r-content_type to something else, but it then gets overridden by
Dynagzip.pm. If I comment out all the calls to
$r-content_type('text/html') in Dynagzip.pm. I get the correct content
type. I'd like it if I could get this behavior without modifying
Dynagzip.pm...
-John
Re: ANNOUNCE: Apache::Dynagzip 0.10
Your own content-type is supposed to be overwritten only in case of the use
of
PerlSetVar UseCGIHeadersFromScript Off
in your configuration file. You might wish to comment this line in your
configuration file when your script generates correct header line in
accordance with CGI/1.0 and/or CGI/1.1.
Thanks,
Slava
- Original Message -
From: John Siracusa [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: Slava Bizyayev [EMAIL PROTECTED]
Sent: Sunday, July 20, 2003 10:05 PM
Subject: Re: ANNOUNCE: Apache::Dynagzip 0.10
Why does Apache/Dynagzip.pm call $r-content_type('text/html') in
several places? My apache module earlier in the Apache::Filter chain
sets $r-content_type to something else, but it then gets overridden by
Dynagzip.pm. If I comment out all the calls to
$r-content_type('text/html') in Dynagzip.pm. I get the correct content
type. I'd like it if I could get this behavior without modifying
Dynagzip.pm...
-John
Re: templating system opinions
On Sun, 20 Jul 2003, Jamie Lawrence wrote: Mason isn't fast. It is, however, fast enough for high volume sites - that I will assert. Sure, amazon.com among them. From my view, the utility of autohandlers and dhandlers, in terms of code written vs. cost and time, is an enormous win. Add to that the flexibility between library developmers and HTML coders, in that there's a constant feedback loop that enforces reasonable development and interaction to ensure that all roles are working for the same goal. I'm not gonna disagree with you. I consider Mason's features well worth the speed/memory costs. That's why I use it and develop it ;) -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: does pnotes() work at all in 1.27? [RESOLVED]
An upgrade to 1.28 fixed this. Never found out what caused it under
1.27.
On Sat, 2003-07-19 at 13:20, Mark Maunder wrote:
Hi. This is a rather comprehensive (read 'cathartic') message, so if you
have something productive to go and do, then you'd probably be better
off doing that. For all other interested parties, read on
I've done a few more tests and isolated this to my production server
only. pnotes() works fine on my workstation. And the problems described
below apply to notes() too. So it's something to do with my
apache/mod_perl installation. Take a look at this:
I've cut down the production server to a bare bones httpd.conf with the
following virtual hosts section:
VirtualHost *
DocumentRoot /home/mark/lib
ServerName localhost
Location /
PerlFixupHandler Handler1
PerlHandler Handler2
PerlLogHandler Handler3
/Location
/Virtualhost
my startup.pl looks like this:
#!/usr/bin/perl
require '/home/mark/lib/Test.pl';
1;
And Test.pl looks like this:
package Handler1;
sub handler {
my $r = shift @_;
$r-pnotes('note1', 'msg1');
warn HANDLER1 says: . $r-pnotes('note1');
return OK;
}
package Handler2;
sub handler {
my $r = shift @_;
$r-pnotes('note2', 'msg2');
warn HANDLER2 says: . $r-pnotes('note2');
warn HANDLER2 got: . $r-pnotes('note1');
$r-send_http_header('text/html');
$r-print(Hello World!\n);
return OK;
}
package Handler3;
sub handler {
my $r = shift @_;
warn HANDLER3 got: . $r-pnotes('note1') .
' and ' . $r-pnotes('note2');
return OK;
}
1;
This gives an output in error_log of the following:
HANDLER1 says: msg1 at /home/mark/lib/Test.pl line 5.
HANDLER1 says: msg1 at /home/mark/lib/Test.pl line 5.
HANDLER1 says: msg1 at /home/mark/lib/Test.pl line 5.
HANDLER2 says: msg2 at /home/mark/lib/Test.pl line 12.
HANDLER2 got: msg1 at /home/mark/lib/Test.pl line 13.
HANDLER3 got: msg1 and at /home/mark/lib/Test.pl line 21.
Which shows that pnotes can pass data from the Fixup handler to the
Response handler, but anything the Response handler sets is lost by the
time the Logging handler is called. Although the data that the Fixup
handler sets is still there.
Question: Why is the Fixup handler being called 3 times? If you look at
the sniffer output I've included, you'll see there's a single request
and response. I checked the URI that was being called and it's '/' in
all three cases.
Just to be sure, I added this to Handler2 (the Response handler)
if($r-is_main())
{
$r-print('You are in main');
}
And it prints out the string. So it is the main request.
Here is some more info:
When I did this test, I stripped out everything from httpd.conf (relying
heavily on vim's undo feature because this server will be live in 48
hours, pnotes or no pnotes!).
Here is the output from httpd -l
Compiled-in modules:
http_core.c
mod_env.c
mod_log_config.c
mod_mime.c
mod_negotiation.c
mod_status.c
mod_include.c
mod_autoindex.c
mod_dir.c
mod_cgi.c
mod_asis.c
mod_imap.c
mod_actions.c
mod_userdir.c
mod_alias.c
mod_rewrite.c
mod_access.c
mod_auth.c
mod_proxy.c
mod_headers.c
mod_setenvif.c
mod_gzip.c
mod_perl.c
suexec: disabled; invalid wrapper /usr/local/apache/bin/suexec
Here is the output from httpd -V:
Server version: ZipTree (Unix)
Server built: Jul 8 2003 12:56:03
Server's Module Magic Number: 19990320:13
Server compiled with
-D HAVE_MMAP
-D HAVE_SHMGET
-D USE_SHMGET_SCOREBOARD
-D USE_MMAP_FILES
-D HAVE_FCNTL_SERIALIZED_ACCEPT
-D HAVE_SYSVSEM_SERIALIZED_ACCEPT
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D HARD_SERVER_LIMIT=256
-D HTTPD_ROOT=/usr/local/apache
-D SUEXEC_BIN=/usr/local/apache/bin/suexec
-D DEFAULT_PIDLOG=logs/httpd.pid
-D DEFAULT_SCOREBOARD=logs/apache_runtime_status
-D DEFAULT_LOCKFILE=logs/accept.lock
-D DEFAULT_ERRORLOG=logs/error_log
-D TYPES_CONFIG_FILE=conf/mime.types
-D SERVER_CONFIG_FILE=conf/httpd.conf
-D ACCESS_CONFIG_FILE=conf/access.conf
-D RESOURCE_CONFIG_FILE=conf/srm.conf
Got a sniffer on the wire too and the output looks like this. The
request is:
GET / HTTP/1.1
Host: testserver
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1)
Gecko/20021003
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0
And the response is:
HTTP/1.1 200 OK
Date: Sat, 19 Jul 2003 20:17:05 GMT
Server: ZipTree
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding:
