<br><br><div class="gmail_quote">On Mon, Apr 27, 2009 at 12:22 PM, Chris Johnson <span dir="ltr"><<a href="mailto:cxjohnson@gmail.com">cxjohnson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Maybe I shouldn't wade into this with my highly opinionated take on<br>
things, but I'm feeling curmudgeonly today.<br>
<br>
First, some free advice. As alluded to by another writer, very often<br>
performance problems are caused by badly written modules. Most of<br>
Drupal's contrib code is, in fact, not written in a very optimal way<br>
for performance. This is not a criticism, by the way. Functionality<br>
first, after all and avoid the premature optimization.<br>
<br>
If one is running a D6 site with a large number of modules, the sheer<br>
number of modules plus the fact that most of them are probably written<br>
"inefficiently" is probably the biggest cause of performance problems<br>
-- absent any really gross configuration errors (missing database<br>
indexes, tiny memory sizes, etc.). As someone who is running over a<br>
hundred contrib modules on large number of sites, I see this situation<br>
all the time.<br>
<br>
Lots of modules means lots of PHP code. Simply opening, reading and<br>
parsing all those PHP files takes a significant amount of time per<br>
request. This is one big reason why PHP opcode caches like APC are<br>
one of the key first steps in making Drupal run faster. It's also why<br>
well written modules include avoiding loading code that won't be used<br>
for the request when possible.</blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Second, complexity of the performance problem space . Despite there<br>
being some large, obvious places to look for performance problems,<br>
it's really a very large, complicated problem. There are almost<br>
innumerable factors involved. Let me just list a few of them:<br>
<br>
1. efficiency of the code of the modules being used.<br>
2. end case inefficiencies in core (I'm being charitable, perhaps).<br>
3. anomalous edge case SQL queries.<br>
4. wrong PHP configuration (fairly simple).<br>
5. wrong Apache configuration (quite more complex).<br>
6. wrong database configuration (even more complex).<br>
7. host system configuration errors (large problem space).<br>
8. host system limitations (obscure problem space).<br>
9. VPS configuration errors (obscure problem space.<br>
10. network problems (large can of worms by itself).<br>
<br>
What this means is, I don't believe any one person knows enough to<br>
actually solve all problems in all problem spaces. Probably not any 2<br>
people, either. It probably takes 3 or 4 people, say a Drupal expert,<br>
a DB expert, a host / sysadmin expert and a senior generalist, and<br>
then maybe even a network expert, if it turns out that's where the<br>
problem is, as discovered by the previous 3 or 4 experts.</blockquote><div><br></div><div>The average developer / sysadmin with 5+ years of experience should be able to cover all of those tasks. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
That's not to say one guy can't make a big improvement, or enough<br>
improvement to satisfy the client. It IS a tradeoff of money versus<br>
incremental improvement. But to get every last bit of performance out<br>
of a system is a really a Hard Problem -- it IS rocket science, so to<br>
speak.</blockquote><div><br></div><div>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. <br>
</div><div><br></div><div>It's a fairly closed system compared to the world rockets have to fly through.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The team I work with (about a dozen folks at OpenBand) will be<br>
optimizing the heck out of our large D6 distribution over the next few<br>
months. It's going to be a very interesting experience.</blockquote><div><br></div><div>I bet. </div><div><br></div><div><br></div><div><br></div></div>