[newbie] PHP vs. long-running script; AJAX relative rarity

@littlebigmanJun 14.2009

Hello,

I have a couple of newbie questions about writing web apps with LAMP servers:

Why write scripts in PHP instead of long-running processes? For heavily loaded servers, it would seem a better idea to keep the application in RAM with open connections to MySQL + global variables, instead of reloading PHP pages every time + reopening connections to the database + keeping variables in eg. MemCacheD

Why are there still so many sites where links reload the whole page instead of just using AJAX to update just the one section in the page that needs to be refreshed? Is this due to browser incompatibilities or security reasons maybe?

Thank you.

to post a comment

Full-stack Developer

6 Comments(s) _↴

@svidgenJun 14.2009 — #PHP is generally installed as an Apache module, which avoids a great deal of overhead. And with effective caching on multiple levels (file caching on both the OS and Apache level, and opcode caching on the PHP(ish?) level), your application effectively [B]is[/B] a stay-in-memory application as you describe it (effectively a daemon). PHP also allows persistence database connections because of this: [B]mysql_pconnect()[/B]. Though, folks generally advise against using persistence connections.

Because of the manner in which web sites and applications tend to work, it makes more sense to [B]think[/B] of requests in terms of pages or requests, which PHP allows you to do with ease, rather than as a daemon. If you need to expand your application to run across multiple application and database servers, having an application built on Apache and PHP will be much easier to expand with, since you'll be coding to handle a single request at a time. If you write a daemon/service, your code [I]may[/I] need to be drastically altered to be aware of its siblings, especially if you're thinking in terms of a stateful web application.

And of course, the mere thought of writing your own fully-featured HTTP server [I]in addition to your application logic[/I] is [B]usually[/B] downright silly! Apache and PHP are developed and maintained by [B]legions[/B] of folks, which tends to result in efficient, stable, flexible, feature rich, and portable code. Unless I was [I]absolutely sure[/I] that my application was impossible to write on top of Apache and PHP (or some other Apache module) or that I would be getting an [B]enormous[/B] efficiency boost from writing my own daemon, I would always build my web apps on top of Apache and PHP/mod_perl/etc..

Also bear in mind, you will likely be writing your daemon to run on one particular environment. If you ever find a reason to switch to another flavor of *nix or an entirely different kernel, you'll probably have to rewrite portions of your daemon/app. On the other hand, your PHP application will probably be portable to any system that can run PHP (which is pretty much any system).

... That help?

@svidgenJun 14.2009 — #Oh ... and in terms of your second question, there are three big reasons. For one, some sites don't need to function like applications. They're just a collection of pages, and are therefor more easily coded as such. Secondly, there are still some folks out there who refuse to enable JavaScript, which means they will not be able to view your site's content. And thirdly, AJAX is search engine [U]un[/U]friendly. People probably won't see your in their search results.

The biggest issue is really the last one. If you want your site to be [B]visited[/B], you want to think in terms of pages for the content-rich portions. It makes them indexable, which allows them to be [B]found[/B].

Make sense?

@littlebigmanauthorJun 15.2009 — #Thanks Jon for the feedback.

As for question #1: So there are no performance drawbacks to the page-based PHP architecture vs. daemons, whether it's having to re-read variables or re-establishing connections to the database?

As for question #2: I didn't understand what you meant about AJAX being search-engine unfriendly. Could you explain this?

Thank you.

@svidgenJun 15.2009 — #[B]1.[/B] I probably wouldn't go as far as saying there is [B]no[/B] overhead. However, with effective caching, that overhead is negligible for most sites. Even if you were to be able to show a noticeable difference in efficiency, it's not worth your time to develop a daemon of your own unless your looking at drastically cutting server expenses. And unless you have some really special needs for your application, you'll probably spend more developing a quality HTTP daemon than you will paying a few % more for servers.

I think the only time I could justify writing my own daemon would be if I needed nearly-real time AJAX communcations among a plethora of HTTP clients. And even then, keeping your PHP scripts small and to-the-point within a properly configured Apache environment (with opcode caching) is probably good enough.

[B]2.[/B] Anything that's loaded asynchronously, whether it be via JavaScript or iFrame, is [generally] not visible to spiders/crawlers. So, those portions of a web page are effectively non-existent as far as Google/Yahoo/etc. are concerned.

@littlebigmanauthorJun 16.2009 — #Even if you were to be able to show a noticeable difference in efficiency, it's not worth your time to develop a daemon of your own unless your looking at drastically cutting server expenses.[/quote]

Actually, what I had in mind, is using Python-based frameworks like TurboGear or Django, which seem to make it very easy to write web daemons as alternatives to CGI tools like PHP.

I'd be curious to read about attempts to write the same app in PHP and daemons, and see how they perform.

Anything that's loaded asynchronously, whether it be via JavaScript or iFrame, is [generally] not visible to spiders/crawlers. So, those portions of a web page are effectively non-existent as far as Google/Yahoo/etc. are concerned.[/QUOTE]

In my case, because it's some kind of Facebook social site, so it doesn't matter if just the homepage is indexed in search engines.

Thank you.

@svidgenJun 16.2009 — #... as alternatives to CGI tools like PHP.[/QUOTE]
As I stated before, PHP is typically installed as a module, meaning [B]it's not CGI[/B]: it's integrated with the web server. You'd be hard-pressed to find anyone out there using CGI with PHP.

Don't forget to install an opcode caching module when you need that performance boost though: With APC (Alternative PHP Cache) installed on svidgen.com, there's effectively no difference in load time between PHP and static files serving the same content. In this case, both would be cached after the initial load. The benchmark just shows that the amount of time required for actually [I]executing[/I] the PHP opcodes is not only insignificant, but it produces nearly "perfect" results.

Perhaps I'm being naive. I guess I would be interested in seeing how a python daemon (and even a non-apache dependent daemon) performs against serving a request cached by PHP, Apache, [and the OS]. You'd basically be benchmarking the overhead of checking a cache for a hit.

I've got a relatively unused server sitting at the office. [I]If I have time[/I], I'll run some benchmarks on that box and see what happens ...