[VoiceOps] Any subscribers from the UK?

[Alex Balashov]

Peter Beckman wrote:

>> There is a considerable body of evidence suggesting that although PHP 
>> does expose a socket API, using it to do sockets is a terrible idea 
>> because it just doesn't perform well at all.  I don't know why anyone 
>> would write a server - FastAGI or otherwise - in PHP.
> 
>  I haven't done any tests to see how well or badly PHP does sockets

I haven't either;  I suppose there are so many points of view from which 
doing a serious server in PHP is considered preposterous and misguided 
that I couldn't find anyone interested in commissioning a study to 
measure the precise degree to which it is so.

My evidence is anecdotal, and for that reason difficult to relate or 
cite.  I see people trying to do this stuff - for the reasons you 
mention - and I see it 1) falling over and 2) becoming untenably complex 
/ impossible to maintain / experiencing internally degenerative motion 
as a codebase.

>> Besides, PHP does not really have the appropriate low-level dimension 
>> for heavyweight or nuanced system calls;  that's not what it was 
>> designed for. Then again, I suppose people make that argument for 
>> Java, too.
> 
>  Untrue: http://us.php.net/manual/en/intro.sockets.php
> 
>  "The socket extension implements a low-level interface to the socket
>  communication functions based on the popular BSD sockets, providing the
>  possibility to act as a socket server as well as a client."

I was talking about PHP's character as a rather abstract, 
application-level runtime environment, not the ability of the 
interpreter-makers to clunkily expose a low-level system call API 
somehow.  That's done in a lot of languages.

>  PHP is more versatile than many people think.  It's not as deep zen as
>  Perl can be, and there are some frustrating inconsistencies in how PHP
>  operates, but it can be powerful in a knowledgable programmer's hands.

The same can be said of almost any language and runtime environment;  it 
is possible to implement almost anything in a language that has a 
sufficiently broad library, and it is possible to follow better or worse 
architectural and programming practices in ColdFusion and Bash, too.

I do not know that the capabilities technically present in the runtime 
interpreter - which are dictated to a fairly large extent by a 
combination of user demands and the developers' own sense of creativity 
- are really a reflection of PHP's "versatility" paradigmatically.  As I 
said, you can write a VM hypervisor in it if the right system calls and 
API hooks were just available.  I think I once read an article about 
someone that stringed a primitive SSH server out of components all 
defined and invoked inline from a Bash script;  are you moved to say 
that the fact that it can be done is a testament to Bash's immense power 
and versatility in the right hands?

It's a fair statement in that context, to be sure, but is it versatile 
in the sort of way that leads to a viable recommendation as an 
implementational language for an SSH server?  Perhaps the example is 
incommensurable because Bash certainly doesn't make it easier or more 
terse to implement one than in a language like Perl or PHP, but even if 
it did, by code volume, through various improvements to the 
interpreter's capabilities (much as in PHP):  Is that trait the defining 
one, the only thing holding you back from saying, "Let's write our SSH 
server in PHP?"

>  I think that maybe PHP has improved since you last used it (or so it
>  seems).  Again, I'm sure there are better ways, but using PHP for FastAGI
>  is not as bad as you make it seem.  Then again, I'm not doing 1,200,000
>  minutes per day.

I don't know how bad I'm making it seem.  I am not suggesting that it is 
outside the realm of feasibility, especially from a basically functional 
perspective.

>> It's a qualitative issue -- "just because you can, doesn't mean you 
>> should."
> 
>  Maybe, but if you are a small mom-and-pop and just need it to work,
>  reusing already written code for both your web and VoIP applications makes
>  a lot of sense.  And if they do it right, by using a PHP-based FastAGI vs
>  straight AGI(), it can scale fairly well.

It's a fair economic point, although personally, to me, that just says 
that the business logic that is shared between web and VoIP needs to 
reside in a common place that still allows the right approaches to be 
taken on both sides and can be called.  Stored procedures, triggers and 
the like are a common candidate for this in my work;  a database call 
can both figure out which rate center destination a call should be 
routed to from the call router, and calculate that rate center and cost 
dynamically for various UI functionality, for example.  Or, if the 
technical argument is there - stemming from the complexity and real-time 
character of the data needed to make the decisions - perhaps even a real 
middleware layer of some sort.

Seems to me that the code reuse argument goes so far.  Saying that using 
the same technology on both sides of a very large abstraction and 
performance domain divide is the most efficient way to lever existing 
code fails to take into account that maybe you just shouldn't have done 
the business layer in PHP either, or otherwise have put the code in the 
wrong place.

What *are* business layers for something like an ITSP call processing 
platform doing in PHP, anyway  PHP is largely a presentation language. 
To reiterate in the most emphatic terms, that is not a description of 
the capabilities of its (phenomenally large) API - as far as I can tell 
there is little that PHP doesn't technically "have" - but rather a 
judgment about the "sort of thing that it is" or was intended to be, a 
genus.

