OT: why are LAMP sites slow?

[Tim Daneliuk]

Paul Rubin wrote:

> Tim Daneliuk <tundra at tundraware.com> writes:
> 
>>[other good stuff from Tim snipped]
>>
>>>Today I think most seeks can be eliminated by just using ram or SSD
>>>(solid state disks) instead of rotating disks.  But yeah, you wouldn't
>>>do that on a laptop.
>>
>>But that still does not solve the latency problem of session
>>establishment/ teardown over network fabric which is the Achilles
>>Heel of the web and web services.
> 
> 
> Well, HTTP 1.1 keepalives takes care of some of that, but really,
> really, most of this problem is server side, like when you browse a
> Wikipedia page it might take a few seconds, which isn't good, but when
> you update it, it takes most of a minute, which is awful.  The
> difference is that editing means server side web cache misses followed
> by a database update that affects numerous indices.

Noted and agreed.  However, also note that establishing/killing
sessions over a high-latency architecture is generally problematic.
The latency can come from any number of sources including servers
starving for memory/cache misses, as well as the network itself exhbiting
latency problems.  One of reasons the older CRS systems were so fast
was that, although the connection *speeds* were low, the networks were
private, polled fabric with very predictable performance characteristics.
Every terminal was guaranteed to be serviced at a regular interval.
Better customers (who were guaranteed better service levels) just got
their terminals serviced more frequently.

When I left Apollo in the mid-
1990s, there were customers running on this private network who were
guaranteed 3 second or better *round-trip* time (from Enter to transaction
results displayed).  This was in an environment with nearly 100,000
users and the core system peaking at something like 22,000 TPC/As
per second ... with 2 or 3 minutes of scheduled downtime per year.
This kind of performance comes from looking at the architecture as a whole,
not just pieces and parts.  One of the troublesome things about the web
is that this kind of systemic thinking about performance and reliability
seems to be rather rare.  For instance, he whole design of SOAP/RPC seems to be
oblivious to the 40+ years of history on these issues that preceded
the web.

With the advent of public/dynamic networks where a lot of discovery and
variable load exists, it is much harder to nail up a latency and
throughput guarantee.  This is part of the motiviation for adding QOS
facilities to IPV6.  However, as a practical matter, I think the explosion
of last-mile broadband as well as generally more lit up fiber in the backbones
may make QOS less necessary - we'll just throw bigger pipes at the problem.
It is well within the realm of possibility that we'll see OC3 class bandwidth
to the premise for reasonable cost in the foreseeable future.

> 
> Wikipedia keeps having these fundraising drives to buy more server CPU
> iron (I've donated a few times) but I wonder if they'd be better off
> spending it on solid state disks and/or software reorganization.

Since I do not use Wikipedia, I have no meaningful comment.  As someone
pointed out here, PHP is also suspect when seeing performance issues.

<OB Python Comment>

One of the things I love about Python is its facility for allowing you to do
things that are time-insensitive in a VHLL and then dive into C or even assembler
if needed for the time-critical stuff.  This fixes the language part of the
architecture problem, but does not, in and of itself, amerliorate the larger
systems architeture questions (nor would I expect it to)...
-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra at tundraware.com
PGP Key:         http://www.tundraware.com/PGP/