[wp-hackers] Improving WordPress' Performance WAS Changing MySQL
minimum version
Computer Guru
computerguru at neosmart.net
Thu Nov 30 18:59:59 GMT 2006
Besides the DB, the entire frontend is also just as inefficient. Take a look
at http://lightpress.org/
I've launched several clients with LightPress, because I was custom-coding
their entire site anyway. But for the average user, that's just not an
option.
LightPress is a total revamp of the theming system and the GUI. It's
installed as a plugin on top of WP, and is _NOT_ a fork of WP.
Unfortunately, development there is (understandably) slow.
My point in all this isn't that WP sucks or that you should use Lightpress
along with it, but rather that from the very bottom (the database) to the
very top (the frontend), WP is inefficient. Very inefficient.
With WP 1.5 that wasn't a problem. *THEN* it was "just a blogging platform,"
but now, WP is much, much more. The sad thing is, WP is getting too large to
rewrite. Because a rewrite is the only thing that can fix it. And a rewrite
at this point would kill compatibility.
Ideally, we'd say 'screw compatibility,' release 2.1, take a 6-8 month break
from coding new features and in this time re-create the database taking
advantage of all MySQL-specific optimizations, bump up the MySQL minimum
version and take advantage of all the new performance features offered, and
then re-implement LightPress as a part of the core. The actual WP code is
marvelously well-written, clear, and fairly concise compared to other
projects of its size - only the frontend needs to be redone per the
LightPress specifications.
But that's not going to happen. I don't see why not, Firefox was rewritten
from scratch several times (not that it helped, Fx's code is absolutely
ghastly and leaks memory more than Hoover Dam has water) - and that was a
MUCH bigger project than WP.
The only thing is, Firefox was rewritten to improve the quality of the code,
and not the performance. i.e. the rewritten Firefox was kept 100% backwards
compatible during the rewrite. However, for WP, that would require the
breaking of quite a few plugins just to make it even slightly faster.
No matter how you look at it, WP is horribly inefficient and now it's
definitely big enough that this warrants a second look. We need to do
something, the only question is, what?
As far as the DB goes, I feel we can (if we wanted to) rewrite it without
breaking compatibility, since we just have to keep the functions the same.
Officially, WP doesn't support plugins or themes that grab info from the
database themselves - that's what the hooks are for, so we don't have to
worry about breaking those kind of things.
But no DB-rewrite is complete without rewritten functions (the LightPress
bit), and that's a bit of a conundrum. After all, WP's biggest advantage is
the millions of plugins and themes and the huge community that builds them -
not something to be taken lightly or trifled with in this manner.
.... I hate endings like this.. Please, someone, think of something!
Computer Guru
NeoSmart Technologies
http://neosmart.net/blog/
> -----Original Message-----
> From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-
> bounces at lists.automattic.com] On Behalf Of Doug Stewart
> Sent: Thursday, November 30, 2006 8:40 PM
> To: wp-hackers at lists.automattic.com
> Subject: Re: [wp-hackers] Re: Changing MySQL minimum version
>
> On 11/30/06, Computer Guru <computerguru at neosmart.net> wrote:
> > Not to start a war or anything, but I think David's right. Ever since
> 1.5 WP
> > has become notorious for its rather in-efficient database. I'm NOT
> (let me
> > repeat: NOT) a database expert and all I know about MySQL is just how
> to
> > create a database that does the job. But I think there is something
> missing
> > from WP's database performance.
> >
> > When you have forums like phpBB and IPB that can take up to 100 or
> more
> > times the load as WP _without caching_ and they serve quite a lot
> more
> > queries, I think that means something is wrong.
> >
> > IMO, WP being inefficient at DB-querying is something that already
> happened,
> > and unless someone is volunteering to completely redo the database
> with full
> > optimizations and proper schemas taking advantage of all of MySQL's
> > (admittedly few) SQL-Side power tools, there's nothing to be done.
> But
> > ignoring these features for future changes and feature-sets is
> another
> > story...
> >
>
> Amen to all of that. Take, for instance, Flopping Ace's recent
> disparaging of WordPress due to the fact that his WP site was taken
> down by traffic generated by the bogus "6 burned Sunnis" story:
> http://floppingaces2.blogspot.com/2006/11/msm-patting-themselves-on-
> back.html
>
> He used to have a fairly attractive and heavily-trafficked WP site but
> when push came to shove, WP couldn't handle the load. MT's static
> publishing might be a pain in the butt and have its own downsides, but
> MT-run sites run circles around WP sites when it comes to a digging,
> /.'ing, Penny Arcade "wanging" or an Instalanche. I can't tell you
> how many frickin' times I've seen that WP "Error reaching the
> database" error screen on blog posts carelessly dugg. I loathe
> Diggmirror, but such circumstances seemingly leave regular readers
> with no choice.
>
> So a hearty +1DAM, +20 to hit on doing whatever we have to do to make
> the mysql portion of WP work better.
>
> --
> -Doug
>
> http://literalbarrage.org/blog/
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
More information about the wp-hackers
mailing list