Earnie-

(I work for one of those corporations.)

But that 100 ms latency would only affect non-Drupal data being pulled into the application -- say an inventory database housed in Connecticut with a web app server in Georgia (actual example). 

Even with such far-flung enterprises, we don't put the _Drupal_ database server that far away from a web server.  To do so is to invite problems. 

And that kind of latency for external data needs to be either cached or (as suggested) stored.  There are all kinds of ways to do this in Drupal -- as Matt, Neil and I discussed at DrupalCON Boston.

I suppose I can imagine an enterprise that forces database storage to be in a separate unit from web servers, but that seems like a legacy technology mistake -- an artifact from an old IT worldview.  Our NOC would never dream of putting the Drupal database on a separate switch from the web/app server.

In our structure, the only real use I can see that would cause this latency is remote authentication against LDAP  -- which, by design, is stored in a separate infrastructure from our web hosting -- but there isn't anything that Drupal can do about that kind of latency.

I suspect that the folks on this thread are talking about different things.  Which leads to much confusion and doesn't help anyone.

Now, can Drupal learn from and exploit the value of stored procedures -- possibly, given the requirement restrictions that Larry mentions.  In fact, we need people with such experience to be active developers on the project.

--
Ken Rickard
agentrickard@gmail.com
http://ken.therickards.com


On Thu, May 1, 2008 at 8:08 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Larry Garfield <larry@garfieldtech.com>:


On Wed, 30 Apr 2008 11:27:31 -0700, "Joshua D. Drake" <jd@commandprompt.com> wrote:
On Wed, 30 Apr 2008 13:18:19 -0500
Larry Garfield <larry@garfieldtech.com> wrote:

My queries, according to dev module, are quite rarely more than 5
ms.  I don't know where you're getting that 30 ms number from.  And,

Have you timed from execution on remote machine to connection on
postgresql machine (pooled/persistent or not) and back?

Joshua D. Drake

No, I can't say I have because A) I don't use PostgreSQL and B) A database server that is sufficiently "remote" that network latency becomes a problem is too far away to begin with.  It should be on a computer sitting on the same ethernet switch as the web server, ideally, or at the very least the same subnet in a data center.  (Most worthwhile web hosts will do the latter, with really really fast ethernet connections between them).


Larry, your statement leads me to believe that you have no experience with large corporations where data latency can be more that 100 ms depending on where the data comes from.  Your ideal situation doesn't fit a corporation with numerous databases in various cities spread throughout the country and world.  All of the DB developers I know always use a stored procedure to gather the data to send back to the client because it is always faster to do so.

Earnie -- http://for-my-kids.com/
-- http://give-me-an-offer.com/