[wp-testers] Wordpress scaling problems

[Austin Matzko]

On Thu, Jan 29, 2009 at 5:43 AM, matthijs <matthijsenator at gmail.com> wrote:
> Again, I understand that in the - current - wordpress design this is how it
> goes. But if you forget the current design for a moment, and think about how
> you could otherwise design a system handling permalinks. I can hardly
> believe there is no other way to do this.

I think there are at least a couple of potential solutions for a
situation like yours, in which you have hundreds of pages.

First, change the logic of verbose page rules.  Currently, when
WordPress encounters what it considers a "verbose" permalink structure
such as yours[1], it explicitly lists all the pages' permalinks and
puts them early in the permalink rules.  Then, WP leaves the
categories to be matched by pattern. It does this on the
assumption---safe for most blogs---that there will be more categories
than pages.

However, in your case it's likely that there are more pages than
categories.  WordPress could change the logic of verbose page rules by
explicitly writing the rules of whichever of categories and pages has
the fewest, matching the other by pattern instead. Or perhaps it could
explicitly write out most of the permalink pattern for whatever thing
has under X items.  This change would be the least disruptive from how
WordPress currently does things.

A second, more radical, change would be rethink the permalink-matching
model.  Currently WordPress compares each rewrite rule pattern to the
*entire* request string until it finds a match (just like Apache's
rewrite rules).  Instead, WP could follow an algorithm similar to that
used by its own get_category_by_path() function: start at the right
and work left.

So to use Otto's example, we have the request string /mycat/mypost.
1. Split the string by "/"
2. Query for a slug that matches "mypost."  If there's only one
result, then we can be reasonably certain we know what it is: either
the page or post that matches, and go to 3 or 4.  If there's no
result, see whether it could be category or date.  More than one
result: move to 3 or 4 to resolve the ambiguity.
3. If "mypost" is a page, check whether "mycat" is a parent page for that page.
4. If "mypost" is a post, check whether "mycat" is a category of that post.
Etc.

Or we could combine the approaches: if there are just a few
unambiguous page or categorie permalink patterns, try matching the
request string to those unambiguous patterns.  If that fails, go to
the get_category_by_path()-like algorithm.

[1] /%category%/%year%/%monthnum%/%day%/%postname%