[consulting] Does anyone offer Drupal performance tuning services?

[Darrel O'Pry]

On Mon, Apr 27, 2009 at 12:22 PM, Chris Johnson <cxjohnson at gmail.com> wrote:

> Maybe I shouldn't wade into this with my highly opinionated take on
> things, but I'm feeling curmudgeonly today.
>
> First, some free advice.  As alluded to by another writer, very often
> performance problems are caused by badly written modules.  Most of
> Drupal's contrib code is, in fact, not written in a very optimal way
> for performance.  This is not a criticism, by the way.  Functionality
> first, after all and avoid the premature optimization.
>
> If one is running a D6 site with a large number of modules, the sheer
> number of modules plus the fact that most of them are probably written
> "inefficiently" is probably the biggest cause of performance problems
> -- absent any really gross configuration errors (missing database
> indexes, tiny memory sizes, etc.).  As someone who is running over a
> hundred contrib modules on large number of sites, I see this situation
> all the time.
>
> Lots of modules means lots of PHP code.  Simply opening, reading and
> parsing all those PHP files takes a significant amount of time per
> request.  This is one big reason why PHP opcode caches like APC are
> one of the key first steps in making Drupal run faster.  It's also why
> well written modules include avoiding loading code that won't be used
> for the request when possible.


I kind of have to disagree with your assertion of well written and
conditionally loading code. If you're already using a compile cache like APC
most of the benefits of conditional loading is lost.


> Second, complexity of the performance problem space .  Despite there
> being some large, obvious places to look for performance problems,
> it's really a very large, complicated problem.  There are almost
> innumerable factors involved.  Let me just list a few of them:
>
> 1.  efficiency of the code of the modules being used.
> 2.  end case inefficiencies in core (I'm being charitable, perhaps).
> 3.  anomalous edge case SQL queries.
> 4.  wrong PHP configuration (fairly simple).
> 5.  wrong Apache configuration (quite more complex).
> 6.  wrong database configuration (even more complex).
> 7.  host system configuration errors (large problem space).
> 8.  host system limitations (obscure problem space).
> 9.  VPS configuration errors (obscure problem space.
> 10. network problems (large can of worms by itself).
>
> What this means is, I don't believe any one person knows enough to
> actually solve all problems in all problem spaces.  Probably not any 2
> people, either.  It probably takes 3 or 4 people, say a Drupal expert,
> a DB expert, a host / sysadmin expert and a senior generalist, and
> then maybe even a network expert, if it turns out that's where the
> problem is, as discovered by the previous 3 or 4 experts.


The average developer / sysadmin with 5+ years of experience should be able
to cover all of those tasks.


> That's not to say one guy can't make a big improvement, or enough
> improvement to satisfy the client.  It IS a tradeoff of money versus
> incremental improvement.  But to get every last bit of performance out
> of a system is a really a Hard Problem -- it IS rocket science, so to
> speak.


It's not really rocket science... It's fairly rote work to optimizing an
existing infrastructure.  It just takes a good understanding of resource
requirements and allocation, with a very small set of resources...
processing time, disk storage, ram, network i/o, and interconnect
bandwidth.

It's a fairly closed system compared to the world rockets have to fly
through.


The team I work with (about a dozen folks at OpenBand) will be
> optimizing the heck out of our large D6 distribution over the next few
> months.  It's going to be a very interesting experience.


I bet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/consulting/attachments/20090427/a46297af/attachment.htm>