[wp-testers] Wordpress scaling problems

[matthijs]

On Thu, Jan 29, 2009 at 11:07 AM, Otto <otto at ottodestruct.com> wrote:

> On Thu, Jan 29, 2009 at 3:14 AM, matthijs <matthijsenator at gmail.com>
> wrote:
> > Is that true? Do you really need to load - all - rules every time? I do
> > understand that's the way it's currently done. But is there absolutely no
> > way to design it in a different way? So that for example, you first look
> at
> > the request bit by bit and then load only what's needed?
>
> For the specific case that we're talking about, yes, you need them
> all. The key here is the category and/or postname. These are just
> arbitrary strings. So you need all the strings with which to compare
> it with.
>

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. How are all those other websites
with more then a few hundred pages doing it then?



>
> Database queries are expensive. String comparisons in memory are fast as
> heck.


The usual php/mysql 101 is the opposite: let the database handle the
calculation, not php.

Mysql queries are fast and if done well almost never the problem. But we are
really not talking about the comparison of a basic string comparison and a
few db queries. If done well both are about milliseconds and never the
bottleneck in speed. The issue here is a situation in which wordpress can't
fit a value in a database field and suddenly needs to run more then 2400
queries to get a single page.

If there really would be no solution possible even with an alternative
design (which I don't believe), then the feature of having flexible
permalinks should just be removed. Just let wordpress have default urls
based on date. Of course then you will disappoint many people.

Again, I just want to talk about possible alternatives. And what the
developers think about how to handle this problem.