[VoiceOps] Any subscribers from the UK?

[Hiers, David]

From what I recall, the likes of Google, E-Bay, MSN, etc have all gone through several major architecture and implementation phases.  Not knowing what they did not know, they built something that was thought to be adequate for the known requirements, and ran it until they started to see smoke.  Then they re-built using the lessons learned, and started the whole iterative cycle over again.  

Google alone has gone through, what, three different file systems already?

The big guys seem to play by the rules of "You catch the first horse you can, ride it to death, then run off and catch another one to ride to death.  You don't get to act surpsised when your horse dies".



David Hiers

CCIE (R/S, V), CISSP
ADP Dealer Services
2525 SW 1st Ave.
Suite 300W
Portland, OR 97201
o: 503-205-4467
f: 503-402-3277 


-----Original Message-----
From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov
Sent: Tuesday, August 04, 2009 4:00 AM
To: Peter Beckman
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] Any subscribers from the UK?

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
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.