Bash was intended to be a shell and to provide a scripting environment 
for simple batching of the sort of stuff you'd often do in a shell 
(complete with very rudimentary flow control and data primitives), even 
though you could certainly augment its, er, versatility by hacking in 
more plumbing to the outside (system) world.

Was PHP designed to be a language for standalone scripts and processes? 
  Does much of the work that goes on in PHP exist to further that 
particular aim?  It's pretty convincing from a cursory survey of the way 
PHP is progressing that it is - and always has been - about the web.  It 
seems to me that its use for standalone scripts really is an accident of 
someone deciding it would be nifty to let people run the interpreter 
from the CLI, which I guess is formally required anyway in order to 
allow PHP to run in a CGI-style way (not with mod_php) if that is desired.

>> It is within the realm of conception that you could write a virtual 
>> machine container/hypervisor in PHP, if only the interpreter exposed 
>> the system calls and other primitives you'd need to pull it off.  But 
>> it's not done for a reason--surely you can agree. (Except perhaps for 
>> the novelty/Slashdot factor by someone with far too much time on their 
>> hands.)
> 
>  Given a programmer talented in all languages, absolutely.

It still comes down to the fact that PHP is a very slow layer of 
interpreted fat and high-level abstraction, and furthermore that its 
virtues and strengths - of which there are many - have absolutely zero 
imaginable correlation to the goal of writing a reasonably performing 
hypervisor.  It dimensions well to web applications, not low-level, 
back-end system processes.

We aren't going to agree on this, although I think we largely agree in 
the breadth of the overall context.  The bottom line really comes down 
to what you value in the craft.  The values of the commercial world 
often dictate that you should do something in the simplest and cheapest 
way possible, with no attention paid to the quality, density or 
longevity of the final product nor the erudition that is brought to bear 
on the problem.  To the extent that one shares those values, one can 
PHP-AGI one's way out of this problem, sure.  Actually, with the amount 
of call setups and burst volume objectively required in most 
cottage-industry ITSP operations, you could probably do the whole thing 
in Bash:

    ACCT_ROUTE_VAR=$(echo \
	            "SELECT id, rt FROM rt_tbl WHERE account = $ACCT LIMIT 1" \
                     | mysql -u user --password=blah -D database \
		    | head -n 3 | tail -n 1 | awk -F '|' '{print $2}')

It'll end up on TheDailyWTF.com, but it does work, and will probably 
continue to work for reasonably large "values of n" that the provider 
will experience in the near/foreseeable future.

On the other side, there's considerable value to be reaped in the 
technical excellence of a little overengineering - not excessive, of 
course, there's always a balance to find.  The value is both qualitative 
to those that value the aesthetic dimension of good programmatic 
craftsmanship and economic in that the system can grow to meet your 
needs, including both needs themselves and magnitudes of needs that 
cannot be reasonably anticipated.

If you and I were charged with developing an integrated technology stack 
as a competitor to say, BroadWorks or Metaswitch, and the requirement 
was that it be able to process bursts of, say, 6500 call setups per 
minute, and you used PHP-AGI and I used something that I find to avoid 
the pitfalls of that approach, my implementation would win and yours 
would lose, per given unit of hardware capacity.  That issue is 
completely academic and largely moot because other limitations will be 
encountered long before that becomes a concern, since Asterisk is in 
use.  :-)  Secondly, neither of us is actually building a system that 
has to handle very bulky logic for 100+ CPS--that's considerably more 
than most commercial softswitch gear will reliably do.  But if we were, 
I don't think you'd use PHP.

It is not so much more difficult to use the right tool for the right job 
to begin with;  it's not a night or day issue in terms of capital 
requirements.  Even if you'll never need it, it's nice to know that you 
can rest easy at a lower threshold because you went for the right 
architecture, as opposed to what many of my customers worry about, which 
is that doubling their traffic next year will render their architecture 
completely unusable because it was built with this kind of crap, and is 
already starting to crack.

I don't make my living by selling customers a geostationary satellite 
guidance system when they need a horse--there's plenty of that out 
there, much of it in enterprise-size environments.  I know, I know, 
ITSPs are small companies that have to take the most pragmatic route to 
achieve anything.  But I think that appreciating the long-term benefits 
of good (perhaps even a little excessive) engineering, as opposed to 
just putting out today's fire today, is critical to any field of 
commercial endeavour in technology, regardless.

I realise you don't disagree with me on most of this.  I just think that 
these premises lead to the conclusion that there's no way something like 
PHP can be the ticket, whereas you clearly don't.


>  I like Net::Server::Fork because it allows me to HUP to restart (reload
>  new code) the parent process without touching the child processes, which
>  means I can put new FastAGI code into production without waiting for no
>  calls or worrying about disconnecting existing active calls.  It is also
>  stable and have not had problems with it in years.

Good to know;  I had not considered the soft reload angle.  Thanks!

-- 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