[wp-testers] Wordpress scaling problems

[Otto]

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

Simple. They don't use bad permalink strategies.

You too can scale WordPress to ridiculous numbers of pages. Just don't
put "category" in the permalink string. Easy.


>> 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.

Err... Don't know where you got that, but no, this is almost never the
case with modern web design. Database queries are far more expensive.
Why? Because usually your database is overloaded and overworked to
begin with. So it's slower than doing calculations yourself.

It's also a matter of distribution, if you're having your database do
calculations and such (other than mere data retrieval), then you're
loading all your processing into one place: the database server. And
remember, that database server usually is not just for your site only,
it could be servicing hundreds or thousands of sites. Why have your
hundred sites sitting there doing nothing waiting for the single
database to do this work you need?

No, better to use the database for what it is: A data storage and
retrieval system. Let your sites do the actual thinking. There's more
sites than databases.

> 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.

No. The option table's value column is LONGTEXT. A LONGTEXT has a
maximum size of 4,294,967,295 (2^32-1) characters. So you're not
talking about "can't fit a value in a database field" because the
value most definitely does fit unless you've exceeded 4 GB in size.

The reason it has to suddenly run 2400 queries is not because the
field is so large that it doesn't fit, but that your configuration is
wrong so that there is a timeout or a max query size or some other
parameter being exceeded.