¿Qué lenguaje de programación debo elegir para mi servicio web de alto rendimiento?

Question

Estoy en proceso de crear una API de servicio web para mi aplicación. Además, estoy planeando exponer el Servicio a través de REST y SOAP.

Estoy interesado en obtener algunos comentarios de la comunidad sobre qué lenguaje de programación debería elegir para implementar el servicio? (Sé que C#, Java y Ruby - RoR son lo suficientemente buenos para crear el servicio).

El servicio es principalmente un servicio HTTP POST. Necesitará manejar alrededor de 2000 conexiones simultáneas, así como ser capaz de manejar alrededor de 10.000 HTTP POST por segundo. (para SOAP tendremos un método de envío para que los clientes llamen).

El servicio no devuelve ninguna respuesta al cliente para las solicitudes POST.

¿Alguna idea sobre qué lenguaje de programación/arquitectura se debe usar?

Answer 1

10,000 solicitudes por segundo son 25 mil millones de aciertos por mes. Eso significa una de dos cosas:

1. Su aplicación es más popular que MySpace; o
2. Usted está tratando de usar esto para comunicarse entre dos muy componentes parlantes que usted controla, y es una opción de diseño horrible horrible.

El hardware de conmutación solo para distribuir tanta carga en una granja de front-ends web costaría miles de dólares.

Comience por escribir un servicio web que pueda gestionar 50 solicitudes por segundo (la elección del idioma no es muy relevante). Si su aplicación está tan ocupada que cruza ese umbral con regularidad, puede permitirse el lujo de contratar a alguien para que trabaje en el problema de escala de tiempo completo, y no tener que pedir ayuda en un sitio gratuito Q & A.

Answer 2

Realmente puede usar cualquier idioma a través de CGI (Common Gateway Interface), por lo que se reduce al rendimiento. Entre los idiomas que lista, espero que C# sea el más rápido. Una buena comparación de la velocidad entre los idiomas es The Language Shootout

Si realmente rendimiento de necesidad es posible que desee mirar en la dirección de un lenguaje orientado al rendimiento más como C o D para manejar las peticiones.

Todo depende de qué tipo de cálculo tenga que realizar realmente cada solicitud.

Answer 3

En 10,000 publicaciones por segundo, el idioma es la menor de tus preocupaciones. Un problema mucho más grande sería el diseño de su granja de servidores y su red. Supongo que no planea ejecutar esto en una sola caja.

Answer 4

Actualización: Su intención es ser un fuego y olvidarse del servicio web. Supongo que enviaré una respuesta HTTP 200/OK simple

No, esto no está destinado a ejecutarse en una sola caja. Está destinado a ejecutarse en algunas cajas (digamos 3-4).

Cuando se reciben las solicitudes, se envían a la cola en otras máquinas, luego se toman y se colocan en una Tienda HBase/Voldemort.

Como he dicho, que va a ser un "dispara y olvida" servicio web

Answer 5

aplicaciones altamente escalables, fiables, distribuidos, y el uso de los sistemas multinúcleo/multiprocesador? Aquí inmediatamente pienso en Erlang/OTP junto con Yaws como servidor de aplicaciones web. El pian se ejecuta extremadamente estable y rápido bajo una carga extremadamente alta. Y Erlang/OTP, ya que la plataforma está diseñada para concurrencia y distribución, junto con algunos mecanismos que ayudan a desarrollar software estable. Los costos: la orientación de concurrencia con un lenguaje de programación funcional no es OOP con Java o C#, la sintaxis parece extraña (pero es muy directa y poderosa una vez que la has adoptado), y la cantidad de bibliotecas de terceros no es tan grande en cuanto a los idiomas principales. Pero vale la pena.

Esperanza esto ayuda

mue

Answer 6

A ese ritmo, y ya que está rompiendo todos modos HTTP (sin respuesta) que también podría desarrollar su propio servidor, o modificar un servidor de código abierto.

Escríbelo todo en C o C++ y estará lo más rápido posible.

Sin embargo, la escalabilidad se ve afectada por algo más que la elección del idioma.

-Adam

Answer 7

Se necesita un C llike lengua y para evitar escribir un servidor completo que sugiere CGI (que es lo que php y similares, todos ejecutar a través de todos modos) servidores Windows ofrecer plug-ins ISAPI, pero estos se ejecuta en el contexto del servidor para que la memoria pierda y los archivos GPF eliminen el servidor. A esto se añade la inconveniencia de detener/iniciar el servidor cada vez que cambia algo, CGI/FastCGI se ve mejor.

Answer 8

Pude obtener un billón de mensajes por mes en una sola máquina. Tengo un servicio web escrito en C# que actualmente maneja aproximadamente 3,5 millones de publicaciones por día. El servidor web se ejecuta con un 3% de utilización de la CPU. Lo que significa que podría presionarlo al menos 20 veces más ...

Suponiendo que cada una de sus máquinas tuviera 4 núcleos Xeon Six, 32 GB de RAM, una matriz de discos rápida y una base de datos altamente optimizada para escrituras, podría hacerlo . Aunque, el costo de cada servidor es probablemente en el rango de $ 35K a $ 40K.

Independientemente, su cuello de botella no sería con C# o Java. Sería con el servidor de la base de datos dependiendo de qué tan grande crezca. En mi caso, se trata de 300 GB con 10 GB que se eliminan y 10 GB que se agregan por día.

Answer 9

Según mi experiencia previa, puedo darle el siguiente consejo.

1. escoger el idioma que (y posiblemente otros miembros del equipo) como la mayoría. Preferiría idiomas de nivel superior porque el hardware es rápido y barato, pero los programadores son lentos y caros.
2. Diseñe sus servicios a sea absolutamente libre de estados (sin sesiones!). Esto hace que sea fácil agregar nuevo hardware, ya que las diferentes instancias de su servicio no necesitan conocerse entre sí.
3. Maneje su procesamiento asincrónicamente, ya que afortunadamente no es necesario dar al cliente ninguna respuesta (que no sea OK). Si lo hace de forma síncrona, su proceso se bloqueará y su tasa de solicitud disminuirá. Una buena lectura es this Wikipedia article, y especialmente (¡el clásico!) The C10K problem.
4. Poner el servicio en muchas máquinas. (dependiendo de la velocidad de sus servicios)
5. colocar el servidor (s) de base de datos en otras máquinas que los servicios web. ¡Utiliza discos rápidos!
6. manejar la carga mediante el equilibrio de con algo como:
   • Linux Virtual Server, la solución mas potente, ya que se ejecuta en el kernel. Escamas como loco Lo usé 2003 con ~ 500req/seg en un P3/1GHz con 0.1% de carga de CPU. Se puede emparejar para lograr HA. Debe manejar los 10000req/seg bastante bien en una sola máquina. Haz esto después de intentar algo más simple. Esto puede ser bastante desafiante.
   • Pound, muy fácil de configurar pero con una sobrecarga elevada. Buen punto de partida. Puede hacer SSL.
   • Nginx, configuración fácil, muy eficiente. Puede hacer SSL. También puede actuar como servidor HTTP y puede ser una solución de alojamiento de rendimiento para sus servicios.
   • Perlbal, no lo he usado pero escuché cosas buenas.
   • u otro reverse proxys.

Answer 10

Veamos los temas:

IO: esto será fácilmente el mayor cuello de botella en el sistema. Elija un idioma que ofrezca la mejor integración con el host host, y brinde semántica avanzada para no bloquear y, opcionalmente, soporte para concurrencia.

Datos: ¿SOAP? XML? Querrá minimizar cualquier ciclo de CPU innecesario. ¿Qué pasa con simplemente usar JSon? (Y no existe un dictamen divino que diga que un servidor REST basado en arquitectura no puede usar datos binarios en el protocolo ...)

Contenido: Si está involucrada cualquier transformación de datos (de texto a número, por ejemplo) , también deberá considerar qué idioma proporciona los mecanismos más eficientes. Como ejemplo, en Java (que es un candidato muy fuerte para usted, por cierto), la clase String es un cerdo de CPU serio.

Java y Erlang son muy buenos candidatos. C siempre es una opción, pero la programación simultánea es mucho más difícil.