¿Cuáles son los límites de rendimiento teóricos en los servidores web?

Question

En un servidor web actualmente implementado, ¿cuáles son los límites típicos de su rendimiento?

Creo que una respuesta significativa sería una de 100, 1,000, 10,000, 100,000 o 1,000,000 de solicitudes/segundo, pero ¿cuál es el verdadero hoy? ¿Cuál fue verdad hace 5 años? ¿Qué podríamos esperar en 5 años? (es decir, cómo afectan las tendencias del ancho de banda, el rendimiento del disco, el rendimiento de la CPU, la respuesta)

Si es material, se debe considerar el hecho de que HTTP sobre TCP es el protocolo de acceso. Deben asumirse que el sistema operativo, el lenguaje del servidor y los efectos del sistema de archivos son los mejores de su clase.

Supongamos que el disco contiene muchos pequeños archivos únicos que se sirven de forma estática. Tengo la intención de eliminar el efecto de las memorias caché de memoria, y ese tiempo de CPU se usa principalmente para ensamblar la información de red/protocolo. Estas suposiciones pretenden desviar la respuesta hacia las estimaciones del 'peor caso' cuando una solicitud requiere algo de ancho de banda, algo de tiempo de CPU y acceso al disco.

Solo busco algo con un orden de magnitud aproximado.

Answer 1

Lee http://www.kegel.com/c10k.html. También puede leer StackOverflow questions tagged 'c10k'. C10K significa 10,000 clientes simultáneos.

Resumen breve: principalmente, el límite no es ni ancho de banda ni CPU. Es concurrencia.

Answer 2

Creo que hay demasiadas variables aquí para responder a su pregunta.

Qué procesador, qué velocidad, qué caché, qué chipset, qué interfaz de disco, qué velocidad de giro, qué tarjeta de red, cómo se configura, la lista es enorme. Creo que debe abordar el problema desde el otro lado ...

"Esto es lo que quiero hacer y lograr, ¿qué debo hacer?"

Answer 3

Esto dependerá de cuál es el núcleo de su CPU ¿Qué velocidad tienen sus discos? ¿Qué es un canal de empresas de alojamiento de tamaño 'gordo' 'mediano'? ¿Qué es el servidor web?

La pregunta es demasiado general

Deploy prueba del servidor usando herramientas como http://jmeter.apache.org/ y ver cómo le va.

Answer 4

El sistema operativo, el idioma del servidor y los efectos del sistema de archivos son las variables aquí. Si los saca, entonces quedará con un socket TCP sin gastos generales.

En ese momento, no se trata en realidad del rendimiento del servidor, sino de la red. Con un socket TCP sin límite, el límite que alcanzará probablemente se encuentre en el firewall o su red cambiará con cuántas conexiones se pueden manejar simultáneamente.

Answer 5

Creo que realmente depende de lo que está sirviendo.

Si está sirviendo aplicaciones web que rinden html dinámicamente, la CPU es lo que más se consume.

Si va a servir a un número relativamente pequeño de artículos lotes estáticos y un montón de veces, es probable que tenga problemas de ancho de banda (ya que los archivos estáticos a sí mismos, probablemente se encontrarán en la memoria)

Si' Al servir una gran cantidad de elementos estáticos, puede ejecutar primero límites de disco (buscar y leer archivos)

Answer 6

En cualquier aplicación web que utilice una base de datos, también se abre una gama completamente nueva de necesidades de optimización.

índices, etc consulta optimización

de archivos estáticos, que hace su caché de la aplicación en la memoria?

etc, etc, etc

Answer 7

Si usted no es capaz de almacenar en caché los archivos en la memoria, entonces el disco tiempos de búsqueda será probablemente el factor limitante y limitar su rendimiento a menos de 1.000 peticiones/segundo. Esto podría mejorar al usar discos de estado sólido.

Answer 8

Hace seis años, vi un 8-proc Windows Server 2003 cuadro servir 100.000 solicitudes por segundos para contenido estático. Esa caja tenía 8 tarjetas Gigabit Ethernet, cada una en una subred separada. El factor limitante fue el ancho de banda de la red. No hay forma de que pueda servir tanto contenido a través de Internet, incluso con una tubería verdaderamente enorme.

En la práctica, para el contenido puramente estático, incluso una caja modesta puede saturar una conexión de red.

Para contenido dinámico, no hay una respuesta fácil. Puede ser utilización de CPU, E/S de disco, latencia de base de datos de back-end, no suficientes hilos de trabajo, demasiada conmutación de contexto, ...

Tiene que medir su aplicación para saber dónde están sus cuellos de botella. Podría estar en el marco, podría estar en su lógica de aplicación. Probablemente cambia a medida que cambia su carga de trabajo.

Answer 9

100, 1,000, 10,000, 100,000 o 1,000,000 de solicitudes/segundo, pero ¿cuál es el verdadero hoy?

Esta prueba se realizó en un ordenador portátil i3 modesta, pero revisó barniz, ATS (Apache tráfico del servidor), Nginx, Lighttpd, etc.

http://nbonvin.wordpress.com/2011/03/24/serving-small-static-files-which-server-to-use/

El punto interesante es que el uso de una de gama alta servidor 8-core da una muy poco de impulso a la mayoría de ellos (Apache, Cherokee, Litespeed, Lighttpd, Nginx, G-WAN):

http://www.rootusers.com/web-server-performance-benchmark/

Como las pruebas se realizaron en localhost para evitar golpear la red como un cuello de botella, el problema está en el núcleo que no escala, a menos que usted tune its options.

Por lo tanto, para responder a su pregunta, el margen de progreso está en la forma en que los servidores procesan IO. Tendrán que usar mejores estructuras de datos (sin esperar).