¿Cuántos usuarios puede manejar WordPress?

Quiero diseñar un sitio de inicio de sesión de miembro en WP pero tengo dudas de que WordPress pueda manejar a más de 40000 usuarios en la misma base de datos.

No estoy seguro de esto, así que estoy haciendo mi trabajo aquí. Entonces, por favor, ayúdenme si alguien sabe exactamente sobre esto para continuar mi proyecto con WP.

Según la estructura de la base de datos de WP, el ID en wp_users es Bigint (20) SIN FIRMAR, por lo que "teóricamente" podría agregar 18446744073709551615 usuarios. http://dev.mysql.com/doc/refman/4.1/en/integer-types.html

Un poco tarde para responder esto, pero dado que está llegando a una búsqueda relevante, esto será útil para alguien:

WordPress utiliza el esquema de base de datos EAV para parte de su implementación de base de datos. Esto afecta tanto a los datos como a los usuarios. (Se guardan en tablas separadas)

Para explicarlo desde el ángulo de datos:

Junto con los detalles relacionados con la publicación directamente accesibles en wp_posts, se publican numerosos meta en la tabla wp_postmeta para cada publicación. Cualquier dato relevante para la publicación (o tipo de publicación personalizada).

El problema con eso es que si tiene HEAPS de publicaciones o páginas (o publicaciones / datos personalizados), se vuelve bastante lento buscar cualquier propiedad que se encuentre en meta. Primero busca todas las entradas en la metatabla para los criterios que necesita, luego obtiene la publicación relevante de la tabla. El truco es que debe buscar CADA criterio por separado. Entonces, una búsqueda de etiqueta, obtienes las publicaciones con el valor X para 'meta1', luego buscas el segundo criterio, por ejemplo, criterios personalizados y obtienes identificadores de publicación con customcriteriavalue1 en criterios personalizados, y luego tomas la intersección de estos y luego vas a obtener los detalles de la publicación de la tabla de publicaciones con esa intersección.

Como ejemplo, coloque 30,000 productos en WooCommerce, y terminará con ~ 1,800,000 filas en wp_postmeta como se explica en la respuesta a continuación:

Publicar meta vs tablas de bases de datos separadas

Por lo tanto, no solo esto hará que la búsqueda sea muy ineficiente (especialmente cuando se une por sí mismo en wp_postmeta para múltiples criterios), sino que incluso consultar una sola fila de entre 1,8 mil filas causa un impacto en el rendimiento.

Deficiencia del esquema EAV.

Entonces, con muchas publicaciones, la implementación de WordPress db hace que las búsquedas complejas sean muy lentas.

Ejecutar un sitio de WordPress con miles de publicaciones es bastante factible si usa complementos de almacenamiento en caché. Puedes ir aún más. Pero las búsquedas serán un problema.

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

Lo mismo ocurre con los usuarios: wp_usermeta también usa el mismo formato EAV. Entonces, si obtiene muchos usuarios y tiene muchos complementos que almacenan varios datos de usuario en wp_usermeta, tendrá el mismo impacto en el rendimiento.

Sin mencionar que con tantos usuarios es probable que ya tenga una gran cantidad de publicaciones, a menos que su aplicación sea algo que tenga que ver principalmente con los usuarios (CRM, etc.), y elija almacenar sus datos de usuario en wp_usermeta en lugar de wp_postmeta . (Aunque poco probable).

.........

Hay algunos complementos que intentan solucionar este problema, como Meta Accelerator.

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

Este complemento toma los datos de cualquier tipo de publicación que elija y los coloca en tablas planas. Esto acelera mucho la búsqueda, y también acelera la consulta de cualquier valor singular.

Pero ese complemento aún está en su infancia.

Alternativamente, puede instalar ElasticSearch en el servidor y usar el complemento ElasticPress u otro complemento que lo integre a WordPress para acelerar dichas búsquedas.

Creo que puedes ejecutar incluso más usuarios. Lo único que puede limitarlo es su servidor. Tendrá que escalarlo correctamente, especialmente el servidor MySQL. Por ejemplo, wordpress.comejecuta incluso más de 40000 usuarios, pero usan sistemas extra potentes para estabilidad, toneladas de equilibradores de carga, etc.

La pregunta debería ser cuántos usuarios pueden manejar la pila php-mysql en lugar de WordPress a medida que WP se desarrolla en esas 2 tecnologías principales.

Dicho esto, si puede configurar el servidor con técnicas avanzadas de servidor, aloje WP en un buen servidor administrado, carga optimizada de la base de datos y consultas, entonces WP puede manejar tantos miembros como desee.

Si instala WordPress en un alojamiento compartido, entonces está limitando su capacidad de WP. Por otro lado, si puede administrar usted mismo ejecutando WP desde un servidor de alojamiento dedicado o basado en la nube, entonces debería obtener el resultado deseado.

Wordpress es capaz de manejar canteras de bases de datos complejas. Puede consultar este https://codex.wordpress.org/Installing_WordPress

El uso de Wordpess también como un marco avanzado de desarrollo de aplicaciones le permite realizar su instalación para manejar una carga de base de datos grande / compleja.

También puede ver esta serie: http://code.tutsplus.com/articles/using-wordpress-for-web-application-development-wp_user_query--wp-35015

Espero que esto ayude. Gracias

He encontrado el cuello de botella para cuántos usuarios de Wordpress puede tener es el tiempo de espera de PHP que entra en juego en la página de administración de usuarios.

Suponiendo que todos sus usuarios tengan al menos 1 rol, tienen una wp_capabilitiesentrada en la user_metadatatabla con una matriz serializada de roles.

La página de administración muestra un recuento de cuántos usuarios con cada tipo de rol hay, por lo que debe cargar cada matriz serializada wp_capabilities, deserializar eso y luego mostrar un recuento total.

Cuando tengo 300,000 usuarios, la página de administración de usuarios tarda 44 segundos en construirse.

Esto significa que cada usuario agrega 0.00014666666 segundos al tiempo de carga de la página.

Suponiendo que su tiempo de espera de PHP sea de 60 segundos, el límite sería de alrededor de 400,000 usuarios.

Sin embargo, estoy ejecutando un servidor bastante viejo y lento. Un hardware más rápido mejoraría mucho las cosas.