I have the source for Resin sitting right here, theres no Pike.
I said resin's core server (since you mentioned the speed at which static files were served) which is roxen, no? I could be wrong.
Further, CGI is usually done in C++ because it's the best faciliator for CGI. To do CGI in java is beyond foolish,
That makes no sense. You can write a cgi program in any language you want (typically perl, not C or C++, not by a long shot) and the only reason people dont use Java for cgi is because java is so god awful slow to launch.
CGI is perfectly adequate for 99.99% of all sites out there and is often the only option people are given.
nor have I ever even heard of such a thing.
Yeah, so? I have. Maybe you weren't paying attention to what was happening 3 or 4 years ago.
Servlets are lightweight processes and don't have any of the processing overhead that a CGI script entails.
Yes, servelets run in the web server's process space, eliminating the startup time required for a cgi app. If the running time for that servelet is longer than the startup and run time of the cgi, then it would clearly be slower, not faster.
Sure, if all you're doing is marshalling some data off a web form for the sql backend, a cgi wouldnt look very good in a benchmark. If you're translating text or processing pixels, or crunching numbers, or any number of things, a cgi written in C could _easily_ outrun a java servelet. Can you at least see that?
Go look at the benchmarks if you want further proof.
I just told you that it is unfair to compare a cgi app with a server embedded language. If you write your app in C and have it communicate using fastCGI (which does not require a process launching) then your servelet engine will be blown out of the water. Completely fucking decimated. Furthermore, I can write any number of cgi apps that will outperform a servelet because (a) there exists many classes of problems for which java would be significantly slower and (b) fast process times (fork() on modern unicies is as fast as thread creation on windows) coupled with this modern technology called a unified vm and file buffer cache.
You, on the other hand, are claiming that servelets are faster because they arent ancient technology. Religion is a fine thing but it has no place in computer science.
CGI is ancient technology, and hardly anyone uses them anymore for non-trivial things, much less intensive backend processing.
Completely untrue. Most, by far, programs that execute on a web server out there are cgi programs.
Easily done. Do you mean launching new threads in a non-server app (this is trivial) or new instances of JVM running entirely separate programs?
That can be done, and rather quickly, but you don't see that a whole lot.
Excuse me but what doesnt get done a whole lot?
I dont care about web servers, I'm not interested in writing an application server that keeps a single instance of a JVM in state, and even if I had the money to buy one, none has been written for my needs. Ergo, every time my non web app needs to do some java logic, I have to launch the JVM. Ergo, Java is slow in my backroom.
The only way you're going to speed up java in my back room is if you integrate in into one monstrous application framework that attempts to the work of an OS: works around process launches, commits an additional level of memory management for its jit, keeps a pool of open reuseable sockets, etc.
Duh. You can do that with any language. And if you did, you'd find java was the slowest of the bunch.
That's because Java, THE LANGUAGE, is slow.
In the case of linux, JDK1.3 launches threads as a new process
That's nice but it's not relevant since I need to launch a new JVM.
(indeed, doing a top will show an entry for each individual thread..disconcerting until you realize its supposed to be that way)
Is it, or is it Linux's braindead Linuxthreads? Not every OS implements threads as processes, you know.
Servlets are faster than CGI. They consume considerably less resources and overhead.
They can be both. They can be neither. This isnt an article of faith, you can easily be shown to be wrong. Dead wrong.
Question for you: Have you ever written a backend processor or server application in general?
Yes, in quite a few languages for many different operating systems.
I dont just mean webserver, but a socket-listening client-server application.
When I was a novice programmer working in a entry level position, sure. Using poll(), select(), threads, passing open file descriptors between processes (one of the faster if underused unix technique -- see Dillon's diablo newsfeeder) and a few other techniques in between. This is elementary shit.
[ Parent ]