|
Re: When to use Java?
by ajt (Prior) on Nov 19, 2002 at 13:03 UTC
|
There are times when Perl isn't the best solution, and there are times when it is...
In the case you mentioned you are comparing apples with zebras. The Perl application is probably running as a CGI application, so the server forks of Perl each time, which is very slow to do. The Java application has been pre-loaded and compiled, so when it's called it doesn't have to grind away starting Java and compiling away like the Perl code does.
The comparison is not fair. To make it fair run the Perl code under mod_Perl or similar (e.g. FastCGI), or force the Java code to run through CGI. Java may still be faster, but you never know until you do a fair comparison.
A few extra links:
Hope this helps...
* update
--
ajt
| [reply] |
Re: When to use Java?
by UnderMine (Friar) on Nov 19, 2002 at 13:07 UTC
|
Other things to look at are :-
A. Apache::DBI in order to have persistant connections.
B. Binding variables to place holders.
C. mod_perl
D. correct DBD driver ie use DBD::Oracle not DBD::ODBC to the Microsoft Oracle driver. (This one is a classic as MS screwed the Oracle driver for their own reasons)
A Code sample would allow us to see if there were any mistakes that were causing CPU spin etc
Hope this Helps
UnderMine | [reply] |
Re: When to use Java?
by rdfield (Priest) on Nov 19, 2002 at 12:53 UTC
|
You might want to read the Guide. There is no need to start up a Perl interpreter for each request, use mod_perl instead.rdfield | [reply] |
Re: When to use Java?
by PodMaster (Abbot) on Nov 19, 2002 at 13:10 UTC
|
Most folks guessed you were talking about a CGI enviroment, but I refuse to make such an assumption, so i ask you, is that the case?
You say applet, so you're comparing a java applet to a perl/cgi program?
(comparing clientside=java, to serverside=perl)
Please clairfy.
____________________________________________________
** The Third rule of perl club is a statement of fact: pod is sexy. | [reply] |
|
|
Well, the assumption was correct. We are using CGI. But the problem is we use iPlanet webserver and I'm told mod_Perl is only supported on Apache. And I'm not sure about it being an applet, it is serverside Java so I guess its not.
bW
| [reply] |
|
|
The problem here is not with Perl but with CGI. Your situation is comparing CGI to Servlets/JSP and the differences between the two mean that Servlets will normally win on performance.
Mod_perl is for apache so yes, you won't get it to run on IPlanet. However, I think it is a little harsh to consider re-writing the whole app. Have you considered writing a middleware server that abstracts all your database code?
That way you can keep a large majority of your existing database code (plus abstract your database from your view) and then just re-write your view?
I've used this approach with great success here but, peversely, in reverse with a Java backend and Perl frontend.
Just my 2p :)
| [reply] |
|
|
If you are using iPlanet on a Windows box then PerlEx may solve your problem with no recoding.. worth a look at least.
Hope it helps
UnderMine
| [reply] |
|
|
You might also want to take a look at CGI::Fast, PPerl and PersistentPerl - three alternatives to mod_perl for solving initialisation time issues.
(mod_perl solves other problems too, but not relevant here :-)
| [reply] |
|
|
I work with bW......we are using java servlets on Iplanet.
---------------------------
In closing, Screw Flanders.
| [reply] |
Re: When to use Java?
by Nitrox (Chaplain) on Nov 19, 2002 at 13:21 UTC
|
I read some place (and it became my mantra) that the best way to *really* learn Perl was to use it in everything you do, even when another language might be a better/easier fit. :-)
-Nitrox | [reply] |
|
|
My only exception is to use Flash when neccessary for a web client user interface. Client side Perl support is not too good but generally there is no real need for Java these days with Flash being so well supported and firewalls stripping Java and ActiveX.
Hope it helps
UnderMine
| [reply] |
|
|
...only exception is to use Flash when neccessary...
The response to which is, It is never necessary to use Flash.
(a) Flash is not that well supported, and
(b) proxies are as likely, if not more so, to strip out Flash as to strip out Java or ActiveX.
Of course, it's not really "never". If you're developing for an intranet, and you can count on all your clients having Flash properly installed, and the proxies not stripping it, then fine; use Flash. Otherwise -- well, disregard usability issues at your own risk.
Flash is NOT web. Web is not Flash. </rant>
jdporter
...porque es dificil estar guapo y blanco.
| [reply]
[d/l] |
|
|
|
|
