Sé que esta es una pregunta horrible y generalizada sin una buena respuesta, y me disculpo de antemano, pero me pregunto si alguien podría intentar hacer una estimación muy amplia.
Supongamos que tiene un servidor MySQL dedicado que se ejecuta en hardware moderno por un valor aproximado de 1.000 dólares.
Digamos que el usuario promedio realiza 20 solicitudes de lectura y 5 solicitudes de escritura por minuto: todas consultas sencillas, sin uniones; principalmente en la línea de 'seleccionar esta fila por UUID' de una tabla indexada de ~10,000,000 de filas.
Muy, muy, muy, muy aproximadamente, cuántos usuarios simultáneos esperaría que manejara un servidor como ese antes de "impulsarlo".
Respuesta1
Como habrás notado, esta es una estimación muy amplia.
La gran pregunta es para qué se usan esos $1000. Siempre que busque un poco más de memoria y menos potencia de procesador con un disco duro promedio, diría que una aplicación razonablemente codificada (donde sea razonable = usando principalmente cualquier biblioteca de abstracción que proporcione su lenguaje) con esos parámetros debería poder manejar alrededor de 500 usuarios concurrentes. Habría adivinado más, excepto por el tamaño del conjunto de filas (ya que cuantas más filas quepan directamente en la RAM, menos irá al disco tendrá que hacer incluso para escrituras inmediatas).
El tipo de datos que hay en las filas y la cantidad de RAM que puede permitirse serán sin duda los factores más importantes en este escenario. Si pudiera arreglárselas con menos escrituras y reducir el tamaño de la tabla indexada, creo que podría salirse con la suya con 1000 usuarios simultáneamente.
Los dos problemas que verás:
La cantidad de datos que puede almacenar en caché en la RAM y, por lo tanto, la cantidad de RAM que tiene por encima del mínimo necesario para ejecutar las operaciones básicas del sistema operativo y del servidor de bases de datos determinarán lo que puede hacer. Más RAM, menos necesidades de sistema operativo y una cantidad menor de datos útiles que deben mantenerse en la RAM para consultas y escrituras significarán la diferencia entre un rendimiento aceptable y mucha, mucha paliza.
El diseño de su aplicación es absolutamente crítico aquí. Una escritura repartida entre 500 y 1000 usuarios tiene un impacto enorme. Del mismo modo, si sus llamadas no son simples y eficientes, rápidamente provocará un choque de trenes. Basé mi estimación en varias aplicaciones MySQL que he visto en funcionamiento, con un poco de conocimiento de cómo funcionan. Si la aplicación tiene problemas fundamentales, es posible que ni siquiera llegue a 40 usuarios. Si lo codifica de manera eficiente y tiene en cuenta los límites del hardware, podrá escalar más allá de 2000 fácilmente.
Respuesta2
Puedo responder eso. Acabo de bajarme de ese viaje y volveré a viajar.
Entre 650 y 800 dólares se puede comprar un AMD de cuatro núcleos y velocidad moderada con 8 GB de RAM y una unidad SATA2 de 1 TB. Con 170 dólares se puede comprar una segunda unidad relativamente rápida de 1 TB. Tenga en cuenta que se trata de hardware disponible en la mayoría de los lugares del tipo de electrónica/oficina/best-buy. Puedes obtener más beneficios en otros lugares, pero no está mal por el dinero. Puedes conseguir un quad core más rápido por poco más.
Ahora, con respecto a la aplicación, asumiré que estás ejecutando Linux/BSD/Unix para el sistema operativo y evitaré el debate entre ms y Unix. Esto es lo que encontré:
No tenemos problemas para especificar más de 200 usuarios/sesiones activas en cualquiera de nuestras aplicaciones sin parpadear, sin importar cuán débil sea la aplicación. De hecho, no hemos podido soltar/bloquear/atascar una aplicación en ningún servidor de cuatro núcleos que hayamos ejecutado durante algún tiempo... pero aprendimos algunas lecciones en los días de los 200 mhz de un solo núcleo.
Por ejemplo, nuestra empresa hermana vende bastantes sistemas de monitoreo de comunicaciones basados en MySQL con más de 1300 usuarios por máquina y, en promedio, varios cientos de sesiones simultáneas por hora. El registro y los informes se realizan en tiempo real (bueno, se produce algo de almacenamiento en búfer) y se han estado ejecutando en máquinas de doble núcleo de 3 Ghz en [jadeo] unidades PATA lentas... De hecho, unidades P-ata de 133 Mhz. El retraso más largo en la interfaz de usuario fue de aproximadamente 2 segundos. Dejaron MSSQL por MySQL hace una década e inmediatamente obtuvieron resultados.
Tenga en cuenta que estas máquinas ejecutan aplicaciones web + bases de datos... así que haga los cálculos. Simplemente funciona. Además, reemplacé varias aplicaciones Oracle/MS/xxxx con estas y nunca estuve cerca de quedarme sin fuerzas. Además, permítanme ampliar lo que dijo el otro desde la perspectiva de un dba... Aquí hay 6 consejos desde las trincheras.
- Las escrituras acabarán con el rendimiento, especialmente si la penalización por bloqueo es un concepto extraño para sus codificadores.
- Hacer todo en una mesa enorme te matará.
- La normalización excesiva no es tu amiga. Si sus codificadores están completando la tercera forma normal, su aplicación funcionará mal. Los datos desnormalizados ocupan más espacio, pero permiten lograr grandes cosas con consultas simples.
- Una mesa grande se ahogará con escrituras frecuentes. Ver 1.
- Si escribe su aplicación para usar una (o más) tablas para mostrar datos y una tabla diferente para escrituras que se puede sincronizar con las tablas de lectura cuando las cargas del sistema lo permitan, puede salirse con la suya con todo tipo de cosas. Usamos una pequeña cantidad de tablas para almacenar en búfer las escrituras y podemos hacer frente a una increíble cantidad de transacciones porque nadie es pisoteado.
- Utilice índices. De todos modos, si sabe qué partes de las consultas se utilizan como claves.
- Ajuste la instalación de la base de datos en función de la memoria. Consulte los documentos de MySQL en línea. A decir verdad, si tiene menos de 1000 sesiones activas, a menudo puede aumentar el número de conexiones y hacerlo. http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html
Puedes ver SQL estúpido en acción mirando la mayoría de WordPress/etc. complementos. La mayoría están escritos por personas que no entienden SQL, y pondrán un servidor de rodillas en poco tiempo con sólo un puñado de usuarios.
Respuesta3
Servidor de $884, 8 GB de RAM, xeon dual quadcore, unidad SATA de 300 GB a 7200 rpm, 40 % inactivo, 5 % iowait
Uptime: 780727 Threads: 276 Questions: 1884267879 Slow queries: 3964303 Opens: 60474
Flush tables: 1 Open tables: 440 Queries per second avg: 2413.478
mientras sirve 220mb/seg