WordPress MU

Hello everyone,

Can somebody tell me about MU speed and resource using?
Simple I see that each blog added at least 8 tables in the database, i.e. 1000 users will generate 8000 tables...

Will MU work with so many table in the database?
Will MySQL work with so many tables in one database?

Did somebody do some tests for MU productivity?

Thank,
Dan

a good test is: http://wordpress.com, with hundred thousands blogs.

http://edublogs.org/ is another place where thousands of blogs are managed from a unique system.

MySQL is built to manage tables... so it's logical that the server itself is able to manage a large amount of tables... there was two possibilities.. storing in a single table all the blogs, or creating new tables for each blogs... the second is better if you split servers, or backup large amount of blogs - even if some noobs tells it is not...

a detail about productivity: it is server-efficient to use a single bundle of files instead of installing customized files for each blog you create.

having a single pack of files read and re-read each time, can be efficient if you have a cache-system in place... most big installations are providing caching from PHP (Zend of others)... that makes your script very efficient too...

the db structure of WPMU is good, but you have to evaluate the addition of plugins if they are asking for more db-requests... reason is they are not built to use the active resources, but create their own processes. this is one big change to be made from coders of addons i think, but if you have a coder in-house, call him!

Ok nexia, thank you for your explain. I asked because do not trust MySQL, I work with this database a long time because I need, but still not trust well :(

Do you know why donncha did it so in many tables, it was very easy to start it in standard tables...

BTW, I'm thinking that it's OK, and I will see later how many members it will have and when it will gone :)

Thank you.

I have around 30000 blogs and with a few tweaks here and there my dual xeon is breezing. 32000 blogs represent a limit that has to be overcome due to the fact that linux can't handle more than 32000 subfolders in one folder (the upload space for users).
If you don't plan on more than 32000 users, you can go for it without wondering. If you do, well you can hope MU will be better at handling them when you reach that number ;-).

Ok, thank you, I thought the same way...

Simple, I started working with MU, but found LYCEUM and therefore got the food for my brain.

But MU I love more because it's more useful and clear to understand from the developer side.

Thank you guys for your help.

i've read the LYceum stuff... this is far from being as developped as WPMU... they tend to compare, but they can't...
the version itself is far from release (0.33 is far from a 1.0 final)...
also, the features that they compare with are old and irrelevent. WPMU was upgraded long time ago, and the missing features are not anymore.

also, there is not a large community of developpers/coders for LYceum... i'm not even sure if you can add plugins or themes to lyceum, because it is not documented... WPMU is tested and have good echoes about that...

Yes Nexia, you're right. I studied lyceum, spent about 6 hours yesterday night... Seems last stable release by July 2006.

In my opinion they have only two real advantages:
1. multiblogging;
2. no multi tables;

it's only on my opinion...

and another problem which makes me headache, maybe you know: articles and pages editor have some JavaScript problems with drag&drop functionality for blocks... I added this issues to trac system but trying to fix it itself, maybe somebody know fast solution?

Thanks

dan, here you have some more discussion on pros and cons of the MU option:
http://mu.wordpress.org/forums/topic.php?id=1834&replies=15

Hi quenting,

Yes I read this topic and on my opinion both sides are right 50x50...

MySQL is not relational database and only in this case information in many tables is much much useful for MySQL than all in one.

quenting,
You wrote about your "dual xeon" running about 30K blogs. Can you please say what is in the box and where do you host it?

Many thanks :)

I just got my first email spam for a edublogs.org blog. :(

Quenting, you write:
"32000 blogs represent a limit that has to be overcome due to the fact that linux can't handle more than 32000 subfolders in one folder (the upload space for users)."

What folder is that exactly? /wp-content/blogs.dir? It creates a dir with the userid as name, but only when a user uploads a file, right? Currently working on a solution for this issue and that information might help.

> quenting,
> You wrote about your "dual xeon" running about 30K blogs.
> Can you please say what is in the box and where do you host it?

It's hosted in france. It's a dual xeon with 4Gb RAM and 15000rpm SCSI RAID disks.
Another somewhat popular site's hosted on it so I can't tell exactly how many total blogs it could host if empty otherwise. But it can handle 30000 blogs along with this other site. Probably can 50000, hopefully I can tell soon ;).

> What folder is that exactly? /wp-content/blogs.dir? It creates a dir with the userid as name, but only when a user uploads a file, right? Currently working on a solution for this issue and that information might help.

Yes, blogs.dir is the one. On the nightly I use it creates the folder systematically, maybe things were improved since then.
Solving this problem is only a part of the scaling issue though.

Having all tables in one database is bad, even if you stay on one server. That's because 1 user = 8 tables (i think it's 8 now, although it was 10 with my nightly) = 24 files in the mysql database folder. Opening a file in a folder (when mysql needs to read from that particular table) is taking more time when you have hundreds of thousands files than if you have a couple. So splitting your database into multiple ones each having less tables inside means a general faster access to those tables. I'm guessing that's why wp.com split their tables to 4096 databases.
$That's why i think solving the directories problem is a bit narrow, soon enough you'll face other more complex problems, and you'll need to figure out a better solution, that would eventually also solve the directories problem right away. Just my 2c.