Re: mod_perl weaknesses? help me build a case....
On Apr 05, [EMAIL PROTECTED] hacked the bitstream to say... Soulhuntre Hiya! Soulhuntre 1) It is VERY easy to have arcane errors in mod_perl code, and that code is Soulhuntre not as easily debugged as one could hope. While it seems that we can be very Soulhuntre careful with our own code and avoid much of this - there are numerous issues Soulhuntre about CPAN modules, that means much of the advantage of perl is called into Soulhuntre question. OTOH, it seems (from my lurking on this list occasional posts) that there are many gurus who are kind enough to help out when you have a problem. i would choose carefully which CPAN modules you rely on of course. Soulhuntre Soulhuntre 2) It seems that the stability of Apache is adversely effected - with the Soulhuntre most common reccomendations being that the apache config should be tailored Soulhuntre to restart the children every x requests to prevent memory creeping crud. Soulhuntre Soulhuntre 3) There are LOTS of posts about segfaults with bad code - this is scary :) Soulhuntre It seems like the perl core has a way to go to be ready for this? i agree with your sentiments. not sure why segfaults are not avoidable... the apache process model deals with this far better than iis to be sure though. Soulhuntre Soulhuntre 4) There does not seem to be a compatible win32/linux modperl/embedding Soulhuntre toolkit. I can use modperl/apache/::ASP under linux, but the same setup does Soulhuntre not seem stable under win32 - and the activestate ASP perlex stuff does not Soulhuntre seem completely compatible. we are using Apache::ASP with swigged c++ - perl objects, and running the same code under IIS w/ASP and ActivePerlScript. this lets you drop writing hard-to-codedebug COM crap. check out http://www.swig.org. jr -- Joel W. Reed http://ruby.ddiworld.com/jreed ---I have a 33.6Kbps modem and 1.5bps fingers---
Re: mod_perl weaknesses? help me build a case....
On Wed, 05 Apr 2000, Soulhuntre wrote: Hiya :) -Original Message- From: Ime Smits [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 05, 2000 6:57 AM To: [EMAIL PROTECTED] Subject: Re: mod_perl weaknesses? help me build a case Just because a lot of errors are openly discussed on the web (it is a community built project) it it doesn't mean there are far more bugs in Apache::ASP or mod_perl or Apache than in any other closed source product, say IIS. Agreed :) You know how it is when your trying to convince the guys upstairs to try something new :) I never had any problems with CPAN modules. I must say the only ones I make heavy use of are the DBI and mySQL modules, which never crashed whatsoever. I think that as long as you don't get into very experimental stuff, you won't have any problems. Ok, good. Like I said, most of the concerns come from the newsgroups and mailing list posts... we will be using DBI/mySQL and some of the XML stuff and a template module mostly. That's because Perl makes people lazy. If you code by the rules, there is no problem. But it ain't a problem create memory leaking code. That I know :) And yeah, cgi makes us lazy :) But reading through the caveats for mod_perl it is pretty easy to see that some of these things are subtle and require a hefty knowledge of perl internal stuff unless your just gonna "copy-n-pray" :) Linux/Apache::ASP I haven't experienced a segfault ever. In the beginning there were some initial memory leaks, but that was my own coding proplem, not a problem of perl or mod_perl or Apache. Good to know :) Thanks! | 4) There does not seem to be a compatible win32/linux modperl/embedding | toolkit. I can use modperl/apache/::ASP under linux, but the same setup does | not seem stable under win32 - and the activestate ASP perlex stuff does not | seem completely compatible. Can you give me more detail on the incompatibilities? Well, let me turn that around, has anyone succeeded in getting mod_perl running well on Apache on win2k? I have had good experiences with mod_perl/apache so far. I do all of my development in various UNIX environments (BSDs and Linux) and also use this platform for my production servers. One situation I ran into about a month ago was the need to build a demoable version of our website that my two CEOs could take on the road with them. Since neither have any UNIX experience, or maybe I should say, neither have much computer experience, I decided to port the site onto a windows box (laptop). With the exception of Apache::Request (which was easy to hack up a replacement--more or less) I had no problems moving the site over - it took about a day, half of which I spent just figuring out how to do it and getting the required software. My configuration is Apache with mod_perl and a MySQL database. I should mention though that the windows site is not a production site so I did not really pay much attention to how well (efficiently) it is running. All the functionality is there which is what I was really after. I don't use the ASP stuff so I don't know too much about that. Hope this helps andrew ... Andrew Wyllie [EMAIL PROTECTED]Open Source Integrator v.206.729.7439 __We can catify or stringify, c.206.851.9876separately or together!__ perl-5.005_03
Re: mod_perl weaknesses? help me build a case....
According to Soulhuntre: Well, let me turn that around, has anyone succeeded in getting mod_perl running well on Apache on win2k? Your problem here is going to be that mod_perl is not thread-safe and will serialize everything when running under the threaded model that apache uses under windows. If your scripts are fast enough you might be able to live with this if you use it as a back end to a lightweight front-end proxy which a busy site needs anyway. Les Mikesell [EMAIL PROTECTED]
mod_perl compat on win32? RE: mod_perl weaknesses? help me build a case....
Hiya :) -Original Message- From: Leslie Mikesell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 05, 2000 1:34 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: mod_perl weaknesses? help me build a case Your problem here is going to be that mod_perl is not thread-safe and will serialize everything when running under the threaded model that apache uses under windows. If your scripts are fast enough you might be able to live with this if you use it as a back end to a lightweight front-end proxy which a busy site needs anyway. Ok... that makes sense :) On a side note... is mod_perl/apache on linux compatible with IIS/operlex from activestate on the Win32 side? If so, that's a big boost for me... Ken --- Soulhuntre (icq# 275066) http://www.soulhuntre.com - my world http://www.dotpublishing.com - my income http://www.virtualchemy.com - my company http://www.the-estate.com - my passion
Re: mod_perl weaknesses? help me build a case....
the bible for doing that is here: http://perl.apache.org/guide/strategy.html#Alternative_architectures_for_ru cliff rayman genwax.com Michael Robinton wrote: if you use it as a back end to a lightweight front-end proxy which a busy site needs anyway. My site is starting to get "busy enough". Are there some docs that explain how to to do this. Apache proxy has always seemed unclear to me, my lack of understanding really I've been using standard apache with mod_perl for several years now and have run squid in front of it, but this is a bit of a setup hassle when things change.
RE: mod_perl weaknesses? help me build a case....
MR Wrote: My site is starting to get "busy enough". Are there some docs that explain how to to do this. Apache proxy has always seemed unclear to me, my lack of understanding really I've been using standard apache with mod_perl for several years now and have run squid in front of it, but this is a bit of a setup hassle when things change. The basic idea of running a separate "light" version of Apache and having it proxy to the "heavy" back end mod_perl server is this: Mod_perl processes/threads tend to be quite a bit larger than plain old "vanilla" Apache processes (in terms of memory). By running a "light" server and having it proxy to a mod_perl "back-end" server. The main idea is that by proxying, the front-end "light" server accepts connections from the net. Many of the users connecting may be on slow modems or other semi-slow connections. It is Apache's job to wait for the client -- it must stay open until the client gets data. But why should you be tying up an "expensive" and "heavy" mod_perl process? By using a "light" Apache server as a front end, you don't waste system resources on that. You can keep a minimal number of "heavy" processes open, because the "light" server will proxy your requests over to the mod_perl server, which will respond really quickly to the local server (no need to stay open for any significant amount of time). If you're setting up a server for an intranet or something where most users are on a fast lan, you may not realize a significant performance increase. Hope that helps... I know the explanation is kind of rough, but hey, I'm too tired to make sense :-) Russell Weiss Founder and Technical Manager InfoRelay Online Systems, Inc. http://www.InfoRelay.net/
Re: mod_perl compat on win32? RE: mod_perl weaknesses? help me build a case....
Soulhuntre wrote:
Hiya :)
-Original Message-
From: Leslie Mikesell [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, April 05, 2000 1:34 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: mod_perl weaknesses? help me build a case
Your problem here is going to be that mod_perl is not thread-safe
and will serialize everything when running under the threaded
model that apache uses under windows. If your scripts are fast enough
you might be able to live with this if you use it as a back end
to a lightweight front-end proxy which a busy site needs anyway.
Ok... that makes sense :)
On a side note... is mod_perl/apache on linux compatible with IIS/operlex
from activestate on the Win32 side?
For all intents and purposes, PerlEx is basically compatible with
mod_perl/Apache::Registry. However, the END {} blocks are interpreted
differently (augh!)... which shouldn't really be that much of an issue for
most programs.
The good thing about PerlEx as opposed to mod_perl/Win32 is that instead of
serializing all the calls to one Perl interpreter, ActiveState Perl actually
creates multiple Perl interpreter "objects" that can be round-robined among
the IIS threads.
If so, that's a big boost for me...
I've been testing all my code on both PerlEx and mod_perl. And haven't had
very many problems at all with compatibility. I think UNIX/mod_perl is faster
than NT/IIS/PerlEx on the same hardware (from my unscientific observation),
but PerlEx seems much faster than ASPs.
Later,
Gunther
