0

I'm beginning to think PHP contributes to extra milliseconds of waiting time. After all, my website is mostly meant for showing photos and I like to have things work fast and so does google.

I was experimenting with fastCGI extension for apache. I successfully created a program to use with it and the program produces expected output when I load it via a web browser. I also installed signal handlers (sigterm, sigkill, sigabrt) in my program which cause it to exit when they are detected.

Here's the problem

Every time I update code to my program, I cannot seem to terminate just the running program without terminating apache followed by terminating the process ID of the program. This is a problem because if I start making programs on a live server, restarting apache every time will cause inconveniences to website guests as well as to myself.

I read fastCGI is supposed to run the program code once and keep it in memory so that the overhead of starting the program doesn't happen every time. Already, this sounds better than going through the overhead of starting php and interpreting php code which is what is happening now when people access my pages.

Is fastCGI the wrong extension for me at this time? or do I need to configure it in a special way so that I can just kill (force-terminate) only the program being tested and leave apache running? If there's a better known and well-trusted extension, I may go for that instead.

Any ideas are welcome including ideas of what to include in my apache configuration.

So far, this is what is in my apache configuration file as it relates to fastCGI:

FastCgiConfig -autoUpdate

<location />
Options +ExecCGI
SetHandler fastcgi-script
</location>

This allows me to treat everything in the root folder as if it was a script that can be executed which at the moment is ok since I'm using a local-only test server.

Any ideas are welcome.

  • FastCGI makes your application a resident ready application by placing it in memory - Apache's memory. The only way to load an updated version of your application is to restart Apache. Using FastCGI is not for development environments or moving targets. It is designed for stable and static applications that have already gone through the development and testing cycle and fully vetted. It is a good option, however, there is nothing wrong with using PHP as you already had. Develop your code. When you are ready to walk away, then think about FastCGI. – closetnoc Nov 19 '15 at 2:47
1

Use PHP-FPM if you want a faster alternative to mod_php, there's no need to try and roll your own solution.

I read fastCGI is supposed to run the program code once and keep it in memory so that the overhead of starting the program doesn't happen every time

This isn't really something that's specific to FastCGI, PHP from 5.5 onwards comes with a built in opcache that does basically this, so you'll have this behaviour regardless of what you use to serve it. (And for older versions there were third party opcache extensions such as APC.)

Also, in your question for speed you might want to consider nginx instead of Apache.

  • Also worth pointing out that PHP can be cached using caching proxies such as vanish to reduce server-side PHP requests using version-ing or a content delivery network can offer such as solution as well. – Simon Hayter Nov 19 '15 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.