Posts Tagged Web Page

FastCGI advantage and disadvantage

FastCGI advantage:

Application Lifetime Is Detached from Web Pages

One major shortcoming of PHP and alikes is that the developer is forced to think in web pages: The application starts when a web page is requested, and it terminates as soon as the web page has been delivered. But you don’t really want to design applications around the user interface; the focus of the design should be on the task the application is supposed to do.

Having a permanently running process makes it easier for the developer to design the application in a more structured way, because he has a clear separation between the program doing the actual work and the mark-up of the results of that work.

But the most important advantage, gained by FastCGI programs outliving the web page, is a different one: You don’t lose your context. The application does not need to read its configuration file again and again, it doesn’t have to open a connection to the database every time a request comes in, and it certainly doesn’t need to pass a myriad of different variables from page to page just because all variables are gone by the time the user requests the next page. One can implement efficient caching, share results between requests, etc.

Scalability

FastCGI applications scale easily. One could have several separate machines running the application, using the web server to balance the load between these machines. With the patch available at [Armbruster], the web server will even ensure that subsequent requests from the same user are handed over to the same FastCGI instance every time, which makes life a lot easier if the application needs some user context that would otherwise have to be shared among all running instances.

Alternatively, one might choose not to rely on the web server for the load balancing, but to build a small dispatcher application instead. Such a dispatcher would accept all incoming requests from the web server and forward them to the actual applications according to some clever algorithm. The possibilities are endless. Because the application is inherently capable of communicating over the network, it is easy to distribute the load between multiple servers.

Caching

Caching is about the most powerful tool to increase the performance of a web-based application. With FastCGI, all incoming requests will go through the same process, so you can cache much more efficiently than you could in CGI or PHP applications. In fact, in those latter architectures, you can hardly cache at all, because the applications terminate after each request. If a request dispatcher as described in the section called “Scalability”is deployed, it could be used to cache entire requests, too.

FastCGI disadvantage:

  • Because the application won’t terminate after each request, memory leaks are a great threat to the application’s stability.
  • Since FastCGI applications do usually multiplex numerous requests at the same time, bugs have severe consequences: If a FastCGI application crashes because of a bug, it will take all other requests down with it, rather than just the request it was processing when the error occurred.
  • The FastCGI interface is way more complex than solutions like PHP. Learning how to write multiplexing FastCGI applications will take some time. We feel that this investment of time pays off rather quickly, but sometimes other people tend to see this differently.

Source: http://www.nongnu.org/fastcgi/

, , , , , , , , , , , , , , ,

No Comments

Testing IE with firefox plugin

Here’s a great plugin for testing IE. This is a great tool for web developers, since you can easily see how your web page displayed in IE with just one click and then switch back to Firefox.

,

No Comments