Câți utilizatori poate gestiona WordPress?

Conform structurii bazei de date WordPress, ID-ul din wp_users este de tip Bigint(20) UNSIGNED, deci "teoretic" ai putea adăuga până la 18446744073709551615 de utilizatori. http://dev.mysql.com/doc/refman/4.1/en/integer-types.html

Răspund puțin mai târziu la această întrebare, dar deoarece apare în căutări relevante, această informație va fi utilă cuiva:

WordPress folosește schema de baze de date EAV pentru o parte din implementarea bazei de date. Aceasta afectează atât datele, cât și utilizatorii. (Acestea sunt păstrate în tabele separate)

Să explicăm din perspectiva datelor:

Pe lângă detaliile postărilor accesibile direct în wp_posts, numeroase metadate sunt stocate în tabelul wp_postmeta pentru fiecare post. Orice date relevante pentru postare (sau tipul de postare personalizat).

Problema este că, dacă ai FOARTE MULTE postări sau pagini (sau date/postări personalizate), devine foarte lent să cauți orice proprietate găsită în metadate. Mai întâi cauți toate intrările din tabelul de metadate pentru criteriile de care ai nevoie, apoi obții postarea relevantă din tabel. Problema este că trebuie să cauți pentru FIECARE criteriu în parte. Deci, o căutare pentru etichetă, obții postările cu valoarea X pentru 'meta1', apoi cauți al doilea criteriu, să zicem, customcriteria și obții ID-urile postărilor cu customcriteriavalue1 în customcriteria, ȘI apoi iei intersecția acestora și mergi să obții detaliile postării din tabelul de postări cu acea intersecție.

Ca exemplu - introduceți 30.000 de produse în WooCommerce și veți ajunge cu ~1.800.000 de rânduri în wp_postmeta, așa cum este explicat în răspunsul de mai jos:

Metadate post vs tabele separate de baze de date

Deci, nu numai că aceasta va face căutările foarte, foarte ineficiente (mai ales când faci self-joins pe wp_postmeta pentru criterii multiple), dar chiar și interogarea unui singur rând din 1,8 milioane de rânduri provoacă o scădere a performanței.

Deficiența schemei EAV.

Deci, cu multe postări, implementarea bazei de date WordPress face căutările complexe foarte lente.

Administrarea unui site WordPress cu mii de postări este posibilă, dacă folosești plugin-uri de caching. Poți merge chiar și mai departe. Dar căutările vor fi o problemă.

............

La fel este și cu utilizatorii - wp_usermeta folosește același format EAV. Deci, dacă ai mulți utilizatori și multe plugin-uri care stochează diverse date ale utilizatorilor în wp_usermeta, vei avea aceeași scădere a performanței.

Fără să mai vorbim că, cu atât de mulți utilizatori, este probabil să ai deja un număr mare de postări - dacă aplicația ta nu este ceva care are de-a face mai mult cu utilizatorii (CRM etc.) și alegi să-ți stochezi datele utilizatorilor în wp_usermeta în loc de wp_postmeta. (Puțin probabil, totuși).

.........

Există câteva plugin-uri care încearcă să ocolească această problemă, cum ar fi Meta Accelerator.

https://wordpress.org/plugins/meta-accelerator/

Acest plugin ia orice date pentru orice tip de postare pe care îl alegi și le pune în tabele plate. Aceasta accelerează mult căutările și, de asemenea, accelerează interogarea oricărei valori singulare.

Dar acest plugin este încă în faza incipientă.

Alternativ, poți instala ElasticSearch pe server și folosi plugin-ul ElasticPress sau un alt plugin care îl integrează în WordPress pentru a accelera astfel de căutări.

Cred că poți susține chiar și mai mulți utilizatori. Singurul lucru care te poate limita este serverul. Va trebui să îl scalezi corespunzător, în special serverul MySQL. De exemplu, wordpress.com rulează chiar peste 40.000 de utilizatori, dar folosesc sisteme extrem de puternice pentru stabilitate, o mulțime de echilibrare a încărcării (load balancers) și altele.

Am descoperit că limitarea principală pentru numărul de utilizatori WordPress pe care îi poți avea este timeout-ul PHP care intră în joc pe pagina de administrare a utilizatorilor.

Presupunând că toți utilizatorii tăi au cel puțin un rol, ei au o intrare wp_capabilities în tabela user_metadata cu un array serializat de roluri.

Pagina de administrare afișează un număr al câți utilizatori au fiecare tip de rol, așa că trebuie să încarce fiecare array serializat wp_capabilities, să-l deserializeze și apoi să afișeze un număr total.

Când am 300.000 de utilizatori, pagina de administrare a utilizatorilor durează 44 de secunde să se încarce.

Asta înseamnă că fiecare utilizator adaugă 0,00014666666 secunde la timpul de încărcare al paginii.

Presupunând că timeout-ul tău PHP este de 60 de secunde, limita ar fi în jur de 400.000 de utilizatori.

Totuși, rulez pe un server destul de vechi și lent. Hardware-ul mai rapid ar îmbunătăți lucrurile semnificativ.

Întrebarea ar trebui să fie câți utilizatori poate gestiona stiva php-mysql în loc de WordPress, deoarece WP este dezvoltat pe aceste două tehnologii principale.

Fiind spus asta, dacă poți configura serverul cu tehnici avansate de server, găzdui WordPress pe un server bine gestionat, optimizat pentru încărcarea și interogările bazei de date, atunci WP poate gestiona câți membri dorești.

Dacă instalezi WordPress pe un hosting partajat, atunci îți limitezi capacitățile WP. Pe de altă parte, dacă poți gestiona singur rularea WordPress de pe un server cloud sau dedicat, atunci ar trebui să obții rezultatul dorit.

WordPress este capabil să gestioneze interogări complexe ale bazei de date. Poți verifica acest link: https://codex.wordpress.org/Installing_WordPress

De asemenea, folosirea WordPress ca un cadru avansat de dezvoltare de aplicații îți permite să faci instalarea ta să gestioneze încărcări mari/complexe ale bazei de date.

Poți verifica și această serie: http://code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015

Sper că acest lucru va ajuta. Mulțumesc.