linux - mp3tag - mp3 tag español
¿Hay alguna revisión moderna de soluciones para el problema de 10000 clientes/segundo? (7)
(Comúnmente llamado el problema C10K)
¿Existe una revisión más contemporánea de las soluciones al problema c10k (Última actualización: 2 de septiembre de 2006), específicamente enfocada en Linux (epoll, signalfd, eventfd, timerfd ..) y bibliotecas como libev o libevent?
¿Algo que discute todos los problemas resueltos y aún no resueltos en un servidor Linux moderno?
Casualmente, hace solo unos días, Programming Reddit o quizás Hacker News mencionaron esta pieza:
En los primeros días de Java, mis amigos de la programación C se reían de mí por hacer socket IO con hilos de bloqueo; en ese momento, no había alternativa. En estos días, con abundante memoria y procesadores, parece ser una estrategia viable.
El artículo está fechado en 2008, por lo que aumenta su horizonte en un par de años.
Eche un vistazo al proyecto RamCloud en Stanford: https://ramcloud.atlassian.net/wiki/display/RAM/RAMCloud
Su objetivo es 1,000,000 de operaciones RPC / seg / servidor. Tienen numerosos puntos de referencia y comentarios sobre los cuellos de botella que están presentes en un sistema que les impediría alcanzar sus objetivos de rendimiento.
El problema C10K generalmente supone que está tratando de optimizar un solo servidor, pero como su artículo hace referencia señala que "el hardware ya no es el cuello de botella". Por lo tanto, el primer paso es asegurarse de que no sea más fácil y barato simplemente lanzar más hardware en la mezcla.
Si tenemos una caja de $ 500 que atiende a X clientes por segundo, es mucho más eficiente comprar otra caja de $ 500 para duplicar nuestro rendimiento en lugar de dejar que un empleado engulle quién sabe cuántas horas y dólares tratando de averiguar cómo exprimir más fuera de la caja original. Por supuesto, eso es asumiendo que nuestra aplicación es amigable para varios servidores, que sabemos cómo cargar el equilibrio, etc., etc.
Para responder a la pregunta de OP, podría decir que hoy el documento equivalente no trata sobre la optimización de un solo servidor para la carga, sino la optimización de todo su servicio en línea para la carga. Desde esa perspectiva, el número de combinaciones es tan grande que lo que está buscando no es un documento, es un sitio web en vivo que recopila dichas arquitecturas y marcos. Tal sitio web existe y se llama www.highscalability.com
Nota lateral 1:
Argumentaría en contra de la creencia de que tirar más hardware es una solución a largo plazo:
Quizás el costo de un ingeniero que "obtiene" rendimiento es alto en comparación con el costo de un solo servidor. ¿Qué pasa cuando escalas? Digamos que tienes 100 servidores. Una mejora del 10 por ciento en la capacidad del servidor puede ahorrarle 10 servidores por mes.
Incluso si solo tiene dos máquinas, aún necesita controlar los picos de rendimiento. La diferencia entre un servicio que se degrada gratamente bajo carga y otro que se descompone es que alguien pasó tiempo optimizando para el escenario de carga.
Nota al margen 2
El tema de esta publicación es ligeramente engañoso. El documento CK10 no intenta resolver el problema de 10k clientes por segundo. (El número de clientes por segundo es irrelevante a menos que también defina una carga de trabajo junto con un rendimiento sostenido bajo latencia acotada. Creo que Dan Kegel lo sabía cuando escribió ese documento). Mírelo en su lugar como un compendio de enfoques para construir servidores simultáneos y micro-puntos de referencia para el mismo. Quizás lo que ha cambiado desde entonces hasta ahora es que podría suponer en un momento dado que el servicio era para un sitio web que ofrecía páginas estáticas. Hoy el servicio podría ser un datastore noSQL, un caché, un proxy o uno de los cientos de piezas de software de infraestructura de red.
También puedes echarle un vistazo a esta serie de artículos:
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3
Muestra una buena cantidad de datos de rendimiento y el trabajo de configuración del sistema operativo que tuvo que hacer para admitir conexiones de 10K y luego de 1M.
Parece que un sistema con 30 GB de RAM podría manejar 1 millón de clientes conectados en una especie de tipo de red social de simulación, usando un frontend libevent para un servidor de aplicaciones basado en Erlang.
libev ejecuta algunos puntos de referencia contra ellos mismos y libevent ...
Recomiendo la poll, epoll, science, and superpoll Reading Zed Shaw poll, epoll, science, and superpoll [1]. Por qué epoll no siempre es la respuesta, y por qué a veces es incluso mejor ir con encuestas, y cómo sacar lo mejor de ambos mundos.