solutions problems optimisation mathematical and optimization

problems - optimization or optimisation



¿Cuáles son las solicitudes "promedio" por segundo para una aplicación web de producción? (8)

No tengo un marco de referencia en términos de lo que se considera "rápido"; Siempre me he preguntado esto, pero nunca he encontrado una respuesta directa ...

Cuando voy al panel de control de mi servidor web, abro phpMyAdmin y hago clic en "Mostrar información de tiempo de ejecución de MySQL", obtengo:

Este servidor MySQL ha estado funcionando durante 53 días, 15 horas, 28 minutos y 53 segundos. Comenzó el 24 de octubre de 2008 a las 04:03 a.m.

Estadísticas de consulta: desde su inicio, se han enviado 3.444.378.344 consultas al servidor.

Total 3,444 M
por hora 2.68 M
por minuto 44.59 k
por segundo 743.13

¡Es un promedio de 743 consultas mySQL cada segundo durante los últimos 53 días!

No sé ustedes, ¡pero para mí eso es rápido! ¡¡Muy rapido!!

Esa es una pregunta muy abierta de manzanas a naranjas.

Usted está preguntando 1. la carga de solicitud promedio para una aplicación de producción 2. lo que se considera rápido

Estos no necesariamente se relacionan.

Su número promedio de solicitudes por segundo está determinado por

a. la cantidad de usuarios simultáneos

segundo. el número promedio de solicitudes de página que realizan por segundo

do. el número de solicitudes adicionales (es decir, llamadas ajax, etc.)

En cuanto a lo que se considera rápido ... ¿quiere decir cuántas pocas solicitudes puede tomar un sitio? ¿O si una pieza de hardware se considera rápida si puede procesar xyz # de solicitudes por segundo?

No estoy seguro de que alguien todavía esté interesado, pero esta información se publicó en Twitter (y aquí también ):

Las estadísticas

  • Más de 350,000 usuarios Los números reales son, como siempre, súper súper alto secreto.
  • 600 solicitudes por segundo.
  • Promedio de 200-300 conexiones por segundo. Aumentando a 800 conexiones por segundo.
  • MySQL manejó 2.400 solicitudes por segundo.
  • 180 instancias de Rails. Utiliza Mongrel como el servidor "web".
  • 1 servidor MySQL (un gran cuadro de 8 núcleos) y 1 esclavo. El esclavo se lee solo para estadísticas e informes.
  • Más de 30 procesos para manejar trabajos impares.
  • 8 Sun X4100s.
  • Procesar una solicitud en 200 milisegundos en Rails.
  • El tiempo promedio que se pasa en la base de datos es de 50 a 100 milisegundos.
  • Más de 16 GB de memcached.

Personalmente, me gusta tanto el análisis hecho cada vez ... solicitudes / segundos y el tiempo / solicitud promedio y me encanta ver el tiempo máximo de solicitud además de eso. es fácil voltear si tiene 61 solicitudes / segundo, luego puede voltearlo a solicitudes de 1000ms / 61.

Para responder a su pregunta, hemos estado haciendo una prueba de carga enorme y encontramos que varía en varios equipos amazónicos que usamos (el mejor valor fue la CPU media de 32 bits cuando se redujo a $$ / evento / segundo) y nuestras solicitudes / segundos varió de 29 solicitudes / segundo / nodo hasta 150 solicitudes / segundo / nodo.

Dar mejor hardware, por supuesto, ofrece mejores resultados, pero no el mejor retorno de la inversión. De todos modos, esta publicación fue excelente, ya que estaba buscando algunos paralelos para ver si mis números estaban en el estadio de béisbol y compartía los míos también en caso de que alguien más estuviera buscando. El mío está puramente cargado tan alto como puedo.

NOTA: gracias a request / second analysis (no ms / request) encontramos un gran problema de Linux que estamos tratando de resolver donde linux (probamos un servidor en C y java) congela todas las llamadas en bibliotecas de socket cuando hay demasiada carga que parece muy extraño. La publicación completa se puede encontrar aquí en realidad ... http://ubuntuforums.org/showthread.php?p=11202389

Todavía estamos tratando de resolver eso, ya que nos da un gran impulso en el rendimiento ya que nuestra prueba va de 2 minutos 42 segundos a 1 minuto 35 segundos cuando esto se soluciona, por lo que vemos una mejora del 33% en la performance ... sin mencionar, cuanto peor es el ataque DoS, más largas son estas pausas para que todas las CPUs lleguen a cero y dejen de procesarse ... en mi opinión, el procesamiento del servidor debe continuar frente a un DoS, pero por alguna razón, se congela de vez en cuando. durante el Dos a veces hasta 30 segundos !!!

ADDICIÓN: descubrimos que en realidad era un error de condición de carrera jdk .... difícil aislar en clústeres grandes, pero cuando ejecutamos 1 nodo de datos de servidor 1 pero 10 de ellos, podíamos reproducirlo cada vez y luego solo mirar el servidor / datanode en que ocurrió. Cambiar el jdk a una versión anterior solucionó el problema. Estábamos en jdk1.6.0_26 Yo creo.

Puede buscar "análisis de efecto slashdot" para ver gráficos de lo que vería si algún aspecto del sitio se hiciera popular de repente en las noticias, por ejemplo, este gráfico en wiki .

Las aplicaciones web que sobreviven tienden a ser las que pueden generar páginas estáticas en lugar de presentar cada solicitud a través de un lenguaje de procesamiento.

Hubo un excelente video (creo que podría haber sido en ted.com, creo que podría haber sido por el equipo de flickr web? ¿Alguien sabe el enlace?) Con ideas sobre cómo escalar sitios web más allá del servidor único, por ejemplo, cómo asigne conexiones entre la mezcla de servidores de solo lectura y de lectura y escritura para obtener el mejor efecto para varios tipos de usuarios.

Tenga en cuenta que los gráficos de frecuencia de aciertos serán patrones sinusoidales con "horas pico" tal vez 2x o 3 veces la velocidad que obtiene mientras los usuarios duermen. (Puede ser útil cuando programe el procesamiento diario de lotes para que ocurra en los servidores)

Puedes ver el efecto incluso en sitios ''internacionales'' (multilingües, localizados) como wikipedia

menos de 2 segundos por usuario por lo general, es decir, los usuarios que ven respuestas más lentas que esta piensan que el sistema es lento.

Ahora dime cuántos usuarios has conectado.