Simply using modules does not make mod_perl slower. There is no performance overhead for just loading them. A program that does things will take longer than a program that does nothing, but that's just as true for PHP.
Frankly, if PHP outperformed mod_perl on your system it was probably because of mistakes in the Perl code. Even PHP boosters admit that mod_perl is faster, as in this talk from Yahoo.
PHP is understood by more people, meaning there are more existing projects that you can implement or just borrow code from.
I'd love to know where you got that statistic from. My guess is "nowhere" or "my friends like PHP." PHP is popular within a certain community of designers who became programmers, but I strongly suspect that Perl has a wider base of users if you look at programmers as a whole.
As for your comment about borrowing code, there is really no language out there that has been as successful at sharing code in a resuable way as Perl with its CPAN system. Borrowing PHP code usually means copy, paste, modify. This problem is exacerbated by the fact that PHP seems to make all functions global within a single namespace, so you have no way of knowing if someone else is stepping on your function name.
You consider PHP more maintainable? What about the lack of namespaces for variables and functions? That's a real problem for use in teams. There are other interesting issues raised in this article.
Benchmarks, including ones published by Yahoo, show that mod_perl is typically faster than mod_php. You were probably comparing Perl running as a CGI to PHP running inside the server.
Yahoo decided to support php rather then perl in their next generation yahoo services specificially because of "There is more then one way to do it".
Pretty ironic when you consider that PHP has exactly the same issue, along with some other issues Perl does not have (lack of namespaces, inadequate comparison operators, etc.).
Why would schools put forth all that time, money, and effort into switching over to Linux if all that will happen is the students would be less prepared for the real world?
Because they have no money, and Linux is free. If you look at some of the schools that have switched to Linux (yes, they exist) you'll find some evangelist who wanted to do it, and a bunch of happy people who are now saving lots of money.
Could you imagine if a certain grade school decided, "Hey. I have a good idea! Let's use Linux on all our computers here.". The children learn and get aquainted with Linux then get into Jr. High - Uh oh, now the students from that grade school are way behind.
Have you ever actually used a different OS? If you have, perhaps you've noticed that they are essentially all the same. That's right, all of the important stuff I learned on my Apple II+ still applies to modern Linux and Windows. It's not learning individual applications that matters -- there will always be new applications. What matters is getting enough practice with a computer to be able to figure out how to use a new one when presented with it.
I not the widespread use of Apple systems in our schools does not seem to have cripped students for life.
This is probably not a very popular point of view, but it seems to me that if these groups really had altruistic intentions they would use a license that allows and encourages copying of each other's code, like Public Domain. These restrictive licenses seem awfully stingy. What are they so worried about? That IBM will copy their code? So what if they do? Source code wants to be shared, and restrictive licenses and lawsuits are a long way from sharing.
So, you're criticizing an early release of an application that you admit you've never used because it doesn't look enough like some other application that you have used? That will certainly help give developers lots of incentive for innovation...
In a high-traffic environment, you typically send requests for static files to a separate server or use a reverse proxy setup. There is no point in having more apache processes than you can have database connections, since a process without a connection can't actually handle a request. You tune this with MaxClients and let the OS queue up any requests that go over that. There's nothing wrong with connection pools, but you are overestimating the real need for them, as opposed to just persistent connections.
When writing distributed systems (i.e. many of the current business systems being developed today) you need to use data somewhere it's not stored.
The kind of additional remote layer that is added by this splitting of the business objects into a separate physical tier is very different from a remote database protocol like Oracle OCI in that it's artificial and unnecessary. You can't run an Oracle database in-process, and since it's a shared resource with all the other machines in the cluster, you probably wouldn't want to. On the other hand, you can run the business logic that is being shipped off into an EJB as an in-process object without losing any of the abstraction benefits.
If there was no performance concern, would it make sense to use coarse-grained calls instead of fine-grained ones? I doubt many experienced developers would say yes. Corase-grained calls make things harder to maintain and debug. Martin Fowler has a good discussion of this in his book about enterprise architecture.
I didn't say that there was never any place for remote access protocols, since obviously there is, but I do think that designing web applications in a way that requires remote calls to access the business objects is usually a bad idea.
No, when the user is idle nothing is being tied up. The process goes on to handle another user's request, with the same database connection. The only time a process is idle is when the application is not being fully used. It has nothing to do with what an individual is doing, and everything to do with the total number of requests being sent in at once. And, it has nothing to do with scalability. Scalability is about how many simultaneous requests can be handled in a period of time, not about how the application behaves when half of its processes are sitting there idle.
There's a really handy module called "Fatal" which you can use to make any existing function throw an exception if it returns a false value. For example:
This concept which you refer to "MAXIMUM the application can handle" seems to assume that every single user performs some function simultaneously.
The simultaneous function here is making a request to the web application. Most web apps will need to contact the database somewhere here, and most of the time spent handling the request will be spent talking to the database. If some threads/processes are not being used (and thus not needing a db connection) then the app is not being pushed to it's maximum. In other words, relinquishing a database connection is only a win when you have idle threads/processes, or your app does time-consuming things that don't involve a database connection. You won't have any idle threads if the app is being pushed to the limit of its scalability.
My Perl code uses exceptions extensively. It's not necessary for me to check return codes. I think you are generalizing based on one way to write Perl code.
When one user is idle, if that user holds an open DB connection, that needlessly ties up resources that other users could be using.
Again, we are talking about the MAXIMUM that the application can handle, not whether resources are "wasted" when the application is not being used at full capacity. And we're not talking about users either. Users don't get their own db connections, but server theads/processes do. In an application at maximum load I would not expect there to be idle threads.
Amazon.com and Ticketmaster.com run significant parts of their sites on Perl. It's fast. Slashdot's code is not very elegant. This is not Perl's fault.
I would say that caching search results in the session is a big mistake. First, what if the user opens multiple browser windows? They will get crazy results if they try to run multiple searches and page through them, and this is a fairly common scenario for most sites. I think you'd be much better off using a file-based search results cache with the search criteria as the key (rather than the session ID).
There are plenty of other approaches than MySQL for sharing sessions. I just wanted to point out that MySQL is extremely fast at this sort of thing, and many people underestimate it. Remember, MyISAM tables have no transactions, so you are basically talking to an in-memory multi-threaded daemon over a local Unix domain socket. The overhead is very low.
Again, this is only useful if you have a lot of requests that don't use the database at all. In most web apps, the time spent outside the database is very short.
The amount of load when the application is idle doesn't seem like a terribly important issue. It's the maximum load that the application can handle which is under discussion here.
Even naive J2EE applications I saw would be smart enough to use a view object (containing all twenty business objects and their fields) to come back from the buisness layer in one call.
Doesn't this just illustrate how absurd it is to use RMI for this kind of thing in the first place? It forces you into workarounds likes this, and makes you use ugly coarse-grained interfaces instead of standard OO practices.
Connection pooling only scales better if most of the time in your application is spent doing calculations or something without the database. If your app mostly is about accessing a database, then the connection will be constantly in use and there will be no benefit from pooling.
Slashdot Mirror
Simply using modules does not make mod_perl slower. There is no performance overhead for just loading them. A program that does things will take longer than a program that does nothing, but that's just as true for PHP.
Frankly, if PHP outperformed mod_perl on your system it was probably because of mistakes in the Perl code. Even PHP boosters admit that mod_perl is faster, as in this talk from Yahoo.
I'd love to know where you got that statistic from. My guess is "nowhere" or "my friends like PHP." PHP is popular within a certain community of designers who became programmers, but I strongly suspect that Perl has a wider base of users if you look at programmers as a whole.
As for your comment about borrowing code, there is really no language out there that has been as successful at sharing code in a resuable way as Perl with its CPAN system. Borrowing PHP code usually means copy, paste, modify. This problem is exacerbated by the fact that PHP seems to make all functions global within a single namespace, so you have no way of knowing if someone else is stepping on your function name.
You consider PHP more maintainable? What about the lack of namespaces for variables and functions? That's a real problem for use in teams. There are other interesting issues raised in this article.
Benchmarks, including ones published by Yahoo, show that mod_perl is typically faster than mod_php. You were probably comparing Perl running as a CGI to PHP running inside the server.
Sounds like a personal problem of yours. Perl has nothing to do with it.
You didn't need to switch to PHP; you just needed to learn one of the powerful templating tools for Perl, like Template Toolkit or Mason.
Pretty ironic when you consider that PHP has exactly the same issue, along with some other issues Perl does not have (lack of namespaces, inadequate comparison operators, etc.).
Because they have no money, and Linux is free. If you look at some of the schools that have switched to Linux (yes, they exist) you'll find some evangelist who wanted to do it, and a bunch of happy people who are now saving lots of money.
Could you imagine if a certain grade school decided, "Hey. I have a good idea! Let's use Linux on all our computers here.". The children learn and get aquainted with Linux then get into Jr. High - Uh oh, now the students from that grade school are way behind.
Have you ever actually used a different OS? If you have, perhaps you've noticed that they are essentially all the same. That's right, all of the important stuff I learned on my Apple II+ still applies to modern Linux and Windows. It's not learning individual applications that matters -- there will always be new applications. What matters is getting enough practice with a computer to be able to figure out how to use a new one when presented with it.
I not the widespread use of Apple systems in our schools does not seem to have cripped students for life.
This is probably not a very popular point of view, but it seems to me that if these groups really had altruistic intentions they would use a license that allows and encourages copying of each other's code, like Public Domain. These restrictive licenses seem awfully stingy. What are they so worried about? That IBM will copy their code? So what if they do? Source code wants to be shared, and restrictive licenses and lawsuits are a long way from sharing.
So, you're criticizing an early release of an application that you admit you've never used because it doesn't look enough like some other application that you have used? That will certainly help give developers lots of incentive for innovation...
In a high-traffic environment, you typically send requests for static files to a separate server or use a reverse proxy setup. There is no point in having more apache processes than you can have database connections, since a process without a connection can't actually handle a request. You tune this with MaxClients and let the OS queue up any requests that go over that. There's nothing wrong with connection pools, but you are overestimating the real need for them, as opposed to just persistent connections.
The kind of additional remote layer that is added by this splitting of the business objects into a separate physical tier is very different from a remote database protocol like Oracle OCI in that it's artificial and unnecessary. You can't run an Oracle database in-process, and since it's a shared resource with all the other machines in the cluster, you probably wouldn't want to. On the other hand, you can run the business logic that is being shipped off into an EJB as an in-process object without losing any of the abstraction benefits.
If there was no performance concern, would it make sense to use coarse-grained calls instead of fine-grained ones? I doubt many experienced developers would say yes. Corase-grained calls make things harder to maintain and debug. Martin Fowler has a good discussion of this in his book about enterprise architecture.
I didn't say that there was never any place for remote access protocols, since obviously there is, but I do think that designing web applications in a way that requires remote calls to access the business objects is usually a bad idea.
No, when the user is idle nothing is being tied up. The process goes on to handle another user's request, with the same database connection. The only time a process is idle is when the application is not being fully used. It has nothing to do with what an individual is doing, and everything to do with the total number of requests being sent in at once. And, it has nothing to do with scalability. Scalability is about how many simultaneous requests can be handled in a period of time, not about how the application behaves when half of its processes are sitting there idle.
use Fatal qw(open close);
You're misinformed. I use exceptions with DBI. Just pass it the RaiseError parameter.
The simultaneous function here is making a request to the web application. Most web apps will need to contact the database somewhere here, and most of the time spent handling the request will be spent talking to the database. If some threads/processes are not being used (and thus not needing a db connection) then the app is not being pushed to it's maximum. In other words, relinquishing a database connection is only a win when you have idle threads/processes, or your app does time-consuming things that don't involve a database connection. You won't have any idle threads if the app is being pushed to the limit of its scalability.
My Perl code uses exceptions extensively. It's not necessary for me to check return codes. I think you are generalizing based on one way to write Perl code.
Again, we are talking about the MAXIMUM that the application can handle, not whether resources are "wasted" when the application is not being used at full capacity. And we're not talking about users either. Users don't get their own db connections, but server theads/processes do. In an application at maximum load I would not expect there to be idle threads.
Amazon.com and Ticketmaster.com run significant parts of their sites on Perl. It's fast. Slashdot's code is not very elegant. This is not Perl's fault.
There are plenty of other approaches than MySQL for sharing sessions. I just wanted to point out that MySQL is extremely fast at this sort of thing, and many people underestimate it. Remember, MyISAM tables have no transactions, so you are basically talking to an in-memory multi-threaded daemon over a local Unix domain socket. The overhead is very low.
Again, this is only useful if you have a lot of requests that don't use the database at all. In most web apps, the time spent outside the database is very short.
The amount of load when the application is idle doesn't seem like a terribly important issue. It's the maximum load that the application can handle which is under discussion here.
Doesn't this just illustrate how absurd it is to use RMI for this kind of thing in the first place? It forces you into workarounds likes this, and makes you use ugly coarse-grained interfaces instead of standard OO practices.
Connection pooling only scales better if most of the time in your application is spent doing calculations or something without the database. If your app mostly is about accessing a database, then the connection will be constantly in use and there will be no benefit from pooling.