Peter Beckman wrote:
Given the same resources, we'd probably both rule out PHP as the ideal solution for a FastAGI implementation. It is, IMO, still a legit option.
Well, I suppose if it comes down to a semantic question - that is, whether PHP belongs to a certain club of things which might be deemed "legit" for this purpose - it's difficult for me to persuasively ascribe any meaningful poverty to it as an implementational choice. I don't know that anything can be ruled out as certifiably "non-legit," and certainly, if it's a resource consumption and processing overhead question, there is no shortage of similar scepticism with which Perl and Java (especially) could be viewed. Obviously, back when we were twiddling bits to save memory in C, running a monstrosity like the JVM was out of question, yet today many things telecom are powered by it, and indeed, the computational resources are there. I think the fundamentals are agreed upon, and to the extent that the matter of PHP is open, it mostly comes down to a sort of intangible software engineering heuristic that - although it holds great weight - is difficult to justify in purely functional terms, at least for anything less than very large values of n. :-) I abdicate the question with a parting thought: Why is it that more high-capacity, commercial-grade stuff (of the standalone, not web front-end variety) isn't written in PHP? Why doesn't someone like Metaswitch or Broadsoft implement internals in PHP? To some extent, the answer is accounted for by the stubbornness of large-corporate fashions and entrenched interests surrounding certain technology stacks, as we well know, but I don't think that's the whole explanation. It's not like these guys didn't get the memo on PHP or something.
Good to know; I had not considered the soft reload angle. Thanks!
No problem! Just be sure that if your FastAGI is using HTTP API calls to your backend that you are able to manage DB changes gracefully. Having an existing call make a call to an internal backend API that now requires an additional variable will fail unless that case is handled. This is one of the reasons the FastAGI does not talk to the DB directly, but through HTTP API calls that are handled quickly by PHP.
That's a smart setup. And, PHP is a fine language to use for an HTTP and/or RESTful API dispatcher. :) -- Alex -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (678) 237-1775