>>>>> "X" == Xiangzhou Wang <[EMAIL PROTECTED]> writes:
X> Can anyone tell me the advantages to use servlet instead of
X> FastCGI for performance issue with Apache+Jserv. Someone said
X> they both have heavy-weigh context switch.
Servlets are an initial memory footprint hit to allocate the JVM and
heapspace; FastCGI is similar in that (I believe) it avoids the
multiple invocations of Perl you get with normal CGI. Since both Perl
and Java are about the same size of engine (more or less), before you
get any visitors, the two methods are about equal.
Once traffic arrives, FastCGI spawns new, independent application
spaces for each and every invocation whereas Servlets are
multithreaded, can share objects between sessions, and need only
expand to accomodate the current heapspace demands of the session
context. For large, complex or high-traffic problems, Servlets are
much less strain on your system.
Servlets are written in a type-safe, network-oriented language (java)
amiable to profiling, debuggers and well-understood CASE
methodologies. Servlets make socket calls, database connections,
network computing and similar tasks a breeze. You can still write bad
code in Java, and you can get very clever in Perl, but IMHO it is
easier to do more thorough quality assurance in Java.
Servlets are pre-compiled to JVM bytestreams whereas Perl is
interpreted a-fresh each time. In the BellLabs tests, Servlets are
generally magnitude faster than Perl and only slightly behind C. Java
falls down on only two counts, and both can be avoided. First, the
Java 1.1 collections classes are not multithreaded, so heavy use of
Hashtable put() calls can serialization threads --- in my practice,
this has not been an issue, and if it were to rear its head, the
problem is avoided by using the 1.2 synchronized collections. Second,
string manipulation in Perl is highly optimized and beats Java flat
out unless you take special care to avoid "string = string + string"
constructs; since many simpler web applications are just string
manipulations, Perl is very often a good choice. For Java, "String"
ops are just too object intensive. In the JVM, one of the most
expensive operations is object creation, so you need to take care to
either pool objects, or to avoid create unneccessary instances.
I'm certain Perl people are going to flame me. Truth is, because most
ISPs don't allow servlets, I use a lot of Perl in my websites. For
the right tasks, Perl is also more elegant, and is much more
economical to develop prototypes and small apps, but that does not
mean either Perl or Java is a panacea. Anyone who won't look at one
method because they defend-to-the-death the other is dangerous and
should be relieved of duty as soon as possible.
My approach to the quality assurance problem is to use strict OOPerl
but this is still a voluntary thing and still leads to problems where
the Perl idiom forces me to do things which are considered bad OOP
practices, or where the ease of fiddling with Perl seduces me into
making extraneous changes that depart from the design specs. This is
largely my own fault, but I find Java forces me to think more before I
start coding, and I have seen a lot of Perl code where thought came
much, much later..
--
Gary Lawrence Murphy <[EMAIL PROTECTED]> TeleDynamics Communications Inc
Business Telecom Services : Internet Consulting : http://www.teledyn.com
Linux/GNU Education Group: http://www.egroups.com/group/linux-education/
"You don't play what you know; you play what you hear." -- (Miles Davis)
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
READ THE FAQ!!!! <http://java.apache.org/faq/>
Archives and Other: <http://java.apache.org/main/mail.html/>
Problems?: [EMAIL PROTECTED]
