Re: mod_perl slower than expected?
Trevor Phillips wrote: Benchmarking was done using an internal before and after check using Time::HiRes (as well as various stages during processing) as well as using ab to do multiple hits in succession. If you use multiple threads in ab, a sub-optimal setting for the number of processes can hurt mod_perl performance. Try to tune it so that it's about the same as FastCGI. Two other possibilities are using a different version of Perl (like one with theads and one without), or accidentally using the wrong version of your modules. I replaced it with my own module, which again parses/compiles expressions into an external structure once, rather than doing it every time. Hmmm. How do you cache these? PerlFreshRestart On Usually a bad idea... PerlModule CGI; You could gain more speed by replacing that. CGI_Lite or CGI::Simple are faster and should still be cross-platform. On a server where there are other developers working on it, if I restart the server, it can interrupt others working. Why don't you run your own server? It's easy to do, even if everyone is on the same machine and using the same mod_perl build. In addition, if I stuff something up badly (such as a minor syntax error), it doesn't kill the whole server. You mean on startup? As a FastCGI, all I have to do to restart it is touch the main CGI file. Does that restart the whole FastCGI daemon? Without affecting other people who are developing on it? With mod_perl I restart with 'apachectl stop apachectl start'. I also have tighter control on the number of FastCGI processes, which is more useful for development. You can specify an exact number with apache if you want to. No objections to FastCGI; I just wondered if there was something we should be looking to add to mod_perl that would make it a more attractive dev environment for people who use FastCGI. I also work on FastCGI as a low-ish denominator. There's less server impact to throw a FastCGI on, than to install mod_perl, if it's not already there. If you're looking for an ISP-friendly approach to offer your potential users, check out SpeedyCGI aka PersistentPerl. It can be used without root access. - Perrin
Re: mod_perl slower than expected?
On Friday 13 June 2003 13:57, Stas Bekman wrote: Since your question is too broad to be able to easily pinpoint any problems without spending some time with it, I'd suggest reading: http://perl.apache.org/docs/1.0/guide/performance.html if you haven't done that yet. I have. Although it was several years ago now. Has much changed? I'll take a look, but I haven't seen anything in there that correlates to the sort of results I'm seeing. This isn't a perl load-time issue, and it's not a small set slow-down - it's a percentage slow-down on pages of which can take up to 10 seconds to generate and return. It's something run-time, which is different between mod_perl and FastCGI. It's bizarre... Have you heard of Apache::Reload. http://perl.apache.org/docs/1.0/guide/porting.html#Reloading_Modules_and_Re quired_Files I have now. How does it handle syntax errors? Does it kill the whole server, keep the old module running, or just kill that module? As a FastCGI, all I have to do to restart it is touch the main CGI file. I also have tighter control on the number of FastCGI processes, which is more useful for development. Looks like you may need to do some docs reading. You can easily get a total control over the number of mod_perl processes. It's all described here: http://perl.apache.org/docs/1.0/guide/performance.html Uh, yes, I can limit the Apache processes, but again, that will impact other users on the system. Really, FastCGI does just what I want, and it means I can write a module that works either as a FastCGI or a module. For content modules, that's fine. I've written a myriad of access modules, loggers, trans handlers, etc... For those, yes, they're mod_perl exclusives. But for some purposes, I find FastCGI more efficient. I'd almost be tempted to leave this app as a FastCGI - except for some places we use it we stack with other mod_perl content handlers. And I'm just baffled at this particular performance problem, since I have been through the standard things to check for. -- . Trevor Phillips - http://jurai.murdoch.edu.au/ . : Web Technical Administrator - [EMAIL PROTECTED] : | IT Services- Murdoch University | | On nights such as this, evil deeds are done. And good deeds, of / | course. But mostly evil, on the whole. / \ -- (Terry Pratchett, Wyrd Sisters) /
Re: mod_perl slower than expected?
Trevor Phillips wrote: On Friday 13 June 2003 13:57, Stas Bekman wrote: Since your question is too broad to be able to easily pinpoint any problems without spending some time with it, I'd suggest reading: http://perl.apache.org/docs/1.0/guide/performance.html if you haven't done that yet. I have. Although it was several years ago now. Has much changed? It wasn't updated much in the last year. But I did lots of updates a year before when working on the Practical mod_perl book. I'll take a look, but I haven't seen anything in there that correlates to the sort of results I'm seeing. This isn't a perl load-time issue, and it's not a small set slow-down - it's a percentage slow-down on pages of which can take up to 10 seconds to generate and return. It's something run-time, which is different between mod_perl and FastCGI. It's bizarre... As I said, if you were asking more specific question or showing code samples which are slower in mod_perl than they are in FastCGI, it'd be easier to know how to tune the setup. That's why sending you to the document was the best I could do in the current situation. Have you heard of Apache::Reload. http://perl.apache.org/docs/1.0/guide/porting.html#Reloading_Modules_and_Re quired_Files I have now. How does it handle syntax errors? Does it kill the whole server, keep the old module running, or just kill that module? it calls require(), so if that fails, the old version stays in memory. Nothing gets killed. I use it all the time and it saves me heaps of time. Give it a try. As a FastCGI, all I have to do to restart it is touch the main CGI file. I also have tighter control on the number of FastCGI processes, which is more useful for development. Looks like you may need to do some docs reading. You can easily get a total control over the number of mod_perl processes. It's all described here: http://perl.apache.org/docs/1.0/guide/performance.html Uh, yes, I can limit the Apache processes, but again, that will impact other users on the system. Really, FastCGI does just what I want, and it means I can write a module that works either as a FastCGI or a module. For content modules, that's fine. I've written a myriad of access modules, loggers, trans handlers, etc... For those, yes, they're mod_perl exclusives. But for some purposes, I find FastCGI more efficient. I'd almost be tempted to leave this app as a FastCGI - except for some places we use it we stack with other mod_perl content handlers. And I'm just baffled at this particular performance problem, since I have been through the standard things to check for. As Perrin said in his reply, we are always interested in features that can be added to mod_perl to make it more convenient to developers. Your answer so far doesn't give much insight on what FastCGI feature provides to control the number of processes in the multi-developers environment and is missing in mod_perl. I'm not familiar with FastCGI myself, so if you can be more specific about this feature, that would help. Thanks. __ 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: PerlOptions Clone/Parent in mp2
On Thu, 2003-06-12 at 02:59, Marc M. Adkins wrote:
The code to implement blocks (e.g. TIPool.../TIPool) in
config files is
pretty gnarly, too. I know it's already there for Perl, it's
one of the
places I looked when I was considering doing one of my own and
wanted to see
an example. The Apache framework is pretty strong for putting in new
directives, but not so much for adding new blocks.
Actually you can't quite do that in a 3rd party module. Currently
the pools
are internal to mod_perl. Making this customizable will require
adding hooks
to the internal tipool mechanism. When I wrote the above
pseudo-config I was
suggesting an internal support for these.
I was actually not figuring to do it myself. ;)
I was commenting on the code required to implement things like Perl or
TIPool. I've since queried the httpd-dev list and the 'official' example
is in the source for mod_proxy (with a caveat that a three-pass config file
parser may necessitate further changes at some point). It appears to be a
lot simpler than the parsing that mod_perl is doing. I was wondering...is
there a specific reason mod_perl implements Perl the way it does or is it
just code inertia?
With something like a Proxy http://foo/*/Proxy block, mod_proxy does
the right thing ( and the simple ) of using the power of
ap_walk_config() to handler the parsing of the contents of the block.
You might want to do the same thing for something like TiPool,
allowing things like
Server
MaxTiPoolConn 10
TiPoll special
MaxTiPoolConn 20
/TiPool
And have each directive in the TiPool block be handled like regular
apache directive with all the cool benefits of configuration merging,
etc.
Reason Perl blocks can't do that is becasue we can't let httpd try and
parse perl code and make any sense of it. If you look closely, a Perl
block simply slurps all its contents and feeds it to perl for
processing.
Hope this makes sense.
mma
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/print||$$++redo}'
signature.asc
Description: This is a digitally signed message part
Re: How practical is that Practical mod_perl?
Hi Perrin, Thank you for the response. At least it's better to know that the book is not that bad in common sense. Let's try to talk a little (and with only minimum of emotions) about the details that just pissed me off yesterday. Every new book written about mod_perl is a very important event for the community of all people participating in development and implementation of this really good and progressive technology. This is a kind of our public face. This is a way to promote our real achievements to people who do not subscribe to this mailing list and do not read our on-line docs carefully. Every good book about mod_perl achievements can result in better contracts for each of us and can bring aboard new talented contributors. A bad book can damage/destroy public interest and finally can kill this technology. We all are in one boat over here. We should together refrain from doing mistakes (at least publicly). Personally I fail to understand: Why would I hesitate to ask list for a help being ordered to write (or review) things in which I feel not quite expert? Of course, it is not mandatory to do when you feel strong enough to take full responsibility for the result... It's my firm belief that mod_perl-made web content compression is easy recognizable and very important achievement of our community. It saves real money and allows some real providers to serve higher content volumes without increasing hardware and traffic expenditures. It might be a brilliant promoter of mod_perl if/when being introduced appropriately... Yes, I know that content compression is not in that common use to date, and I know why. Even more - I know how to fix the situation. That was why I came up here with my Apache::Dynagzip. It is really work horse: universal, flexible, and easy configurable. To date there are no other module around with close set of properties and options... And I can not write this in my FAQ myself. Because it would be reasonably considered an impolite behavior. That was a good chance with a new book... I will be thinking about your idea concerning FAQ... Thanks, Slava - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:13 PM Subject: Re: How practical is that Practical mod_perl? On Thu, 2003-06-12 at 03:03, Slava Bizyayev wrote: Yesterday I've finally received a long-waiting book (http://www.modperlbook.org/) written by Stas Bekman and Eric Cholet. In fact, I don't know who is that Eric Cholet Eric pre-dates you on this list by a few years. He knows his stuff. The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. BTW, it would be curious to see HTTP client logs from Apache::GzipChain over HTTP/1.0 and HTTP/1.1 for dynamically generated and partially flushed content. And how about SSL over HTTP/1.1? It would probably help even me to switch to the right handler finally one day. It's a 900 page book! You're talking about, what 7 pages of it? There is going to be some errata, just like there is in every other technical book. The fact is, most people do not compress their content, and those who do probably don't have as much experience with it as you do. I certainly wouldn't know about these details you're speaking of, and the FAQ which you maintain doesn't fully discuss them either. It says that Dynagzip handles them, but not that the others don't. Maybe you should add a more complete comparison. For some reason Stas forgot even to mention http://perl.apache.org/docs/tutorials/client/compression/compression.html which he personally initiated about a year ago when we discussed Apache::Dynagzip over here. Is there something wrong with that text? You can't expect every page of the mod_perl site to be mentioned in the book. From my point of view, that was namely Stas who failed in this situation. He failed to recognize that the absence of information in area that you do not understand (or don't care to understand) is always better (and much more practical), than wrong and misleading recommendations. It doesn't sound like the advice in the book is so terrible to me, just not as good as it could be. More to the point, I don't see how you can say this is all Stas' fault. Why not Eric? Why not all the technical reviewers (like me) who didn't know enough or care enough about content compression to suggest changes there? There's no need to be insulting Stas. My real question to the list subscribers (see subject line) rises from the fact that I cannot review other parts of this book with full details, and since this book provides misleading recommendations about content compression opportunities on mod_perl enabled Apache I'm not sure any more about other parts... I haven't received my copy yet, but the parts of the earlier version that I reviewed
RE: PerlOptions Clone/Parent in mp2
With something like a Proxy http://foo/*/Proxy block, mod_proxy does the right thing ( and the simple ) of using the power of ap_walk_config() to handler the parsing of the contents of the block. [...snip...] Reason Perl blocks can't do that is becasue we can't let httpd try and parse perl code and make any sense of it. If you look closely, a Perl block simply slurps all its contents and feeds it to perl for processing. Ah...I see...it's the MP_CMD_SRV_RAW_ARGS_ON_READ which translates into AP_INIT_RAW_ARGS with the all-important EXEC_ON_READ flag that allows you to waylay the configuration file on the way in. Otherwise the directives are partially processed and constructed into a tree, which you don't want. Turns out mod_macro does the same thing. Doesn't apply to my code, thank goodness. thx, mma
Re: How practical is that Practical mod_perl?
NN-4.X sends HTTP header Accept-Encoding: gzip requesting any web content. Unfortunately NN-4.X fails to ungzip css files and JavaScript libraries. It is pretty old and well-known bug in NN-4.X. To work around this bug mod_gzip uses internal procedures for recognition of NN-4.X. The similar approach is used in mod_deflate. Apache::GzipChain does not have internal resources to work around this bug. You can find on CPAN http://search.cpan.org/author/SLAVA/Apache-CompressClientFixup-0.06/ which is supposed to serve any mod_perl compressor including Apache::GzipChain, but this handler is missed in example on p.402. # From: [EMAIL PROTECTED] # To: [EMAIL PROTECTED] # Date: Wed, 15 Jan 2003 20:05:06 +0200 # # ... Our customers still include 17% Netscape 4 users, sigh ... # Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:41 PM Subject: Re: How practical is that Practical mod_perl? The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. Can we have some more information about what in the implementation leads to the unsatisfied clients?
Re: mod_perl slower than expected?
On Fri, Jun 13, 2003 at 01:16:48PM +0800, Trevor Phillips wrote: On Friday 13 June 2003 12:26, Perrin Harkins wrote: You're not giving us much to go on here. What kind of changes did you make? Can you verify that you are running the correct versions of the modules under mod_perl? Are you seeing generally about the same performance on both platforms? What does you httpd.conf look like? Ok, EDO (the name of the app) parses HTML for additional custom markups, and then executes functionality based on those markups (putting it very simply). The general procedure for a request involves: - Creating an EDO::Parser object - Parsing HTML source into an internal structure (this can be cached to avoid caching on every request) - Executing instructions based on the parsed code The app does a lot of talking to databases - predominantly MySQL for testing. Are you creating and then distroying a lot of database connections in your modules? Apache::DBI caches these connections saving you the connecton overhead. Not sure if FastCGI can do that. Just my thoughts Paddy
Re: How practical is that Practical mod_perl?
Hi Stas, In my understanding you would better rewrite p.401-402 from the scratch for the next edition (which is not supposed to happen very soon, isn't it?). Otherwise, you will have to rewrite Apache::GzipChain appropriately. Whatever you decide, I would be more than happy to help you in that work. Just let me know. I will be waiting around. Thanks, Slava - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Perrin Harkins [EMAIL PROTECTED] Cc: Slava Bizyayev [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 6:56 PM Subject: Re: How practical is that Practical mod_perl? I've very little to add to Perrin's wise reply, other than if you find incorrect or outdated information please submit it to us and we will make sure that the corrections/additions will make it to the Errata and will be rectified in the future editions. For example Chris Winters emailed me telling that Appendix B (Apache Perl Modules) doesn't mention OpenInteract. So it'll be mentioned in the next update. BTW, Eric is working on creating a new site for http://modperlbook.org/ which will include the source code, errata and other useful information. We will let you know when this work has been completed. __ 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
Use mod_perl2 in production environment?
Hi guys, within the next 2 months I have to create an webapplication from scratch using mod_perl for a customer. The customer wanted to host the application at his provider which refuses the installation of Apache2+mod_perl2 because he considers them to be Beta-Software whereas he considers Apache1+mod_perl1 under Win32 to be stable. My job is it now to write a response to our customer and I want to have some information from developers and/or users about the stability of Apache2+mod_perl2+Unix and Apache1+mod_perl1+Win32. thx Tom
Re: How practical is that Practical mod_perl?
Hi all, On Fri, 13 Jun 2003, Slava Bizyayev wrote: We should together refrain from doing mistakes (at least publicly). It is unrealistic (and perhaps a little Oriental?) to refuse to accept that we make mistakes, and that we will continue to make them. It is far more constructive to prepare for them - usually one would try to minimise their impact; to acknowledge them, and if necessary to own up to them :) when they are made; and to take whatever corrective action might be called for in a timely fashion. In all the above, for several years Stas has set us a fine example. Personally I fail to understand: Why would I hesitate to ask list for a help being ordered to write (or review) things in which I feel not quite expert? Of course, it is not mandatory to do when you feel strong enough to take full responsibility for the result... I don't know if I fully understand what you're saying here. When, here on this List and on numerous occasions, Stas begged us for reviews of the text of his book, did you respond? Many of us did. If we missed some mistakes we will all share the blame and I for one am quite happy with that. Let's call an end to this. 73, Ged.
UTF-8 support [was : (Re: [mp2] make test fails with 1.99_10-dev sources on redhat)]
--- Stas Bekman [EMAIL PROTECTED] wrote: My understanding is that setting locale to UTF8 makes it try to open everything as a UTF8 document, but not everything is one. It causes problems for Java and Konsole too apparently. It could simply be that Perl's handlling of UTF8 is broken, but I didn't want UTF8 in the first place so putting LANG back to what it was before seems like a reasonable fix to me. If I understand correctly most XML parsers support UTF-8 primarily. If perl's UTF-8 support is broken in 5.8.0 doesnt that mean it will break any mod_perl application which is handling XML's or UTF-8 data ? What about Axkit etc ? Anyone facing problem handling UTF-8 data using 5.8.0 based mod_perl setup ? Mithun __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com
Re: How practical is that Practical mod_perl?
ok, i thought you might have been referred to problems that early versions of IE6 seemed to have with gzip, or with deflate problems in mozilla/n6. Slava Bizyayev wrote: NN-4.X sends HTTP header Accept-Encoding: gzip requesting any web content. Unfortunately NN-4.X fails to ungzip css files and JavaScript libraries. It is pretty old and well-known bug in NN-4.X. To work around this bug mod_gzip uses internal procedures for recognition of NN-4.X. The similar approach is used in mod_deflate. Apache::GzipChain does not have internal resources to work around this bug. You can find on CPAN http://search.cpan.org/author/SLAVA/Apache-CompressClientFixup-0.06/ which is supposed to serve any mod_perl compressor including Apache::GzipChain, but this handler is missed in example on p.402. # From: [EMAIL PROTECTED] # To: [EMAIL PROTECTED] # Date: Wed, 15 Jan 2003 20:05:06 +0200 # # ... Our customers still include 17% Netscape 4 users, sigh ... # Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:41 PM Subject: Re: How practical is that Practical mod_perl? The direct implementation of the example configuration p.402 is supposed to lead you to about 15% of unsatisfied clients recently. Can we have some more information about what in the implementation leads to the unsatisfied clients?
Re: UTF-8 support [was : (Re: [mp2] make test fails with 1.99_10-devsources on redhat)]
Mithun Bhattacharya wrote: If perl's UTF-8 support is broken in 5.8.0 doesnt that mean it will break any mod_perl application which is handling XML's or UTF-8 data ? I didn't say it was broken. I don't really know if it is. What I do know is that some documents, including CPAN modules, are not UTF8 compliant, and opening them as UTF8 gives mysterious errors and test failures. Remember, this locale setting is a recent change. I doubt that chaning it back to what it was in Red Hat 7.3 will impact XML parsing. - Perrin
RE: Use mod_perl2 in production environment?
My job is it now to write a response to our customer and I want to have some information from developers and/or users about the stability of Apache2+mod_perl2+Unix and Apache1+mod_perl1+Win32. This is kinda comparing apples to oranges. mod_perl1+Apache1+Win32 is a single threaded environment. Apache can only accept one request at a time. Not a good idea for a production environment. If a server request takes a long time, everyone waits in line until that is complete. I would think that Apache1+mod_perl1+Unix is your most stable option. If you have to go with Win32, I would suggest going with Apache2+mod_perl2. Although it's technically not 100%, I've been using it for the past 4 months with no problems (YET!). Good Luck, Mike -Original Message- From: Tom Schindl [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2003 3:30 AM To: modperl Subject: Use mod_perl2 in production environment? Hi guys, within the next 2 months I have to create an webapplication from scratch using mod_perl for a customer. The customer wanted to host the application at his provider which refuses the installation of Apache2+mod_perl2 because he considers them to be Beta-Software whereas he considers Apache1+mod_perl1 under Win32 to be stable. thx Tom
RE: Use mod_perl2 in production environment?
On Fri, 2003-06-13 at 10:07, Mike Zelina wrote: mod_perl1+Apache1+Win32 is a single threaded environment. Apache can only accept one request at a time. Not a good idea for a production environment. If a server request takes a long time, everyone waits in line until that is complete. Note that this is written up on the site as well: http://perl.apache.org/docs/1.0/os/win32/index.html In addition, any use of sockets created by your code will be a problem with mod_perl 1 on win32. - Perrin
Re: mod_perl slower than expected?
[ please keep it on the list ] On Fri, 2003-06-13 at 03:23, Trevor Phillips wrote: Two other possibilities are using a different version of Perl (like one with theads and one without), or accidentally using the wrong version of your modules. I don't think so. Pretty standard Debian install, Perl 5.6.1... And you compiled both mod_perl and FastCGI yourself? PerlModule CGI; You could gain more speed by replacing that. CGI_Lite or CGI::Simple are faster and should still be cross-platform. That's preloaded for some other modules. EDO uses Apache::Registry. (Which is another possible point of suspicion, although it's not used much... And Apache::Registry is supposed to be faster than CGI (which the FastCGI version uses) too...) Apache::Registry is faster than a CGI script. The CGI.pm module does something totally different, i.e. parsing params. CGI::Simple implements the same interface and is a drop-in replacement, so it might be worth a try. How does the performance compare in general? Apache::Registry is slower than writing your own handler, so it could be masking your speed gain to some degree. Why don't you run your own server? It's easy to do, even if everyone is on the same machine and using the same mod_perl build. I've never had a need to? Our dev server is close to our prod server in config, to aid in testing possible issues conflicts. I do it for the reason you mentioned, i.e. restart without disturbing anyone else. As a FastCGI, all I have to do to restart it is touch the main CGI file. Does that restart the whole FastCGI daemon? Without affecting other people who are developing on it? Ummm, the script IS the daemon. mod_fastcgi knows how to talk to the FastCGIs, and manages the loading (and killing) of them. Each FastCGI app runs as its own persistent process, and you can either statically control the number of processes, or give it a dynamic range to balance requests with. So it takes down the script, but that doesn't affect the rest of the developers because they aren't working on the same script? That makes sense. SpeedyCGI is similar, I believe. So when a FastCGI is thrashing your CPU, top shows the actual CGI name, and you can restart it by killing it, or, if enabled, by touching it, with no effect on any apache daemons, or other FastCGIs. Showing the script name in top is a nice feature. With mod_perl you have to use something Apache::VMonitor for this. You can specify an exact number with apache if you want to. But again, that limits what else the server is doing. I could have an Apache server with 50 daemons, used to deliver images, boring stuff, mod_perl stuff, whatever, and still control my FastCGI's processes. Yes, this is true. In production I use a front-end proxy setup for this reason. Personally, I'd love to see a blend: Where I can have a light-weight mod_perl style interface in all daemons, which can interface to a possibly more limited number of FastCGIs. Gain the power of mod_perl, with the resource control of FastCGIs. You can do that with mod_perl 2, by setting up the number of perl interpreters you want to have available for each script. See http://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support - Perrin
Re: How practical is that Practical mod_perl?
On Fri, 2003-06-13 at 03:46, Slava Bizyayev wrote: Every good book about mod_perl achievements can result in better contracts for each of us and can bring aboard new talented contributors. A bad book can damage/destroy public interest and finally can kill this technology. There are many bad books about Perl and they haven't killed it. Regardless, I think what you're forgetting here is that you are complaining about a problem that is very obscure. Personally I fail to understand: Why would I hesitate to ask list for a help being ordered to write (or review) things in which I feel not quite expert? Stas asked many times for people to review the book, and some of us did. If I were writing a book and wanted to include a small example of compression, I would expect that reading the FAQ, reading the POD for the modules, and testing one of them out with whatever browsers I have handy would be enough. I would not feel the need to run an exhaustive test of every browser ever made just for a couple of pages in a huge book that is mostly about other things. To date there are no other module around with close set of properties and options... And I can not write this in my FAQ myself. Because it would be reasonably considered an impolite behavior. You can write the simple facts of the situation. The things you just mentioned on the list about Netscape 4 support are not in the FAQ. Neither is Apache::CompressClientFixup. You need to put them there, or no one will know about these issues. For example, you could add a section like this: Q: Are there any known problems with specific browsers? A: Yes, Netscape 4 has problems with compressed cascading style sheets and JavaScript files. Apache::Dynagzip handles this by detecting Netscape 4 and leaving those files uncompressed. If you are using one of the other modules, you can use Apache::CompressClientFixup to disable compression for these files. ... You get the idea. As long as you talk about specific issues and don't generally slam the other modules, no one will be upset by it. - Perrin
Re: Large Data Set In Mod_Perl
On Wed, May 28, 2003 at 10:07:39PM -0400, Dale Lancaster wrote:
For the perl hash, I would key the hash on the combo of planet and date,
something like:
my %Planets = (
jupiter= {
1900-01-01= ( 5h 39m 18s, +22o
4.0', 28.922, -15,128, -164.799, set),
1900-01-02= ( 5h 39m 18s, +22o
4.0', 28.922, -15,128, -164.799, set),
},
neptune= {
1900-01-01= ( 5h 39m 18s, +22o
4.0', 28.922, -15,128, -164.799, set),
1900-01-02= ( 5h 39m 18s, +22o
4.0', 28.922, -15,128, -164.799, set),
},
) ;
my $Planets = {
jupiter= {
1900 = {
01 = {
01 = 1, # Record number in a file
02 = 2,
}.
02 = { ...},
This would not require the entire dataset to be stored in memory but rather an offset
to a file possition which could be randomly accessed.
However If I ever heard of a case for use of a fixed width ascii file using spacing
records this is it.
If you had one file per planet and assuming that you wanted to start on 1900-01-01
my $record_width=90;
my $offset = (($year-1900)*372+(($month-1)*31)+($day-1))*$record_width;
# 1900-01-01 would be offset 0
# 2003-06-13 would be offset 3463560
This format would require blank records inserted for 1900-02-30 etc. but a simple
script could auto generate the file.
One advantage of this would be the OS would file cache the read only file.
Just my toughts, hope it helps.
Paddy
Re: Large Data Set In Mod_Perl
On Fri, 2003-06-13 at 12:02, Patrick Mulvany wrote: However If I ever heard of a case for use of a fixed width ascii file using spacing records this is it. Why make your life difficult? Just use a dbm file. - Perrin
problem building libapreq on Solaris
Hello, I've just compiled Apache 1.3.27 with mod_perl 1.27 from their tarballs on Solaris. perl is 5.8.0 packaged for Solaris. The installation of libapreq with cpan(1) stops here: Running make test make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.1/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.1/Cookie' t/httpd -f `pwd`/t/httpd.conf /bin/sh: t/httpd: not found make: *** [start_httpd] Error 1 /usr/local/bin/make test -- NOT OK Looks like it's taking t/httpd instead of /usr/local/apache/bin/httpd, though I entered that full path to httpd in a previous prompt. With similar settings I've just smoothly installed libapreq on Debian, do you know what can be happening? -- fxn
Re: How practical is that Practical mod_perl?
It arrived, today. (Practical mod_perl ) My first impression was ...!, this is a Fat Book!!! while I browse the book, I found some chapters importants. I believe that all know to Stas Bekman for your contributions to mod_perl documentation and tests, this is a good book, and I hope to discuss his content with us. Regards. Perrin Harkins wrote: On Fri, 2003-06-13 at 03:46, Slava Bizyayev wrote: Every good book about mod_perl achievements can result in better contractsfor each of us and can bring aboard new talented contributors. A bad bookcan damage/destroy public interest and finally can kill this technology. There are many bad books about Perl and they haven't killed it. Regardless, I think what you're forgetting here is that you arecomplaining about a problem that is very obscure. Personally I fail to understand: Why would Ihesitate to ask list for a help being ordered to write (or review) things inwhich I feel not quite expert? Stas asked many times for people to review the book, and some of us did.If I were writing a book and wanted to include a small example ofcompression, I would expect that reading the FAQ, reading the POD forthe modules, and testing one of them out with whatever browsers I havehandy would be enough. I would not feel the need to run an exhaustivetest of every browser ever made just for a couple of pages in a hugebook that is mostly about other things. To date there are no other module aroundwith close set of properties and options... And I can not write this in myFAQ myself. Because it would be reasonably considered an impolite behavior. You can write the simple facts of the situation. The things you justmentioned on the list about Netscape 4 support are not in the FAQ. Neither is Apache::CompressClientFixup. You need to put them there, orno one will know about these issues.For example, you could add a section like this:Q: Are there any known problems with specific browsers?A: Yes, Netscape 4 has problems with compressed cascading style sheetsand _javascript_ files. Apache::Dynagzip handles this by detectingNetscape 4 and leaving those files uncompressed. If you are using oneof the other modules, you can use Apache::CompressClientFixup to disablecompression for these files You get the idea. As long as you talk about specific issues anddon't generally slam the other modules, no one will be upset by it.- Perrin
Re: [mp1] 1.28 release candidate #1
Hi there, On 9 Jun 2003, Philippe M. Chiasson wrote: Finally, the first mod_perl 1.28 release candidate #1 has arrived. [snip] Please give this release a spin Linux 2.5.69, gcc 3.2.3, glibc 2.3.1, perl 5.8.0; 1300MHz Duron (x86). All tests successful, 6 tests skipped. Files=34, Tests=400, 13 wallclock secs ( 7.88 cusr + 1.60 csys = 9.48 CPU) No problems at all. 73, Ged.
handler($$) unreliability
I have handler that looks like this:
sub handler ($$) {
my ($class, $apache) =3D @_;
Apache::request($apache);
$apache-status(200); # Default
#.
}
The vast majority of the time, this works fine. Every now
and then, usually after the apache server has been up
for a while, and usually under substantial load,
it appears that the handler in one child process starts
being called as if it did not have the prototype.
That is, $apache ($r) is in $_[0] instead of $_[1],
and I get messages like this:
[Fri Jun 13 06:00:06 2003] [error] Can't call method status on an undefin=
ed
+value at Project/Control.pm line 116.
And things quit working because $apache is not set properly.
A server restart clears this up. This is a perl5.6.0
DSO build of mod_perl/apache (1.27), but I am fairly certain I
have also seen this occur on a static mod_perl/apache.
Any ideas on what causes this or a good way to track it down?
--
Matthew Pressly
Re: problem building libapreq on Solaris
Xavier Noria [EMAIL PROTECTED] writes: [...] Looks like it's taking t/httpd instead of /usr/local/apache/bin/httpd, though I entered that full path to httpd in a previous prompt. With similar settings I've just smoothly installed libapreq on Debian, do you know what can be happening? We've replaced the Apache::test suite in 1.1 with an Apache::Test based one, and are planning to release it as soon as the kinks are worked out. Please try out the latest release candidate at http://httpd.apache.org/~joes/libapreq-1.2_rc2.tar.gz and see if you have better luck with the new tests. (You may need to install Apache::Test from CPAN first.) -- Joe Schaefer
RE: handler($$) unreliability
Are you using 'lookup_uri' or another form of subrequest somewhere
in your handlers? Try tracing your request and see where it goes
wrong. I had similar problems and it pointed out to be an error in
a subrequest. Consult the mailinglist archive if you want.
--Frank
I have handler that looks like this:
sub handler ($$) {
my ($class, $apache) =3D @_;
Apache::request($apache);
$apache-status(200); # Default
#.
}
The vast majority of the time, this works fine. Every now
and then, usually after the apache server has been up
...
RE: [mp2] make test fails nearly all tests...
No problem. Today has been crazy, but I should be able to post this information on Monday morning. Thanks again. =) --TWH -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2003 4:38 PM To: Tim Howell Cc: [EMAIL PROTECTED] Subject: Re: [mp2] make test fails nearly all tests... Tim Howell wrote: Stas (and others)-- Following your suggestion I built/tested as a normal user. This time only one test fails (one of the CGI tests). Below is the output from make test. Great. However if you don't mind to help others, I'd like you to help me to resolve your original problem, it shouldn't be a problem to run tests as root. So if you can answer my questions from the original reply to you, that will help a lot Thanks for your help. I've only been using unix/linux for a few months, but I've learned an enormous amount from lists like this. I really appreciate it. We all have been helped while being newbies and try to help others in the same positions we once were. It's a win-win vicious circle ;) Just in case you don't have the original reply, here is what I wanted to know (that's when you return to run the build and tests as root, not a normal user, which we now know that works): -- Looks like you encounter permission problems. Since you have /root/mod_perl-1.99_09/t/hooks in the path. I'm pretty sure that if you build/test as a normal user and only su to install, everything will work just fine. We try to provide a workaround for testing with root and what we do is chown the files to the uid/gid the server is configured to run with. This is because the server can't be run as root for security reasons. Can you do: grep User t/conf/httpd.conf it tries to pick the 'httpd' or 'nobody' user to run the tests with. If you don't have such user on your machine this may explain the problem you are having. Also, I'd like to see the output of 'make test', since it tells me when it chowns the files and to which uid/gid. __ 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
Help pls
Hi, I have probs with installing mod_perl onto apache server.PPM installed the mod_perl without probs so I added the LoadModule perl_module "modules/mod_perl.so" directive into http.conf. Now everytime apache is starting it does not start and returns error message: Syntax error on line 992 of c:/Program Files/Apache Group/Apache2/modules/mod_perl.so into server: Module was not found. The file mod_perl.so is in correct location. Spent hours searching web for solution but only thing I've found is to add LoadFile "C:/Perl/bin/perl56.dll" into http.conf before the LoadModule perl_module "modules/mod_perl.so" directive but it does not work neither. Can someone help me pls? I have xp professional, ver. of Apache 2.0.46 and built of perl is 635. Oskar
apache::request parse() doesn't capture abort error
Hello, first this is my configuration, all were installed by hand: - apache 1.3.27 - libapreq-1.1 - mod_perl 1.27 the users of this project can upload big files to the website (videos mostly). SoI use an html popup where a mod_perl handler receives the data, let's suppose its 100Mb. If the user closes the popup in the middle of an upload, Apache::Request parse() isn't throwing any error, and all the following code in my module savesthe file incomplete in the system, which of course is garbage data. Is this a bug, an incomplete feature, or is my configuration? If parse is supposed to return an error code, which one is that? 206 = HTTP_PARTIAL_CONTENT? Ok, now let's suppose that this error is fixed. I want to do several uploads fromthe same popup at once, so I have 5 file boxes in the form. If the user closesthe popup before the process ends, i'd like to save only the completed files, how could I check which files are correctly uploaded, and which ones are incomplete? Any help would be great people, thanks. -- Hector Pizarro Amautatech
Re: Help pls
On Sat, 14 Jun 2003, Oskar wrote: Hi, I have probs with installing mod_perl onto apache server. PPM installed the mod_perl without probs so I added the LoadModule perl_module modules/mod_perl.so directive into http.conf. Now everytime apache is starting it does not start and returns error message: Syntax error on line 992 of c:/Program Files/Apache Group/Apache2/modules/mod_perl.so into server: Module was not found. The file mod_perl.so is in correct location. Spent hours searching web for solution but only thing I've found is to add LoadFile C:/Perl/bin/perl56.dll into http.conf before the LoadModule perl_module modules/mod_perl.so directive but it does not work neither. Can someone help me pls? I have xp professional, ver. of Apache 2.0.46 and built of perl is 635. Oskar As is described under http://perl.apache.org/docs/2.0/os/win32/, ActivePerl 6xx doesn't work well with mod_perl 2. If you're wanting to stick with 6xx, you'll have to get Apache/1.3 and mod_perl 1. If you want to use Apache/2.0 and mod_perl 2, you'll have to get ActivePerl 8xx (based on perl-5.8). -- best regards, randy kobes
