Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
My understanding is that creating CGI scripts is a thing of a past, and has deemed inefficient because of the way it forks every time its being called. However I don’t see what the different is considering when you call a web page with php scripts embeded, it still in some way forks to another process, so why is CGI deemed inefficient?
There are two “mainstream” ways around forking for every request:
You can load the interpreter directly into your server’s process space, and prefork a number of set instances during startup. mod_php and mod_python take roughly this tactic.
You can create a persistent process for the interpreter, and then either prefork or spawn threads for each request, communicating with the server over sockets. FastCGI is used this way.
Event-driven servers, while not exactly mainstream, are becoming more common for good reason. They rely on the knowledge that most websites spend most of their time blocking on I/O, just spinning their metaphorical gears. Whenever a request needs to do any I/O, the server is free to start handling another request without starting another thread/process by using select() and friends. This is really the only way to solve the C10k problem.