Re: How do you use mod_perl for your web application?
We use mp2 + httpd in prefork mode to translate between JSON/SOAP to proprietary CORBA (via opalORB - the 100% painless CORBA interface) on dedicated servers . We've run 100's of requests a second through a single server. So long as httpd is configured sensibly the performance is excellent. A word too on stability. One installation has been chugging away for about 4 years now without a single defect report. I also use it for internal testing - using virtual hosts to serve a proprietary in-house socket protocol, which is then reconstituted inside perl. The advantage of this is that I can use Apache::Test to drive the tests. So far the need for frameworks of any sort has not arisen. The ones I have played with, Mason,Catalyst,Gantry, Dancer are all very capable. Probably it is due to the limited use I've put them to but I tend to find that Text::Perlate (or even just some quick and dirty regex-based text mutations), and maybe a bit of javascript gets me there quicker than the frameworks. That said - I have an uncomfortable suspicion that sophisticated technology leads to sophisticated solutions, whether the problems at hand deserve such sophistication or not. Just to reinforce Randolf's enthusiasm - mod_perl is fantastic. Combined with httpd's remarkable flexibility and stability I can't see why we don't brainwash our children into using it as soon as they can hit a keyboard.
Re: highscalability.com report
On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins wrote: > ... If they were to > rewrite it in Perl today, *it would go up again*! > > - Perrin > No performance anxiety there then.
Bug report - mod_perl2 make test fails on Cygwin DLL version: 1.5.24
Guys, Probably not a bug as such but something in my set up. Find the output from REPORT below. Basically everything seems to build ok but make test fails with the claim that the server didn't start. When I look at the ps output I can see that httpd2 has started. Any help appreciated. Thanks, Rolf -8<-- Start Bug Report 8<-- 1. Problem Description: make test fails: /usr/bin/perl.exe -Iblib/arch -Iblib/lib \ t/TEST -clean APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \ /usr/bin/perl.exe -Iblib/arch -Iblib/lib \ t/TEST -bugreport -verbose=0 /usr/sbin/httpd2 -d /build/mod_perl-2.0.3/t -f /build/mod_perl-2.0.3/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.2.4 (prefork MPM) waiting 120 seconds for server to start: .[Sat Oct 27 11:19:06 2007] [warn] Useless use of AllowOverride in line 879. [Sat Oct 27 11:19:06 2007] [info] 6 Apache2:: modules loaded [Sat Oct 27 11:19:06 2007] [info] 0 APR:: modules loaded [Sat Oct 27 11:19:06 2007] [info] base server + 29 vhosts ready to run tests [Sat Oct 27 11:19:10 2007] [warn] The Alias directive in mod_perl at line 1 will probably never match because it overlaps an earlierAlias. [Sat Oct 27 11:19:10 2007] [warn] The Alias directive in mod_perl at line 1 will probably never match because it overlaps an earlier Ali as. [Sat Oct 27 11:19:10 2007] [warn] The Alias directive in mod_perl at line 1 will probably never match because it overlaps an earlier Ali as. [Sat Oct 27 11:19:10 2007] [warn] The Alias directive in mod_perl at line 1 will probably never match because it overlaps an earlier Ali as. [Sat Oct 27 11:19:10 2007] [warn] The Alias directive in mod_perl at line 1 will probably never match because it overlaps an earlier Ali as. .. waiting 120 seconds for server to start: not ok [ error] giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. by setting the environment variable APACHE_TEST_STARTUP_TIMEOUT to a high value (e.g. 420) and repeat the last command. [ error] server failed to start! (please examine t/logs/error_log) ++ | Please file a bug report: http://perl.apache.org/bugs/ | ++ make: *** [run_tests] Error 1 cat t/logs/error_log [Sat Oct 27 11:19:10 2007] [info] mod_unique_id: using ip addr 192.168.0.100 [Sat Oct 27 11:19:11 2007] [info] Init: Seeding PRNG with 0 bytes of entropy [Sat Oct 27 11:19:11 2007] [info] Init: Generating temporary RSA private keys (512/1024 bits) [Sat Oct 27 11:19:11 2007] [info] Init: Generating temporary DH parameters (512/1024 bits) [Sat Oct 27 11:19:11 2007] [warn] Init: Session Cache is not configured [hint: SSLSessionCache] [Sat Oct 27 11:19:11 2007] [info] Init: Initializing (virtual) servers for SSL [Sat Oct 27 11:19:11 2007] [info] Server: Apache/2.2.4, Interface: mod_ssl/2.2.4, Library: OpenSSL/0.9.8e END in modperl_extra.pl, pid=8336 When I look at the process table: ps -ef | grep http bantiro4848 1 ? 11:19:11 /usr/sbin/httpd2 So apache has started. I have no previous version of mod perl installed. 2. Used Components and their Configuration: *** mod_perl version 2.03 *** using /build/mod_perl-2.0.3/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_APXS=> /usr/sbin/apxs2 MP_COMPAT_1X => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 *** /usr/sbin/httpd2 -V Server version: Apache/2.2.4 (Unix) Server built: Apr 6 2007 23:09:29 Server's Module Magic Number: 20051115:4 Server loaded: APR 1.2.8, APR-Util 1.2.8 Compiled using: APR 1.2.8, APR-Util 1.2.8 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_MMAP -D APR_USE_SYSVSEM_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/usr" -D SUEXEC_BIN="/usr/bin/suexec" -D DEFAULT_PIDLOG="/var/run/httpd2.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="/var/run/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types" -D SERVER_CONFIG_FILE="/etc/apache2/httpd.conf" *** (apr|apu)-config linking info -L/usr/lib -laprutil-1 -lgdbm -ldb-4.2 -lexpat -liconv -L/usr/lib -L/usr/lib -lapr-1 -lcrypt *** /usr/bin/perl5.8.8 -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=cygwin, osvers=1.5.24(0.15642), archname=
UDP support in mod_perl2/apache
Hi, I'd like to able to transplant a kind of gateway app I have written from a POE to mod_perl2. Why? Well mainly so I have an excuse to get into mod_perl2 & apache. What the app does is accept client requests in a proprietrary protocol carried over UDP and translate them either into synchronous CORBA calls or asynchronous requests over the proprietrary protocol to an external server. In turn server repsonses are then translated and sent back to the original client. I have scanned the mail archives and found references to some UDP based work that different people were doing but I can't see if anything got released. Did the mod_udp development get into release mode or are there other ways to get mod_perl to listen to UDP ? Thanks in advance, Rolf
Re: dev environment
On 11/5/07, Jeff Armstrong <[EMAIL PROTECTED]> wrote: > Or even make yourself a virtual PC using MS Virtual PC and install a > Linux / Apache / Modperl / Samba / MySQL / SVN etc into it (e.g. Debian > is easy, or whatever you need for your prod). Or: 1. use cygwin ( if you can get mod_perl2 to build. I couldn't.) 2. Pay up for VMWare Workstation. With VMWare you can have virtual linux sessions running in Windows. There's a free player and some free Linux virtual machines but if you want to create your own virtual system you will need Workstation (about 200 euro). With recent versions of the linux kernel you can create virtual OS's that share folders with Windows (or the other way round if you have Linux as your native OS). Even without shared folder support you can access the virtual system from the host system via SSH etc. I've got mod_perl2 to fly on debian (woody) and RHEL3 virtual machines. With a reasonable spec box you will hardly notice you are running a hosted OS. VMWare is highly recommended. Check out these web sites: http://en.wikipedia.org/wiki/VMware http://www.vmware.com Rolf
Re: dev environment
On 11/5/07, Octavian Rasnita <[EMAIL PROTECTED]> wrote: > I wasn't able to use it because I didn't know how to set its share > directories and especially its network interface to be able to access the > internet from the virtual machine (if it is possible). 1. You can access the internet from the virtual machine. It has its own IP address so as far as the network is concerned it looks like a different physical node. 2. Shared folders require installation of the vmware tools for the guest operating system. Once installed the shares can be created via a wizard accessible from the properties dialogue for the virtual machine. When a share is created it shows up under /mnt/hgfs in Linux virtual machines. Rolf
make test failure for mp 2.0.3 against httpd2 trunk: access2.t fails
Hi,
I have a few problems with mp 2.0.3 against the http2 trunk.
1)
/home/mrstlee/Projects/mod_perl-2.0.3/xs/Apache2/RequestUtil/Apache2__RequestUtil.h:157:
structure has no member named `ap_auth_type'
/home/mrstlee/Projects/mod_perl-2.0.3/xs/Apache2/RequestUtil/Apache2__RequestUtil.h:158:
structure has no member named `ap_auth_type'
/home/mrstlee/Projects/mod_perl-2.0.3/xs/Apache2/RequestUtil/Apache2__RequestUtil.h:160:
structure has no member named `ap_auth_name'
/home/mrstlee/Projects/mod_perl-2.0.3/xs/Apache2/RequestUtil/Apache2__RequestUtil.h:161:
structure has no member named `ap_auth_name'
So I change that:
--- xs/Apache2/RequestUtil/Apache2__RequestUtil.h Fri Nov 9 12:31:27 2007
+++
/home/mrstlee/Projects/mod_perl-2.0.3/xs/Apache2/RequestUtil/Apache2__RequestUtil.h
Sun Nov 19 23:31:03 2006
@@ -149,20 +149,16 @@
int i;
for (i=0; id, location)) {
-if (!auth_type) {
-auth_type = "Basic";
+if (!entry->ap_auth_type) {
+entry->ap_auth_type = "Basic";
}
-if (!auth_name) {
-auth_name = apr_pstrdup(p, location);
+if (!entry->ap_auth_name) {
+entry->ap_auth_name = apr_pstrdup(p, location);
}
r->per_dir_config =
ap_merge_per_dir_configs(p, s->lookup_defaults, sec[i]);
2) It builds OK. But then with make test:
/opt/apache2-udp/bin/aps-udp: relocation error:
/home/mrstlee/Projects/mod_perl-2.0.3/blib/arch/auto/Apache2/ServerUtil/ServerUtil.so:
undefined symbol: ap_get_server_version
I see in the httpd comments that ap_get_server_version has been
replaced with get_server_description or get_server_banner.
3) So I change get_server_version to get_server_description. This
seems to go OK - make test now builds and runs. But access2 fails.
When I look at the error log:
no authorization providers configured
Presumably this is due to the way the auth stuff has changed in
Apache2__RequestUtil.h?
Does anyone know what I need to do here?
Thanks,
Rolf
Re: mp 2.0.3 make test fails against httpd trunk: Has authorisation changed since httpd 2.2 ?
I can answer my own question, at least in part. In the t/httpd.conf location /TestAPI__access has AuthType none and AuthName modperl defined. If I comment those out t/api/access.t passes except for test 7. Test 7 expects 'none' as AuthType whereas in fact it is 'undef' now. I've looked through the server 1.3,2.0, 2.2 & dev documentation. They all say that there are 2 possible values for AuthType - Basic or Digest. From my apache/mp novice perspective it looks as though access.t really should also fail for mp vs 2.2.6 since 'none' does not appear to a legal AuthType. Anyway - should access.t & t/conf/httpd.conf in the mod_perl trunk be changed? I am quite happy to do this. Thanks, Rolf
Re: mp 2.0.3 make test fails against httpd trunk: Has authorisation changed since httpd 2.2 ?
Thanks for the replies. I'll carry on and see if I can get to the bottom of the other make test failures. At that point I'll seek advice on whether or not the mp archive needs an update. I've moved on to access2.t now. The difference with access.t is that user id authentication is required. No matter what I try my response always starts off: 401 Authorization Required Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn\'t understand how to supply the credentials required. This is the relevant httpd.conf section: PerlAuthenHandler TestAPI::access2 PerlResponseHandler Apache::TestHandler::ok1 SetHandler modperl # needed to test $r->satisfies Allow from All AuthType Basic AuthName "Access" Require user goo bar Require group bar tar Require valid-user Satisfy All # htpasswd -mbc auth-users goo foo # htpasswd -mb auth-users bar mar # using md5 password so it'll work on win32 too AuthUserFile /home/mrstlee/.cpan/build/mod_perl-2.0.3-YQdTDD/t/htdocs/api/auth-users # group: user1 user2 ... AuthGroupFile /home/mrstlee/.cpan/build/mod_perl-2.0.3-YQdTDD/t/htdocs/api/auth-groups This is as created by the make test process. As far as I can gather from the dev (2.3) documentation it looks ok. I've tried recreating the auth files to make sure the passwords passed in the access2.t script are correct & adding an 'AuthBasicProvider file' line. No change. Again - this works when built against 2.2.6. Any ideas greatly appreciated. Rolf .
Re: mp 2.0.3 make test fails against httpd trunk: Has authorisation changed since httpd 2.2 ?
I've noticed some comments in the source (using the wonderful 'ack') about a change from requires to providers. Haven't looked any deeper so far.
mod_perl 2.0.3 + httpd trunk + access2.t fails: How to get 'Require' data with the httpd trunk implementation?
All,
The access2.t test fails when mod_perl 2.0.3 is built against the httpd
trunk. The core problem is that the test script needs the httpd ap_requires
function; however the log shows that the ap_requires function has been
removed from httpd:
relocation error:
/home/mmsadm/Projects/mod_perl-2.0.3/blib/arch/auto/Apache2/Access/Access.so:
undefined symbol: ap_requires
The relevant code in t/repsonse/TestAPI/access2.pm is:
# extract just the requirement entries
my %require =
map { my ($k, $v) = split /\s+/, $_->{requirement}, 2; ($k, $v||'') }
@{ $r->requires };
debug \%require;
return Apache2::Const::SERVER_ERROR unless $require{user} eq $users;
return Apache2::Const::SERVER_ERROR unless $require{group} eq $groups;
Since requires effectively wraps ap_requires the %require hash is not
populated & SERVER::ERROR is returned from the handler.
The config section is:
PerlAuthenHandler TestAPI::access2
PerlResponseHandler Apache::TestHandler::ok1
SetHandler modperl
# needed to test $r->satisfies
Allow from All
AuthType Basic
AuthName "Access"
Require user goo bar
Require group bar tar
Require valid-user
Satisfy All
# htpasswd -mbc auth-users goo foo
# htpasswd -mb auth-users bar mar
# using md5 password so it'll work on win32 too
AuthUserFile /home/mmsadm/Projects/mod_perl-2.0.3/t/htdocs/api/auth-users
# group: user1 user2 ...
AuthGroupFile /home/mmsadm/Projects/mod_perl-2.0.3/t/htdocs/api/auth-groups
To make the access2 test pass it seems that the obvious thing to do is
populate the %require hash without the '$r->requires'
call. Does anyone know how the information associated with 'Require'
directives can be retrieved
in the latest httpd implementation?
Thanks,
Rolf
Further info:
1. This mail discussion between Steve Hay & Randy Kobes
mentions the removal of ap_requires from httpd:
"Problems building mod_perl-2.0.3 on Win32 with VC8"
2. t/hooks/authz.t & t/hooks/authen_basic.t fail for the same reason
Re: decline and fall of modperl?
Foo JH wrote: > In the academia the general directive in choosing a language would be > something to this effect: > 1. teach modern language concepts, such as OO > 2. minimise the learning curve by way of something easy to teach, easy > to learn without having to figure out all the details of programming > 3. introduce the students to a language that will make them attractive > to the general market > > You probably have a feel why Perl isn't a strong choice given these > objectives. On points 1 & 2: 1. Perl supports more programming paradigms than Java. 2. You write fewer lines of perl to get things done than you do in Java. There is empirical evidence of this - anyone seen the Software Productivity Group research on programming languages? In general: C - 6 x more productive than assembler Java/C++ - 3 x more productive than C Perl/Python (Ruby/javascript not represented) - 2-3 x more productive than Java/C++ Results are consistent over 2 studies a decade or so apart. Point 3 does scream "Java" but take a look at this: http://lambda-the-ultimate.org/node/2941 The author laments the ubiquity of Java as the language of choice in education (despite having advocated it himself). On balance he'd go for python but doesn't dismiss Perl out of hand either. I can't convince my own colleagues of the benefits of perl despite the fact I continually produce decent quality s/w faster than they can, when given the opportunity. Folk will see what they expect to see. This was demonstrated by a psychology experiment in the 90's. Subjects were asked to look at a video of 2 football teams passing a football around and count how many times the ball was passed. When asked at the end of the video the answers were pretty accurate. Then they were asked "What about the gorilla?". In the middle of the video someone in a gorilla suit walks on, bangs on its chest and walks off. Hardly anyone spots the gorilla.
Re: To learn perl... [was: decline and fall of modperl?]
On Thu, Mar 26, 2009 at 11:35 AM, Simon Forster wrote:
>
> On 25 Mar 2009, at 18:23, David Ihnen wrote:
>
> They've also told me that they know that perl is harder to learn than PHP.
>>> What can I tell them? That it is not true?
>>>
>> Yes, but you may or may not be right. We all agree that coming into perl
>> is confusing - too much old data about how to do things is out there in the
>> world. That makes it harder to learn - not because the language is harder
>> to learn - but because its not clear what the proper way to learn it is.
>>
>
> And what is the proper way? I've futzed about in a number or languages -
> including perl - but only at a very basic level with perl. I've got some web
> stuff to do and thought that having a go with perl may be a pleasant
> diversion. At the moment it looks like I'll be using Catalyst and Mason to
> help with the job - but what are the pratfalls to avoid - or the good
> practice to follow (use strict and warnings :-)
>
> As an outsider, perl is its own worst enemy. Its proud boast is that
> there's more than one way of doing things (so show me a language where
> that's not true) while not really showing a good way. I accept that a chunk
> of this is style / taste / choice but a few pointers along the lines of
> "that way the road is quite straight and smooth" would help quite a lot.
>
> I guess I'm asking for a magic formula which doesn't exist and that I
> should just bloody well get on and do it but I'll ask anyway.
>
> TIA
>
> Simon
>
"The Perl Cookbook" will likely as not point you at the smoother parts of
the road.
"Perl Best Practices" by Damian Conway goes into the "right" way to do
perl-ish things in great depth.
PerlCritic is a perl module inspired by the book that will check your code
against a configured policy set.
A great place to start is the Camel book ("Programming Perl" - Wall et al)
which has sections on style, newbie pitfalls etc
Try "Perl Hacks" for a more sideways glance.
It is a rich, flexible, language that has been around a good while. In a
good few years at this game I have not come across another that gets you
from here to there in so few steps.
Re: To learn perl... [was: decline and fall of modperl?]
On Thu, Mar 26, 2009 at 1:04 PM, Simon Forster wrote:
>
> On 26 Mar 2009, at 11:50, Mark Blackman wrote:
>
> The older answer is something along the lines of "Perl Best Practice" the
>> O'Reilly
>> book by D. Conway and ideas behind it. See also
>> http://www.perl.com/pub/a/2005/07/14/bestpractices.html.
>>
>> The newer answer is an emerging buzzword called "Modern Perl" or sometimes
>> "Enlightened Perl".
>> Chromatic's blog on the subject, http://www.modernperlbooks.com/mt/, is
>> probably the best
>> starting place for that idea.
>>
>
>
> On 26 Mar 2009, at 11:51, Rolf Banting wrote:
>
> "The Perl Cookbook" will likely as not point you at the smoother parts of
>> the road.
>> "Perl Best Practices" by Damian Conway goes into the "right" way to do
>> perl-ish things in great depth.
>> PerlCritic is a perl module inspired by the book that will check your code
>> against a configured policy set.
>> A great place to start is the Camel book ("Programming Perl" - Wall et al)
>> which has sections on style, newbie pitfalls etc
>>
>> Try "Perl Hacks" for a more sideways glance.
>>
>> It is a rich, flexible, language that has been around a good while. In a
>> good few years at this game I have not come across another that gets you
>> from here to there in so few steps.
>>
>
> Sheesh. Thanks guys but I don't have enough time to digest all that.
>
> ;-)
>
> Probably I should just buy the Camel book - but it's a bit long in the
> tooth now (perl 5.6, published 2000).
>
> I imagine I'll just throw myself into it at some time and bore the list
> with asinine questions.
>
> Simon
>
Fair enough Simon. I would recommend you look at the Cookbook too - it has
recipes for everything from iterating through a hash to web automation.
http://docstore.mik.ua/orelly/perl/cookbook/
Slan abhaile,
Rolf
Re: decline and fall of modperl?
On Thu, Mar 26, 2009 at 3:44 PM, Octavian Râsnita wrote: > *From:* Rolf Banting > > Foo JH wrote: > > In the academia the general directive in choosing a language would be > > something to this effect: > > 1. teach modern language concepts, such as OO > > 2. minimise the learning curve by way of something easy to teach, easy > > to learn without having to figure out all the details of programming > > 3. introduce the students to a language that will make them attractive > > to the general market > > > > You probably have a feel why Perl isn't a strong choice given these > > objectives. > > > On points 1 & 2: > > 1. Perl supports more programming paradigms than Java. > > 2. You write fewer lines of perl to get things done than you do in Java. > 1. I don't know what it means that perl supports more paradigms than Java, > but I know that the Java / C# OOP style is usually considered a much > complete and better standard than one used by Perl. > > Functions are first class citizens in Perl - so you get functional programming built in. You don't in Java. How are standards of OO quantified and compared? > Java / DotNet support interfaces, so the classes they create respect the > "contracts" better, while in perl world, the programmer is free, and nobody > points a shotgun to him in order to force him to do it. > > Java and C# uses a dot notation for separating the classes when using the > OOP style, and even Template-Toolkit uses it, but perl uses something else. > > > C++ uses '::' > 2. It is right that perl is probably one of the most productive languages, > because it requires to write very little code, for doing very many things. > But for doing the same thing, Ruby and Python can use sometimes even less > code, because they don't use so much punctuation and funny char > > And anyway, for the beginners, this is not a big problem. The biggest > problem is that perl is harder to learn. The programmers might want to learn > a language for a year, and get a job, and after this they hope that they > will find time to learn the chosen language better while they have a job. > > Harder to learn than what? Is there any evidence for this? > > We could say that perl would be really great for these days if we could say > about it something like: > - It is the most easy to learn language even by the most stupid > programmers. > > It is easy to learn! > - It can create portable programs that can run everywhere, under Windows, > Mac, Linux, shared hosting web sites that don't offer root and shell access. > > - The source code of the programs can be hidden. > > - There are very many recent books that teach Perl. > > Why is "recent" important? The language features haven't changed much so why would the learning resources? > - Perl is chosen by bigger companies like IBM, Oracle, Microsoft, Sun, > Yahoo, Google, SAP. > - The popular sites like Twitter, Digg, Facebook, MySpace, Wikipedia, are > powered by perl. > - There are important other software made in Perl which are used much these > days, like a mailing list manager, a web server, financial charting > software, stock exchange trading applications, etc. > > I know of perl CORBA applications that have been responsible for charging literally millions of real-time short messages in telecomms networks in Latin America. > > ...and other things like these. But unfortunately in the last years I've > seen only reports about the decreasing number of sites that use Perl. > > Octavian > > > Use of perl is declining - but not due to lack of technical merit. Fashions change.
Re: To learn perl... [was: decline and fall of modperl?]
On Thu, Mar 26, 2009 at 6:29 PM, Joel Bernstein wrote: > > On 26 Mar 2009, at 13:21, Rolf Banting wrote: > >> Fair enough Simon. I would recommend you look at the Cookbook too - it has >> recipes for everything from iterating through a hash to web automation. >> >> http:/SNIP/perl/cookbook/ >> > > Why would you do that? I'm sure you realise that a Ukrainian mirror of the > first edition is unlikely to be officially sanctioned. Didn't occur to me. Too busy to think to check. I apologise *unreservedly*if there is anything untoward about the link. > You like the book so much that you want to screw its authors by linking to > a pirated copy stolen from the Perl CD Bookshelf? I'm sure your mother taught you better. > http://oreilly.com/catalog/9780596003135/index.html > Is the correct link, and it's for the Second Edition rather than the First. > Which is newer and much better. > > Please don't encourage people to steal anybody's work, let alone the work > of such excellent community members (who have given so much to Perl) as gnat > and tchrist! > > I'm quite happy to accept that you might have made an honest mistake in > selecting that URL as an example, but I think it's important to note that > it's not a reasonable example and IMO one that cannot be accepted here. > > /joel >
Re: decline and fall of modperl?
On Sat, Mar 28, 2009 at 6:44 AM, Octavian Râsnita wrote: > From: "Joe Schaefer" > >> A contribution to a *community* would be to offer gratis advice on a >> mailing list, ostensibly to help the community reach its objectives. >> Nothing I see in this thread looks like a contribution to the mod_perl >> community, sorry. >> > > The mod_perl community is also made of those who want to use mod_perl, and > if somebody put questions regarding mod_perl, we should try to help him, no > matter if he is interested about technical faces of mod_perl, or if he is > interested to know how obsolete or modern it is, or if he is interested to > know how many mod_perl programmers are available. > > "Die" is just an expression that wants to tell that the language is not >> used by >> more and more programmers, but by fewer. >> > > Usage statistics are irrelevent to the vitality of a language. What's >> relevant >> to the perl community is something like how many module maintainers have >> abandoned >> their codebases. Do you have any information about how many modules are >> on >> CPAN that are no longer supported? And to bring it back to mod_perl, how >> many >> of those are Apache modules? >> > > Nope, but I know that WxPython is much better developed than WxPerl, that > Python can be used under Symbian, that Python can work better together with > Java virtual machine, that Python is better than Perl for some tasks, and I > gave an example of 2 screen readers made in python, one for Linux and one > for Windows. > > I also know that even the Perl programmers prefer more and more fastcgi, > because it has some advantages. > I have never used fastcgi or fcgid, but only mod_perl, but this doesn't > mean that we should present only the good parts of mod_perl and perl. > > Usage statistics are very relevant. In the christian part of the world, in > churches the old greek and latin are considered great languages, with a big > history, and some consider them more important languages for the world's > civilisation than English or Spanish, but this is because for what those > persons is important, those languages could be important, however for the > rest of the world those languages are considered only dead languages, even > if they have a longer history than English or Spanish. > > If perl will become better and better but for less and less users, it would > become an alive language like latin. > > If we want to be more on-topic, it would be interesting to compare mod_perl > with mod_php and mod_python and find if the other Apache modules have > advantages, or why they are more and more used. > And the number of current users is not so important as the rate of increase > or decrease in the number of users and sites that use them. > > If there are say 1 million sites that use mod_perl but only 100 thousand > that use mod_python, however the number of web sites that use mod_perl > increases with 1% each year (or even decreases), and the number of sites > that use mod_python increases with 10% each year, then the future doesn't > sound very well for mod_perl. > > If this presumption is true or not, it would be helpful for us to know in > any case. > > Octavian > I do see Joe's point. The question I would ask though is "what harm has this mail trail done?". It has generated a large amount of interest, even if the opinion to backed-by-objective-evidence ratio has been a little high at times. If someone isn't interested then surely they just won't follow the discussion?
Re: Profiling live mod_perl backends
On Sun, Mar 29, 2009 at 9:52 PM, Perrin Harkins wrote: > On Sun, Mar 29, 2009 at 4:44 PM, Cosimo Streppone > wrote: > > The main problem is that in the past we experienced some kind of > > performance problems that only manifested themselves really clearly > > in production and only at peak traffic hours. > > Out of peak hours, everything was fine. > > That sounds like a problem with a shared resource like the database, > not something you'll find by profiling the code. You'd be better off > either using DBI::Profile or using logging on your database to find > the problem. > > - Perrin There's a neat idea in "Perl Hacks" where you nominate every 100th (or whatever) object as a debug object. Perhaps you could do something similar with Devel::NYTProf - profile only every 'n' th request during peak times. I assume you have checked "obvious" things like cpu & disk usage stats, KeepAlive, MaxClients etc
Re: Profiling live mod_perl backends
On Mon, Mar 30, 2009 at 2:14 PM, Cosimo Streppone wrote:
> In data 30 mars 2009 alle ore 13:46:09, Rolf Banting
> ha scritto:
>
> > On Sun, Mar 29, 2009 at 9:52 PM, Perrin Harkins
> > wrote:
> >
> >> On Sun, Mar 29, 2009 at 4:44 PM, Cosimo Streppone
> >> wrote:
> >> > The main problem is that in the past we experienced some kind of
> >> > performance problems that only manifested themselves really clearly
> >> > in production and only at peak traffic hours.
> >> > Out of peak hours, everything was fine.
> >>
> >> That sounds like a problem with a shared resource like the database,
> >> not something you'll find by profiling the code. You'd be better off
> >> either using DBI::Profile or using logging on your database to find
> >> the problem.
>
> I get the points.
>
> The problem that we had, this was in November last year,
> was that all the backends were at load 15.0-20.0 (normal was ~3-4)
> after an update to the application.
>
> In those cases, it's pretty clear where the problem is
> (CPU/load/etc...). What's not really clear is which point in the
> code is causing it.
>
> In our case, it was the code, and particularly a single function,
> used in many places, that spent a lot of time doing useless things.
> We sorted that out "by intuition", knowing the hot spots of the code.
>
> What I want to do now is to prevent this kind of problems, possibly
> in a more systematic and/or scientific way, and I thought of doing
> this by running automated performance/stress tests before deployment.
>
> While I try to get there, I thought it might be useful to dedicate 1 of the
> live backends to this "live profiling". Even if the application now is
> not having any problem, even at peak times.
>
> Maybe I just have to try and see what I get :)
>
> DBI::Profile is also another good "track" to follow.
>
> --
> Cosimo
>
If you know which routines you want to profile it is easy enough to set up
wrapped versions of the routines which record execution times etc and
install them at run time so the wrapped version gets executed.
Here's some simple test code I (mostly) found in "High Order Perl" by Mark
Jason Dominus:
package TheDude;
sub make_me_proud { return "I love you pops"}
package main;
use Data::Dumper;
my %calls;
my %times;
sub profile {
my ( $func, $name ) = @_;
my $stub = sub {
my $start = time;
## Call the real sub routine
my $return = $func->(@_);
my $end = time;
my $elapsed = $end - $start;
$calls{$name} += 1;
$times{$name}->{'elapsed'} += $elapsed;
return $return;
};
return $stub;
}
## Overwrite the sub routine with a wrapped version
no strict qw(refs);
*{"TheDude::make_me_proud"} =
profile(\&TheDude::make_me_proud,"TheDude::make_me_proud");
#
TheDude::make_me_proud() foreach (1..100);
print Dumper \%calls;
print Dumper \%times;
If you put that in a script an run you'll get something like:
$VAR1 = {
'TheDude::make_me_proud' => 100
};
$VAR1 = {
'TheDude::make_me_proud' => {
'elapsed' => 3
}
};
Obviously you can customise the routine returned by "profile" to do anything
you like.
Rolf
