Je veux concevoir un site de connexion des membres dans WP mais j'ai un doute que WordPress peut gérer plus de 40000 utilisateurs sur la même base de données?
Je ne suis pas sûr de cela, donc je me penche ici. Alors s'il vous plaît, aidez-moi si quelqu'un le sait exactement pour poursuivre mon projet avec WP.
Réponses:
Selon la structure de la base de données WP, l'ID dans wp_users est Bigint (20) UNSIGNED, vous pouvez donc "théoriquement" ajouter 18446744073709551615 utilisateurs. http://dev.mysql.com/doc/refman/4.1/en/integer-types.html
Un peu tard pour répondre à cela, mais depuis sa sortie pour une recherche pertinente, cela sera utile à quelqu'un:
WordPress utilise le schéma de base de données EAV pour une partie de sa mise en œuvre de base de données. Cela affecte à la fois les données et les utilisateurs. (Ils sont conservés dans des tableaux séparés)
Pour l'expliquer sous l'angle des données:
En plus des détails liés aux articles directement accessibles dans wp_posts, de nombreuses métadonnées sont publiées dans la table wp_postmeta pour chaque article. Toutes les données pertinentes pour la publication (ou le type de publication personnalisé).
Le problème est que si vous avez des HEAPS de publications ou de pages (ou des publications / données personnalisées), il devient assez lent de rechercher toute propriété trouvée dans la méta. Vous recherchez d'abord toutes les entrées dans la méta-table pour les critères dont vous avez besoin, puis obtenez le poste pertinent dans la table. Le kicker est que vous devez rechercher CHACUN des critères séparément. Donc, une recherche de balise, vous obtenez les publications avec la valeur X pour 'meta1', puis vous recherchez des seconds critères, par exemple, des critères personnalisés et obtenez des identifiants de publication avec customcriteriavalue1 dans customcriteria, ET puis prenez l'intersection de ceux-ci et ensuite allez chercher les détails du post du tableau des posts avec cette intersection.
Par exemple - mettez 30 000 produits dans WooCommerce, et vous vous retrouverez avec environ 1 800 000 lignes dans wp_postmeta comme expliqué dans la réponse ci-dessous:
Post méta vs tables de base de données distinctes
Ainsi, non seulement cela rendra la recherche très très inefficace (en particulier lorsque vous effectuez des jointures automatiques sur wp_postmeta pour plusieurs critères), mais également l'interrogation d'une seule ligne parmi 1,8 mil lignes entraîne une baisse des performances.
Carence du schéma EAV.
Donc, avec beaucoup de publications, l'implémentation de WordPress db rend les recherches complexes très lentes.
L'exécution d'un site WordPress avec des milliers de publications est tout à fait faisable, si vous utilisez des plugins de mise en cache. Vous pouvez aller encore plus loin. Mais les recherches seront un problème.
............
C'est la même chose pour les utilisateurs aussi - wp_usermeta utilise également le même format EAV. Donc, si vous obtenez beaucoup d'utilisateurs et que vous avez beaucoup de plugins qui stockent diverses données utilisateur dans wp_usermeta, vous obtiendrez le même résultat de performance.
Sans parler du nombre d'utilisateurs, il est probable que vous ayez déjà un grand nombre de publications - à moins que votre application soit principalement liée aux utilisateurs (CRM, etc.) et que vous choisissez de stocker vos données utilisateur dans wp_usermeta au lieu de wp_postmeta . (Peu probable cependant).
.........
Il existe des plugins qui tentent de contourner ce problème, comme Meta Accelerator.
https://wordpress.org/plugins/meta-accelerator/
Ce plugin prend toutes les données pour le type de publication que vous choisissez et les place dans des tableaux plats. Cela accélère beaucoup la recherche et accélère également l'interrogation de toute valeur singulière.
Mais ce plugin en est encore à ses balbutiements.
Alternativement, vous pouvez installer ElasticSearch sur le serveur et utiliser le plug-in ElasticPress ou un autre plug-in qui l'intègre à WordPress pour accélérer ces recherches.
Je pense que vous pouvez exécuter encore plus d'utilisateurs. La seule chose qui peut vous limiter est votre serveur. Vous devrez le faire évoluer correctement, en particulier le serveur MySQL. Par exemple, il wordpress.comexécute encore plus de 40000 utilisateurs, mais ils utilisent des systèmes très puissants pour la stabilité, des tonnes d'équilibreurs de charge, etc.
La question devrait être de savoir combien d'utilisateurs peuvent gérer la pile php-mysql au lieu de WordPress car WP est développé sur ces 2 technologies principales.
Cela dit, si vous pouvez configurer le serveur avec des techniques de serveur avancées, héberger WP dans un bon serveur géré, une charge de base de données et des requêtes optimisées, WP peut gérer autant de membres que vous le souhaitez.
Si vous installez wordpress dans un hébergement partagé, vous limitez votre capacité WP. D'un autre côté, si vous pouvez vous gérer en exécutant WP à partir d'un serveur d'hébergement cloud ou dédié, vous devriez obtenir le résultat souhaité.
Wordpress est capable de gérer des carrières de bases de données complexes. Vous pouvez consulter ce https://codex.wordpress.org/Installing_WordPress
L'utilisation de wordpess comme cadre de développement d'applications avancé vous permet de faire votre installation pour gérer la charge de base de données volumineuse / complexe.
vous pouvez également supprimer cette série: http://code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015
J'espère que cela vous aidera. Merci
J'ai trouvé le goulot d'étranglement pour combien d'utilisateurs Wordpress vous pouvez avoir est le délai d'expiration PHP entrant en jeu sur la page d'administration des utilisateurs.
En supposant que tous vos utilisateurs ont au moins 1 rôle, ils ont une wp_capabilitiesentrée dans le user_metadatatableau avec un tableau sérialisé de rôles.
La page d'administration indique le nombre d'utilisateurs avec chaque type de rôle. Elle doit donc charger chaque baie sérialisée wp_capabilities, la désérialiser et afficher un nombre total.
Lorsque j'ai 300 000 utilisateurs, la page d'administration des utilisateurs prend 44 secondes à créer.
Cela signifie que chaque utilisateur ajoute 0,00014666666 secondes au temps de chargement de la page.
En supposant que votre délai d'expiration PHP est de 60 secondes, la limite serait d'environ 400 000 utilisateurs.
Cependant, je gère un serveur assez ancien et lent. Un matériel plus rapide améliorerait considérablement les choses.
PHPpartie de la pile ne sera pas votre problème (Facebook est construit avec un PHP modifié), maisMySQLpourrait très bien être limitant.