Quanti utenti può gestire WordPress?
Vorrei progettare un sito con login per gli utenti in WordPress ma ho un dubbio: WordPress può gestire più di 40.000 utenti nello stesso database?
Non sono sicuro di questo aspetto quindi ho interrotto il mio lavoro qui. Vi chiedo aiuto se qualcuno sa esattamente come procedere con il mio progetto in WordPress.

Secondo la struttura del database di WordPress, l'ID in wp_users è di tipo Bigint(20) UNSIGNED, quindi "teoricamente" potresti aggiungere fino a 18446744073709551615 utenti. http://dev.mysql.com/doc/refman/4.1/en/integer-types.html

Rispondo con un po' di ritardo, ma dato che questa domanda risulta rilevante nelle ricerche, potrebbe essere utile a qualcuno:
WordPress utilizza lo schema di database EAV per parte della sua implementazione del database. Questo riguarda sia i dati che gli utenti. (Vengono mantenuti in tabelle separate)
Per spiegarlo dal punto di vista dei dati:
Insieme ai dettagli direttamente accessibili relativi ai post in wp_posts, numerosi metadati vengono inseriti nella tabella wp_postmeta per ogni post. Qualsiasi dato rilevante per il post (o per il tipo di post personalizzato).
Il problema è che, se hai MOLTISSIMI post o pagine (o dati/post personalizzati), diventa piuttosto lento cercare qualsiasi proprietà presente nei metadati. Prima devi cercare tutte le voci nella tabella meta secondo i criteri che ti servono, poi ottenere il post relativo dalla tabella. La cosa peggiore è che devi cercare per OGNI criterio separatamente. Quindi una ricerca per tag, ottieni i post con il valore X per 'meta1', poi cerchi un secondo criterio, ad esempio customcriteria e ottieni gli ID dei post con customcriteriavalue1 in customcriteria, E poi prendi l'intersezione di questi e vai a ottenere i dettagli del post dalla tabella posts con quell'intersezione.
Come esempio - inserisci 30.000 prodotti in WooCommerce, e finirai con ~1.800.000 righe in wp_postmeta come spiegato nella risposta qui sotto:
Post meta vs tabelle di database separate
Quindi, non solo questo renderà la ricerca molto molto inefficiente (soprattutto quando fai self join su wp_postmeta per più criteri), ma anche interrogare una singola riga tra 1,8 milioni di righe causa un calo di prestazioni.
Deficit dello schema EAV.
Quindi, con molti post, l'implementazione del database di WordPress rende le ricerche complesse molto lente.
Gestire un sito WordPress con migliaia di post è fattibile, se usi plugin di caching. Puoi spingerti anche oltre. Ma le ricerche saranno un problema.
............
Lo stesso vale per gli utenti - wp_usermeta utilizza lo stesso formato EAV. Quindi se hai molti utenti e molti plugin che memorizzano vari dati utente in wp_usermeta, subirai lo stesso calo di prestazioni.
Per non parlare del fatto che con così tanti utenti è probabile che tu abbia già un numero elevato di post - a meno che la tua app non sia qualcosa che riguarda principalmente gli utenti (CRM ecc.), e scegli di memorizzare i dati degli utenti in wp_usermeta invece che 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 qualsiasi dato per qualsiasi tipo di post che scegli e li inserisce in tabelle flat. Questo velocizza molto la ricerca e accelera anche l'interrogazione di qualsiasi valore singolo.
Ma questo plugin è ancora nelle sue prime fasi.
In alternativa, puoi installare ElasticSearch nel server e utilizzare il plugin ElasticPress o un altro plugin che lo integra con WordPress per velocizzare tali ricerche.

Penso che tu possa gestire ancora più utenti.
L'unica cosa che può limitarti è il tuo server. Dovrai dimensionarlo correttamente, soprattutto il server MySQL. Ad esempio wordpress.com
gestisce addirittura più di 40000 utenti, ma utilizzano sistemi estremamente potenti per la stabilità, tonnellate di bilanciatori di carico e così via.

Ho scoperto che il collo di bottiglia per il numero di utenti WordPress gestibili è determinato dal timeout PHP che entra in gioco nella pagina di amministrazione degli utenti.
Supponendo che tutti i tuoi utenti abbiano almeno 1 ruolo, avranno una voce wp_capabilities
nella tabella user_metadata
con un array serializzato dei ruoli.
La pagina di amministrazione mostra un conteggio di quanti utenti hanno ciascun tipo di ruolo, quindi deve caricare ogni singolo array serializzato wp_capabilities, deserializzarlo e poi mostrare un conteggio totale.
Quando ho 300.000 utenti, la pagina di amministrazione degli utenti impiega 44 secondi per essere generata.
Ciò significa che ogni utente aggiunge 0,00014666666 secondi al tempo di caricamento della pagina.
Supponendo che il tuo timeout PHP sia di 60 secondi, il limite sarebbe intorno ai 400.000 utenti.
Tuttavia, sto utilizzando un server piuttosto vecchio e lento. Hardware più veloce migliorerebbe notevolmente le prestazioni.

La domanda dovrebbe essere quanti utenti può gestire lo stack PHP-MySQL piuttosto che WordPress, dato che WP è sviluppato su queste 2 tecnologie principali.
Detto questo, se puoi configurare il server con tecniche avanzate, ospitare WP su un buon server gestito, ottimizzare il carico e le query del database, allora WP può gestire quanti membri desideri.
Se installi WordPress su un hosting condiviso, stai limitando le capacità del tuo WP. D'altra parte, se riesci a gestire autonomamente l'esecuzione di WP su un server cloud o dedicato, allora dovresti ottenere il risultato desiderato.
WordPress è in grado di gestire query di database complesse. Puoi dare un'occhiata qui: https://codex.wordpress.org/Installing_WordPress
Inoltre, utilizzare WordPress come framework avanzato per lo sviluppo di applicazioni ti permette di far gestire al tuo installazione carichi di database grandi/complessi.
Puoi anche controllare questa serie: http://code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015
Spero che questo ti sia d'aiuto. Grazie.

Per la cronaca, la parte PHP
dello stack non sarà il tuo problema (Facebook è costruito con un PHP modificato), ma MySQL
potrebbe benissimo essere un limite.
