[development] Advanced DB features

[Ken Rickard]

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 at gmail.com
http://ken.therickards.com


On Thu, May 1, 2008 at 8:08 AM, Earnie Boyd <earnie at users.sourceforge.net>
wrote:

> Quoting Larry Garfield <larry at garfieldtech.com>:
>
>
> > On Wed, 30 Apr 2008 11:27:31 -0700, "Joshua D. Drake" <
> > jd at commandprompt.com> wrote:
> >
> > > On Wed, 30 Apr 2008 13:18:19 -0500
> > > Larry Garfield <larry at 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20080501/207f69f6/attachment.htm