No tengo un marco de referencia en términos de lo que se considera "rápido"; Siempre me había preguntado esto, pero nunca había encontrado una respuesta directa ...
optimization
capotej
fuente
fuente
Respuestas:
OpenStreetMap parece tener 10-20 por segundo
Wikipedia parece estar entre 30000 y 70000 por segundo distribuidas en 300 servidores (de 100 a 200 solicitudes por segundo por máquina, la mayoría de las cuales son cachés)
Geograph obtiene 7000 imágenes por semana (1 carga cada 95 segundos)
fuente
No estoy seguro de que alguien todavía esté interesado, pero esta información se publicó sobre Twitter (y aquí también ):
fuente
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:
¡Eso 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!!
fuente
personalmente, me gusta tanto el análisis realizado cada vez ... solicitudes / segundo y tiempo promedio / solicitud y me encanta ver el tiempo máximo de solicitud también. es fácil cambiarlo si tiene 61 solicitudes / segundo, luego puede cambiarlo a 1000ms / 61 solicitudes.
Para responder a su pregunta, hemos estado haciendo una gran prueba de carga nosotros mismos y encontramos que varía en varios hardware de Amazon que usamos (el mejor valor fue la CPU mediana de 32 bits cuando se redujo a $$ / evento / segundo) y nuestras solicitudes / segundos osciló entre 29 solicitudes / segundo / nodo hasta 150 solicitudes / segundo / nodo.
Ofrecer un mejor hardware, por supuesto, da mejores resultados, pero no el mejor ROI. De todos modos, esta publicación fue excelente, ya que estaba buscando algunos paralelos para ver si mis números estaban en el estadio y también compartían los míos en caso de que alguien más estuviera mirando. La mía está puramente cargada tan alto como puedo.
NOTA: gracias a las solicitudes / segundo análisis (no a ms / solicitud) encontramos un problema importante 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 está bajo demasiada carga lo 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 rendimiento del 33% ... sin mencionar, cuanto peor es el ataque DoS, más largas son estas pausas para que todos los cpus caigan a cero y dejen de procesar ... en mi opinión, el procesamiento del servidor debería continuar frente a un DoS, pero por alguna razón, se congela de vez en cuando durante el Dos a veces hasta 30 segundos !!!
ADICIÓN: Descubrimos que en realidad era un error de condición de carrera de jdk ... difícil de aislar en grandes clústeres, pero cuando ejecutamos 1 nodo de datos del servidor 1 pero 10 de esos, pudimos reproducirlo cada vez que lo hicimos y solo miramos el servidor / datanode en el que ocurrió. Cambiar el jdk a una versión anterior solucionó el problema. Estábamos en jdk1.6.0_26, creo.
fuente
Ese es un tipo de pregunta muy abierta.
Estás preguntando 1. la carga de solicitud promedio para una aplicación de producción 2. qué se considera rápido
Estos no se relacionan necesariamente.
Su número promedio de solicitudes por segundo está determinado por
a. el número de usuarios simultáneos
si. el número medio de solicitudes de página que realizan por segundo
C. la cantidad de solicitudes adicionales (es decir, llamadas ajax, etc.)
En cuanto a lo que se considera rápido ... ¿te refieres a las pocas solicitudes que puede aceptar un sitio? ¿O si una pieza de hardware se considera rápida si puede procesar xyz # de solicitudes por segundo?
fuente
Tenga en cuenta que los gráficos de tasa de aciertos serán patrones sinusoidales con 'horas pico' tal vez 2 veces o 3 veces la tasa que obtiene mientras los usuarios duermen. (Puede ser útil cuando está programando el procesamiento por lotes diario para que suceda en los servidores)
Puede ver el efecto incluso en sitios 'internacionales' (multilingües, localizados) como wikipedia
fuente
menos de 2 segundos por usuario por lo general, es decir, los usuarios que ven respuestas más lentas piensan que el sistema es lento.
Ahora dime a cuántos usuarios has conectado.
fuente
Puede buscar en el "análisis del efecto de slashdot" 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 someter cada solicitud a un lenguaje de procesamiento.
Hubo un video excelente (creo que podría haber estado en ted.com? Creo que podría haber sido del equipo web de flickr? ¿Alguien conoce el enlace?) Con ideas sobre cómo escalar sitios web más allá del servidor único, por ejemplo, cómo asigne conexiones entre la combinación de servidores de solo lectura y de lectura y escritura para obtener el mejor efecto para varios tipos de usuarios.
fuente