Quiero diseñar un sitio de inicio de sesión de miembro en WP, pero tengo una duda de que WordPress puede manejar más de 40000 usuarios en la misma base de datos.
No estoy seguro de esto, así que estoy deteniendo mi trabajo aquí. Así que, si alguien sabe exactamente sobre esto, ayúdeme a continuar mi proyecto con WP.
Creo que puedes correr incluso más usuarios.
Lo único que puede limitarte es tu servidor. Tendrás que escalarlo correctamente, especialmente el servidor MySQL. Por ejemplo, wordpress.com ejecuta incluso más de 40000 usuarios, pero utilizan sistemas extra poderosos para la estabilidad, toneladas de balanceadores de carga y etc.
Es un poco tarde para responder a esto, pero como viene para 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 mantienen en tablas separadas)
Para explicarlo desde el ángulo de datos:
Junto con los detalles relacionados directamente a la publicación en wp_posts, numerosos meta se publican 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), es bastante lento buscar cualquier propiedad que se encuentre en el meta. Primero busca en todas las entradas en la tabla meta para los criterios que necesitas, luego obtén la publicación relevante de la tabla. Lo bueno es que necesitas buscar CADA criterio por separado. Entonces, una búsqueda de etiqueta, obtiene las publicaciones con el valor X para 'meta1', luego busca el segundo criterio, por ejemplo, customcriteria y obtiene las ID de las publicaciones con customcriteriavalue1 en customcriteria, Y luego toma la intersección de estas y luego va 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 siguiente respuesta:
Tablas de bases de datos posteriores a la comparación meta / meta
Por lo tanto, no solo esto hará que la búsqueda sea muy ineficiente (especialmente cuando realiza uniones automáticas en wp_postmeta para múltiples criterios), sino que incluso la consulta de una sola fila de entre 1,8 mil filas provoca un impacto en el rendimiento.
Deficiencia del esquema EAV.
Entonces, con una gran cantidad de publicaciones, la implementación de WordPress db hace que las búsquedas complejas sean muy lentas.
La ejecución de un sitio de WordPress con miles de publicaciones es bastante factible, si utiliza complementos de almacenamiento en caché. Puedes ir aún más. Pero las búsquedas serán un problema.
............
Es lo mismo con los usuarios también: 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 de rendimiento.
Por no mencionar con tantos usuarios, es probable que ya tenga un gran número de publicaciones, a menos que su aplicación sea algo que tenga que ver con los usuarios en su mayoría (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.
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 plugin está en su infancia todavía.
Alternativamente, puede instalar ElasticSearch en el servidor y usar el complemento ElasticPress u otro complemento que lo integre en WordPress para acelerar dichas búsquedas.
Encontré el cuello de botella para cuántos usuarios de Wordpress puedes 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 tienen al menos 1 rol, tienen una entrada wp_capabilities en la tabla user_metadata 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 tiene que cargar cada una de las matrices serializadas 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 el tiempo de espera de PHP es 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.
La pregunta debería ser cuántos usuarios pueden manejar la pila de 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 de servidor avanzadas, hospede el WP en un servidor bien administrado, la carga optimizada de la base de datos y las consultas, entonces el 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 administrarse ejecutando WP desde un servidor de alojamiento dedicado o basado en la nube, debería obtener el resultado deseado.
Wordpress es capaz de manejar canteras de bases de datos complejas. Puede consultar este enlace
El uso de wordpess como marco de desarrollo avanzado de aplicaciones le permite realizar su instalación para manejar una carga de base de datos grande / compleja.
también puede realizar esta serie: enlace
Espero que esto ayude. gracias
Lea otras preguntas en las etiquetas database users membership