Quanti utenti possono gestire WordPress?


10

Voglio progettare un sito di accesso dei membri in WP ma ho dubbi sul fatto che WordPress può gestire più di 40000 utenti sullo stesso database?

Non ne sono sicuro, quindi chino il mio lavoro qui. Quindi, per favore, aiutami se qualcuno sa esattamente questo per procedere con il mio progetto con WP.

Risposte:



6

Un po 'in ritardo per rispondere a questo, ma dal momento che sta arrivando per la ricerca pertinente, questo sarà utile a qualcuno:

WordPress utilizza lo schema del database EAV per parte della sua implementazione del database. Ciò influisce sia sui dati che sugli utenti. (Sono tenuti in tabelle separate)

Per spiegarlo dal punto di vista dei dati:

Insieme ai dettagli relativi ai post direttamente accessibili in wp_posts, numerosi meta vengono pubblicati nella tabella wp_postmeta per ogni post. Qualsiasi dato rilevante per il post (o tipo di post personalizzato).

Il problema è che se hai HEAPS di post o pagine (o post / dati personalizzati), diventa piuttosto lento cercare qualsiasi proprietà trovata in meta. Prima devi cercare tutte le voci nella meta tabella per i criteri di cui hai bisogno, quindi ottenere il post pertinente dalla tabella. Il kicker è che devi cercare OGNI criterio separatamente. Quindi una ricerca per tag, ottieni i post con il valore X per "meta1", quindi cerchi i secondi criteri, diciamo, criteri personalizzati e ottieni ID post con criteri di valutazione personalizzati in criteri personalizzati, quindi prendi l'intersezione di questi e poi vai a ottenere i dettagli del post dalla tabella dei post con quell'intersezione.

Ad esempio, inserisci 30.000 prodotti in WooCommerce e finirai con ~ 1.800.000 righe in wp_postmeta, come spiegato nella seguente risposta:

Pubblica meta vs tabelle di database separate

Quindi, non solo questo renderà la ricerca molto inefficiente (specialmente quando si eseguono i self join su wp_postmeta per più criteri), ma anche eseguire una query su una singola riga tra 1,8 milioni di righe provoca un calo delle prestazioni.

Carenza dello schema EAV.

Quindi, con molti post, l'implementazione del db di WordPress rende le ricerche complesse molto lente.

L'esecuzione di un sito WordPress con migliaia di post è abbastanza fattibile se si utilizzano plug-in di cache. Puoi andare ancora di più. Ma le ricerche saranno un problema.

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

Lo stesso vale anche per gli utenti: anche wp_usermeta utilizza lo stesso formato EAV. Quindi, se hai molti utenti e hai molti plugin che memorizzano vari dati utente in wp_usermeta, otterrai lo stesso risultato prestazionale.

Per non parlare di così tanti utenti, è probabile che tu abbia già un numero elevato di post, a meno che la tua app non abbia a che fare principalmente con gli utenti (CRM ecc.) E decidi di archiviare i tuoi dati utente in wp_usermeta anziché in wp_postmeta . (Improbabile però).

.........

Ci sono alcuni plugin che cercano di aggirare questo problema, come Meta Accelerator.

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

Questo plugin prende tutti i dati per ogni tipo di post che scegli e li mette in tabelle piatte. Questo accelera molto la ricerca e accelera anche l'interrogazione di qualsiasi valore singolare.

Ma quel plugin è ancora agli inizi.

In alternativa, puoi installare ElasticSearch nel server e utilizzare il plug-in ElasticPress o un altro plug-in che lo integra in WordPress per accelerare tali ricerche.


5

Penso che tu possa eseguire ancora più utenti. L'unica cosa che può limitarti è il tuo server. Dovrai ridimensionarlo correttamente, in particolare il server MySQL. Ad esempio, wordpress.comgestisce anche più di 40000 utenti, ma usano sistemi extra potenti per stabilità, tonnellate di bilanciatori del carico ecc.


4

La domanda dovrebbe essere: quanti utenti possono gestire lo stack php-mysql invece di WordPress poiché WP è sviluppato su queste 2 principali tecnologie.

Detto questo, se è possibile configurare il server con tecniche server avanzate, ospitare il WP in un buon server gestito, il caricamento del database ottimizzato e le query, WP può gestire tutti i membri che si desidera.

Se installi wordpress in un hosting condiviso, stai limitando la tua capacità di WP. D'altra parte, se riesci a gestirti eseguendo WP da un server di hosting basato su cloud o dedicato, dovresti ottenere il risultato desiderato.

Wordpress è in grado di gestire complesse cave di database. Puoi dare un'occhiata a questo https://codex.wordpress.org/Installing_WordPress

Anche l'utilizzo di wordpess come framework avanzato di sviluppo di applicazioni consente di eseguire l'installazione per gestire carichi di database complessi / di grandi dimensioni.

puoi anche chk questa serie: http://code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015

Spero che questo possa aiutare. Grazie


Per la cronaca, la PHPparte dello stack non sarà il tuo problema (Facebook è costruito con un PHP modificato), ma MySQLmolto bene potrebbe essere limitante.
Dan,

3

Ho trovato il collo di bottiglia per quanti utenti di Wordpress puoi avere è il timeout di PHP che entra in gioco nella pagina di amministrazione degli utenti.

Supponendo che tutti i tuoi utenti abbiano almeno 1 ruolo, hanno una wp_capabilitiesvoce nella user_metadatatabella con un array serializzato di ruoli.

La pagina di amministrazione mostra un conteggio del numero di utenti con ciascun tipo di ruolo, quindi deve caricare ogni singolo array serializzato wp_capabilities, annullare la serializzazione e quindi mostrare un conteggio totale.

Quando ho 300.000 utenti, la pagina di amministrazione degli utenti impiega 44 secondi per essere costruita.

Ciò significa che ogni utente aggiunge 0,00014666666 secondi al tempo di caricamento della pagina.

Supponendo che il timeout di PHP sia di 60 secondi, il limite sarebbe di circa 400.000 utenti.

Tuttavia sto eseguendo un server piuttosto vecchio e lento. Un hardware più veloce migliorerebbe notevolmente le cose.


Non penso che l'impatto sia lineare, ma sono d'accordo con l'essenza di esso, non è tanto il numero ma ciò per cui usi effettivamente le informazioni e dove / quando accedi
Mark Kaplun
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.