RE: mod_perl vs. C for high performance Apache modules
On Fri, 2001-12-14 at 14:27, Thomas Moore wrote: I spoke to the technical lead at Yahoo who said mod_perl will not scale as well as c++ when you get to their level of traffic, but for a large Isn't that coming from a company using Python? I see that most of their URLs include a tell-tale .py. Of course, whether that's really Python or not Matt
Re: Excellent article on Apache/mod_perl at eToys
On Tue, 2001-10-23 at 12:31, Dave Hodgkinson wrote: Nathan Torkington [EMAIL PROTECTED] writes: Is there a nice graphicy map of what actually constitutes J2EE onto which we can overlay the relevant perl bitz? Something like this: http://www.onjava.com/pub/a/onjava/api_map/ http://java.sun.com/j2ee/ I wonder if such a P2EE project should build on CORBA just as J2EE does? Is interoperability with J2EE a goal? The other approach is to get the Perl language ported to the JVM. I know some work has been put into that. In this case it's important to be able to access the Java API's as easily as it is in Java. I lean toward the second approach since it would give P2EE a faster start, building on already existent frameworks. Eg. you could begin writing EJB components in perl immediately. Matt -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
RE: Excellent article on Apache/mod_perl at eToys
On Mon, 2001-10-22 at 20:14, Robert Koberg wrote: For comparions, a nice aspect of j2ee applications IMHO is the application server tends to be more general. ie. the application server is not just the web server (as it is with mod_perl). I've found j2ee features such as message beans, queues and such especially useful for back-end work. For these reasons, I personally don't buy the argument that mod_perl makes an effective application server for a good sized task (your mileage will vary no doubt ;). What is stopping you from using both, if you want? Actually, I already do -- but not at the same time. The criteria I personally use is basically this: if the task doesn't involve more than one or two disparate system to be talked to, and a two tier model (apache and a rdbms for example) fits the problem well, then I'll chose Perl (mod_perl, Mason and *sometimes* ORBit's Perl bindings). If the app is to talk to a number of disparate systems and a variety of client types (stand alone app, web, wireless etc.) then generally I'll use the a J2EE app server etc. Of course there are will be exceptions. ORBit is a corba orb, BTW. Matt -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: Excellent article on Apache/mod_perl at eToys
On Mon, 2001-10-22 at 21:27, Perrin Harkins wrote: It sounds like the limitation there is that you're interfacing with systems that can't notify you when something new happens. That's not Perl's fault. If you wrote your daemons in Java alpahabet soup, they'd still have to poll the pop3 server. Well, I'd more likely be using a standard javamail API within the context of a EJB server. There is a fairly rich set of call backs there which mean I generally don't have to poll/sleep etc. Also true of the java message service. -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: Excellent article on Apache/mod_perl at eToys
On Tue, 2001-10-23 at 10:09, Gunther Birznieks wrote: At 08:46 PM 10/23/2001, Rob Nagler wrote: I don't quite understand the difference between worflow in the front-end and workflow in the back-end. They both change. The danger of making one part of the system easier to change is that people tend to cheat. They won't put the business logic in the back-end if it takes twice as long. Yes, people can cheat. But generally the workflow that is most likely to change is the UI based workflow. UI isn't just about templates, it's a lot about how you go from one screen to the next, or not. Actually business logic is a bit of a misnomer because there is plenty of business logic in the front-end from your choice of fields to the javascript to the UI workflow. I agree. Basically there's front end business logic which defined the work flow of the client's end (web server/web browser etc). And then business logic in the middle tier. I've been using Apache/Jakarta Struts for the front end business stuff, a row of session beans (java speak for purely process related, not data related objects) behind the client to model work flow and then another row of entity beans (java speak for data object persistence) to get at a rdbms. This arrangement has worked well for me. This approach makes cheating code look immediately out-of-place, and just downright embarrassing :) Is there a Perl equivalent to Struts? Mason seems to come close if you keep yourself disciplined somewhat. -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: Excellent article on Apache/mod_perl at eToys
Firstly, I am curious... Why was Berkeley DB chosen for caching when a RDBMS (mysql in this case) was already being used? Secondly, I've worked on a good-sized commerce site with mod_perl+HTML::Mason. One of the more dirty secrets is that the back-end of the site involves several standalone perl programs running as daemons. What's even worse is; most of them have to sit in poll/wait loops waiting on message from external systems (such as pop3 servers, ccvs etc.) For comparions, a nice aspect of j2ee applications IMHO is the application server tends to be more general. ie. the application server is not just the web server (as it is with mod_perl). I've found j2ee features such as message beans, queues and such especially useful for back-end work. For these reasons, I personally don't buy the argument that mod_perl makes an effective application server for a good sized task (your mileage will vary no doubt ;). So again, I'm curious, what does the eToys.com site back-end stuff look like? Great article BTW, Bill Perrin, Matt On Thu, 2001-10-18 at 21:11, Andrew Ho wrote: Hello, I checked the list archives and it didn't look like this had been posted yet. For those of you who haven't seen it yet... a great read on perl.com about the Apache/mod_perl setup at eToys, co-authored by our own mod_perl regular contributer Perrin Harkins. http://www.perl.com/pub/a/2001/10/17/etoys.html Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 -- -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
middle tier like j2ee only in mod_perl, possible?
I've been experimenting with what's possible in terms of having mod_perl interface with a system of business logic rather than a relational database. ie. I am try to find the find the mod_perl equivalent of Java's EJB tier in the following: (web brower + servlets) --- (ejb) --- (relational dbms) I've searched CPAN. Here are some better candidates: RPC::PlClient/PlServer/Simple, XMLRPC/SOAP, CORBA::ORBit/Mico. The most promising route seems to be a CORBA interface since such objects could be easily used by other systems. The feeling I'm left with is that although these could be used to implement a middle tier, it ain't exactly the playground filled with toys that J2EE has become. So I'm interested... Has anyone had success with implementing a middle tier for mod_perl? What with? And how successful was it? Matthew
Re: Fast DB access
On 17 Apr 2001 18:24:43 -0700, clayton wrote:
i wanted a good benchmark for postgres and mysql
{i hope to transpose the sql properly!}
This is a good comparison of MySQL and PostgreSQL 7.0:
"Open Source Databases: As The Tables Turn" --
http://www.phpbuilder.com/columns/tim20001112.php3
Re: Fast DB access
On 18 Apr 2001 12:00:57 +0530, Differentiated Software Solutions Pvt. Ltd., wrote: Hi, There are 4 responses to our results. We will answer them to the best of our ability. MATT This is a very very old version of postgresql. Try it again with 7.1 for MATT more respectable results. Accepted. We knew this when we conducted the benchmarks. We've had terrible experience with postgres. Firstly on performance and more importantly on availablity. Some of you should try pounding postgres with upwards of 25 queries a second and see the results. The postgres server will spew out error messages and shutdown. Last year we had a several nightouts writing code to protect postgres from an overload of queries. I've written several mails to postgres mailing lists and even to mod_perl in desperation. Problem wasn't solved. I'm on several postgresql mailing lists and couldn't find a recent post from you complaining about 6.5.3 performance problems (not even by an archive search). Your benchmark is worthless until you try postgresql 7.1. There have been two major releases of postgresql since 6.5.x (ie. 7.0 and 7.1) and several minor ones over a total of 2-3 years. It's no secret that they have tremendous performance improvements over 6.5.x. So why did you benchmark 6.5.x? We'll try out 7.1. Maybe it is a major improvement over 6.5.3. I find it difficult to believe that it will improve performance by 36 times I believe postgresql 7.0 had an extensive redesign in comparison to 6.5.x. So yes, you *can* expect that level of performance improvement. CLAYTON i wanted a good benchmark for postgres and mysql This is a good comparison of MySQL and PostgreSQL 7.0: "Open Source Databases: As The Tables Turn" -- http://www.phpbuilder.com/columns/tim20001112.php3 We haven't tried this one. We are doing a project on mysql. Our preliminary assessment is, it's a shocker. They justify not having commit and rollback!! Makes us think whether they are even lower end than MS-Access. Again, checkout PostgreSQL 7.1 -- I believe "commit" and "rollback" (as you put it) are available. BTW, I would like to see that comment about MS-Access posted to pgsql-general... I dare ya. :P Matthew
(OT) Re: Fast DB access
On 18 Apr 2001 08:49:38 -0700, clayton cottingham wrote:
Matthew Kennedy wrote:
On 17 Apr 2001 18:24:43 -0700, clayton wrote:
i wanted a good benchmark for postgres and mysql
{i hope to transpose the sql properly!}
This is a good comparison of MySQL and PostgreSQL 7.0:
"Open Source Databases: As The Tables Turn" --
http://www.phpbuilder.com/columns/tim20001112.php3
very nice not all the info i was looking for but some solid answers
This might help too:
http://www.angelfire.com/nv/aldev/pgsql/GreatBridge.html
Of course benchmarks are so debatable anyway..
Matt
/dev/null problems
Hello, From the mod_perl guide: syntax error at /dev/null line 1, near "line arguments:" Execution of /dev/null aborted due to compilation errors. parse: Undefined error: 0 There is a chance that your /dev/null device is broken. Try: % sudo echo /dev/null This is exactly the problem I have been getting when starting Apache mod_perl, however the suggested fix does not work for me. We're on a HPUX 11 machine. Is there another way to solve this problem? As I understand it, if /dev/null is being used as the $0 argument to the handler, perhaps I could somehow explicitly set it to another (empty) file? How would I go about that? Does anyone have any suggestions? Thanks, Matt
Re: /dev/null problems
On 28 Mar 2001 21:33:51 +0100, G.W. Haywood wrote: Hi there, Have you checked to make sure that your /dev/null is really broken? My feeling is that this is unlikely. The symptom might indicate that something is not configured correctly but there's no information to work with. As Kee wrote in the thread, removing /dev/null and re-creating it worked for me. I did check /dev/null before I fixed it -- it did seem to have the right major/minor numbers.
RE: /dev/null problems
On 28 Mar 2001 12:42:46 -0800, Rob Bloodgood wrote: According to the sample: syntax error at /dev/null line 1, near "line arguments:" Execution of /dev/null aborted due to compilation errors. parse: Undefined error: 0 Which says to me that one of your (scripts/server-parsed pages/modules) has the string "line arguments:" in it, and there is a syntax error near there. That "line arguments:" string will throw you off -- each time I tried restarting the server I'd see different junk in it's place (debug messages from various daemons mostly). It was almost as if /dev/null had decided to be a FIFO for some reason.
Re: ASP / Apache
I've used Apache::ASP and it worked quite well for me. With Apache::ASP (as for other mod_perl based frameworks) you should interface with your favourite relational database using the DBI (via. Apache::DBI is best). There are DBI drivers for MySQL. I don't know about SQLServer -- for that you could use the ODBC driver. See http://dbi.symbolstone.org/ for DBI. Also checkout HTML::Mason http://www.masonhq.com (my favourite) and EmbPerl http://perl.apache.org/embperl/ Matthew On 27 Mar 2001 09:41:29 +, Samuel Lellouche wrote: I'm planning on porting a website w/ ASP pages, from an IIS server, to an Apache Server... Does Apache::ASP work well ? Does Anyone have good experiences whit it ? Does Apache::ASP interacts with SQLServer or MySql ? Thanx alot for any informations...
Re: mod_perl advocacy project resurrection
"Bruce W. Hoylman" wrote: "Matthew" == Matthew Kennedy [EMAIL PROTECTED] writes: snip Matthew compiled enterprise app might only be 300Kb (and not just a Matthew "report queue manager"). And 500Mb of memory? That's Matthew tuppence in the server world anyway. This happens to be minimum numbers for working with a particular Application Server marketed by a well-known database vendor by the name of Oracle Corp. ;-) Could someone actually be using Oracle's Application Server! Matthew I think it's exciting to think what an n-tier framework in Matthew Perl might look like. IMHO, it should be more than just the Matthew outgrowth of CPAN's contents. I agree, but I should be able to expand and contract this middle tier monster in a very similiar fashion. Hey, I want some functionality, get it, configure it, install use it, derive from it, whatever. On the other hand, if I don't want, I can wipe it out without horking up the entire system. I agree with this. A pluggable architecture is nice. Incidentally, that's what the J2EE platform offers as well. For instance; I don't have to use JavaMail with EJB, or the Java Messaging System with EJB, or even JDBC with EJB either etc. Those modules would not necessarily have to be loaded into a JVM in order for me to use the rest of the framework. Sounds to me that this would not be too hard to do in a Perl context either. I think in general the work gone into J2EE's specification and rationale might be an excellent requirements model for a Perl n-tier equivalent. snip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
brian moseley wrote: On Wed, 6 Dec 2000, Gunther Birznieks wrote: Has anyone written a Perl IDE in Perl? i goofed around with a class browser/code generator a while back, but i lost interest. as i recall, #perl laughed at me when i suggested it :) ActiveState has built an Perl/Python IDE out of Mozilla: http://www.activestate.com/Products/Komodo/index.html -- Matthew Kennedy Opus Healthcare Solutions, Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
"Bruce W. Hoylman" wrote: snip In my experience, these so-called enterprise solutions are just that ... a huge lathe, or whatever an end mill is. Their solution to even the most minute problem is to throw huge - I mean huge - application piece parts at it, hoping to bury it in the wizard technology of the moment. There is no other solution. You get it all or you get none of it. Or if you only want a part of the bulk, you still must sift through a mountain of installed crap. "What do you mean I need 1GB of disk and 500 MB of memory just to get an internet-enabled report queue manager?" I don't know where you got the 1GB disk requirement from? Even Weblogic's download is only 43Mb, jBoss' is about 6Mb. The Java Platform is somewhere between that. Your compiled enterprise app might only be 300Kb (and not just a "report queue manager"). And 500Mb of memory? That's tuppence in the server world anyway. J2EE is such a joy to work with in these class of problems which require a middle tier. The APIs are clearly defined and standardized, every object has a consitent feel, low level issues such as socket communications and threading is handled for you. It leaves the developer free to actually code toward the solution. Now maybe some feel better with a large enterprise application server or whatever staring over one's shoulder, but I prefer to build my solution in a way that I get only what I need. The rest can be called upon, If you think you can hack out a solution for those class of problems from CPAN, then good for you. I'm sure you can in some cases. I think mod_perl has done an excellent job of conquering the the two-teir web-based problems. I love tools such as Mason and Apache::ASP which ride on mod_perl. Perl-DBI is an excellent advancement for Perl in general also. I think it's exciting to think what an n-tier framework in Perl might look like. IMHO, it should be more than just the outgrowth of CPAN's contents. snip An enterprise-size solution is rarely a viable answer to an enterprise-size problem. Sounds almost like you're talking about "enterprise" being a "company"? I know you can't be though... right? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Ged Haywood wrote: Hi there, This isn't a silly question. At least I hope it isn't. On Wed, 6 Dec 2000, Jeffrey W. Baker wrote: [snip,snip] A modifies a row in X and adds a row to Y. A commits X, which succeeds. A commits Y, which fails. The only thing that Machine A can do now is send an email to the DBA "..." says the DBA, Given that it's designed to fail sooner or later, are there good reasons why someone would put together a system in that way? There's probably no reason one would _design_ a system like that per se. However there are plenty of times it just _turns_out_ like that -- usually as the result of a system evolving through time. Another example might be the B2B case of consulting your own DB etc. and then communicating some change based on that to another organization's DB system. I've seen that particular situation arrise many times. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
"Thomas J. Mather" wrote: On Tue, 5 Dec 2000, Michael Nachbaur wrote: I don't know what I'm getting at here, but I see that Perl is half a step behind Java in many ways, except for the performance issues (which perl is leagues ahead). For my company, we're probably going Java, but it sorta makes sense for us (we need an enterprise solution now...not when the Perl community gets around to it). Server side performance of Java shouldn't be an issue for you. How exactly does Java provide a better "enterprise solution" than Perl? And how can the Perl community better provide an "enterprise solution"? I've worked with both (Java 2 EE and tools like Apache::ASP/Mason). What people want out of an "enterprise solution" is a middle tier which is not tied into the presentation. When you free your process decisions from the presentation in that way, you can implement a B2B type transactions much more easily. The rationale for J2EE is already defined quite well in this way. snip I guess what I'm getting at is that I hear a lot of marketing hype about Java being a better "enterprise solution", but I'm curious as to what are the purely technical reasons for using Java over Perl. What exactly can you do in Java that you can't do as easily in Perl? Transaction support for your business logic is easy in J2EE. It's not clear how you do this in Perl? By CORBA ORBs and TMs I suspect, but there's no real standard framework for that in Perl. There are other lesser advantages too... standardized XML support is one of them (topical for me right now). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl advocacy project resurrection
Perrin Harkins wrote: On Tue, 5 Dec 2000, Matthew Kennedy wrote: I've worked with both (Java 2 EE and tools like Apache::ASP/Mason). What people want out of an "enterprise solution" is a middle tier which is not tied into the presentation. When you free your process decisions from the presentation in that way, you can implement a B2B type transactions much more easily. The rationale for J2EE is already defined quite well in this way. Mr. Mather's Apache::PageKit module does a good job of implementing the model/view/controller paradigm in mod_perl. I will check that out. Transaction support for your business logic is easy in J2EE. It's not clear how you do this in Perl? Use an RDBMS. You don't understand that it can have nothing to do with a RDBMS. I'm not talking about transaction control within the context of a database within a RDBMS. As I wrote to another user on this list, say you have two database servers and you need to implement a process which operates on each database in order. Maybe you move an item from on to the other. What if the second operation fails? Natually you want to roll-back to before the operation on the first. That's what J2EE transactions are about. See how RDMBS transactions are a different deal in this situation? - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
