I love C++ more than all the others, but as far as I know fastcgi is
still the only way to avoid having to fork a process, and that's still
Well, there's also the "write a webserver directly into your application" approach. :)
You could also write your application as an Apache module. That gives you a pretty tight coupling into the web server, but it does restrict you to using Apache.
Beyond that, you could build up a framework to maintain and marshal sessions and connections, but at that point you're essentially reinventing FastCGI.
Heh... I feel like yelling 'first post' or something.
Beyond that, you could build up a framework to maintain and marshal
sessions and connections, but at that point you're essentially
Right and it's kindof amazing that at this point there still isn't a standard solution.
I guess java and .net are the solution.
And if you want fast, you have to roll your own and that's how it is.
Why is fastcgi lame but java servlets not lame? The web server passes
the request to the java shit over a socket, just like fastcgi. It's
the same exact concept in that respect.
Concept yet, but (and I'm certainly rusty at my fastcgi) I remember it not being an all encompassing thing, you had to write something depending on what platform you were on.
I forget it was a long time ago, maybe it's not so lame, but it's not as seamless as servlets, which is all I was getting at.
Right and it's kindof amazing that at this point there still isn't a
I guess java and .net are the solution.
What makes them the solution? They still have to talk to a web server.
The only difference is that someone already integrated it for you. By that standard, PHP "is the solution" and so is Python, Ruby on Rails, etc. etc. etc.
Any web application environment needs to either talk to a web server or act as a web server. It's kind of like a Von Neumann bottleneck of web programming.
forking a process to run an interpreter to me seems to be a pretty much worse case scenario.
I don't know how ruby does it, but I'm pretty sure it's integrated like java.
php is a good Language for the purpose, but if you run it as a forked process, I don't think you should be doing that in anything but a test program.
Same thing with perl, if you run modperl and whatever the php equivalent must be it's far less worse, but you're still interpreting. I'm guessing modperl persists its compiles? Okay, so less worse even. Then it's just that Ihate perl as a language.
Java for it's bytecode suckyness, at least has everything all compiled and ready to go, and nothing gets forked, and once it starts caching classes, in theory it never even has to go to disk.
I do know that I need IIS, a bloated server OS, all sorts of firewalls and locked down policies to run a asp.net application on a web server; conversely, I can run apache and PHP off a live CD in my toaster oven a serve pages.
I have a friend who's a MS weenie, and we got back and forth, he's got every feature and tool and library I do and I've got every feature and tool and library he does.
The difference is, he has to pay up the ying yang for all that software.
The tradeoff: people still pay lots of money for people who do that.
I go where the money is too.
I happen to like unix more than windows, so that's where I go, but really, if I had a problem with tomcat, and he had a problem with IIS we'd be in the same boat.
I *can* find the source and try and fix it, but it's so huge and there's such a learning curve, the reality is that I'm not going to do it, and it might as well be black box.
He can call up support and they Will Fix His Problem.
But again, he has to pay lots of money for that.
So it is not in itself a library, but all you have to do is remove the main function and compile, and it is.
Mo Mär 30 2009 07:56:56 EDT von Ford II <>Of course it depends on the goal, but my preference for writing a web application is simple java servlets and jsps
The reason is a) eclipse makes development so easy, but really because b) that's what servlets are designed for.
I love C++ more than all the others, but as far as I know fastcgi is still the only way to avoid having to fork a process, and that's still kinda lame.
An application server that can take requests and hand them to already running programs (in the sense that java programs run) and maintain a pool of database connections and other resources, to me, that's the way to go.
Of course I hate the performance hit and the over complexity, but the overall picture is better.
I think php is definetly the best of the lot in terms of cgi making, it was designed to be exactly what it is, and except for the few glaring security flaws, it does its thing well.
I don't know a lot about php, maybe there is a daemon mode it runs in or something.
But it has to be compiled or interpreted no? Nothing like run time interpretation to yield speedy web results.
And my long time fallback: is google written in PHP? I did'nt think so.
The fucked up part, is I think large parts of facebook are.
Java and simple in one sentence? That doesn't mix. Most java guys, questioned "Where's your ear?" will wrap their arm around their head and point to the ear on the opposite side of the arm.
Mo Mär 30 2009 10:57:07 EDT von fleeb <>
Perhaps, for what you're describing, if I wanted extreme performance, I'd use C++, code up a module for apache (presuming the use of an apache server), and have a virtual folder that refers to the module's bits to perform database queries and such.
Setup for such a thing would be fun.
Apache and performance in one sentence? doesn't mix well again.
theres nginx or lighty or lighthttpd, if it should be fuckin' fast use one of them.
Me started using nginx.
ah, and the prefered connection from the webserver-frontend to the backend nowadays _IS_ fastcgi. Ruby or Python frameworks do so. And there also is a better php cgi frontend than the upstream one.
the webserver itself musn't use much memory on many simultaneous connections, so all the calls waiting for gifs and stuff to be read from disk clog up your resources.
NOT tying the application into the webserver frontend has the advantage, that you don't get problems with waiting for your application logic while you should be barfing out files; which would bring in the need to fork/thread the webserver so it could cope applications without blocking file i/o for static content (which for example is one of the last performace problems of webcit). The modern aproaches go with one task, no (or not many) threads and select(). They have real little connection resource overhead (nginx can handle 2000 idle sessions [almos every connection will be idle somewhen in its life cycle] with around one meg of ram usage)
go and figure how to do a thousand simultaneous connections with apache; who uses ~30-50 Megs per child depending on the amount of modules you plug into it...
triple M still has writing a fastcgi frontendmodule into webcit, so nginx integration can be better...
go and figure how to do a thousand simultaneous connections with apache;who
uses ~30-50 Megs per child depending on the amount of modules you plug into
isn't that a little unfair? Apache is threaded now. The per-child metric doesn't matter so much anymore.