[VoiceOps] Any subscribers from the UK?

[Peter Beckman]

On Mon, 3 Aug 2009, Alex Balashov wrote:

> Peter Beckman wrote:
>
>>  First off, calling AGI(somescript.php) is awful. 
>
> It is, but most of the broken implementations I am brought in to fix do 
> exactly ... that!  :-)

  I meant to say "I completely agree that ..."

> 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, but
  one of my friends and past coworkers who worked with some Zend folk
  directly (Zeev, the original author of PHP) said that he wrote some pretty
  amazingly fast socket-related tools in PHP.  I don't know how many
  calls-setups-per-second that might translate to, but I think there is the
  possibility that neither of us really knows how best to build a
  socket-based long-running PHP daemon that has the stability and
  performance that we demand.  I suspect it is possible to do at a level
  on-par with other FastAGI implementations in other interpreted (not
  compiled) languages.

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

  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.

> Maybe.  I suppose it's just hard for me to see, as someone with a programming 
> background that almost entirely consists of socket-layer programming and 
> network protocol implementation (in C), how PHP - given its architecture - 
> can do those things in a scalable fashion even if it does bother to publish 
> APIs for the underlying system calls.  Managing large amounts of I/O-bound 
> processing just isn't what it was built for at all.  Even my curl_*() calls 
> out of PHP are dog-slow.

  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.

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

> The real answer lies in robust performance studies and in the details of 
> PHP's runtime implementation.  I have neither of these annals at my ready 
> disposal in order to illustrate that point.  There's just a general principle 
> that high-level, non-typed web languages aren't designed to participate in 
> the same problem domain as general-purpose programming languages and/or 
> languages on which systems are built at that lower level of abstraction.
>
> 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.

> Interesting.  I've tended to use Asterisk::FastAGI in the past, but it never 
> seems to obey my bind port parameter on the initial invocation.

  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.

---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com                                 http://www.angryox.com/
---------------------------------------------------------------------------