2010-09-05 7 views
6

Me inspiré en Slashdot, me dijeron que utiliza servidores muy limitados para admitir a muchos usuarios con una respuesta rápida. Y hay un sitio web llamado slashcode, no estoy seguro si slashdot usa su código fuente.¿Es Perl la forma más rápida de escribir una página de alto rendimiento?

Me pregunto si Perl es el mejor para escribir una página web de alto rendimiento. Sé que usar Apache o IIS tendrá muchos gastos generales?

¿Alguna idea, libros, documentos, tutoriales?

+9

Una buena arquitectura va a ser más importante que el idioma. Esto incluye las otras capas como el almacenamiento en caché, la base de datos, el almacenamiento de archivos, etc. –

+0

Sí, slashcode es un código detrás de Slashdot. Utiliza Apache + mod_perl. –

Respuesta

14

Voy a suponer que por "alto rendimiento" se refiere tanto al tiempo real que se tarda en producir una página como a la cantidad que puede servir al mismo tiempo.

El lenguaje de programación no es tan importante como sus servidores y algoritmos. Es posible que desee consultar The C10k Problem, que es una serie de nuevas tecnologías y perfeccionamiento de técnicas con el objetivo de permitir que un solo servidor web administre al mismo tiempo más de 10.000 conexiones simultáneas. Cosas como los servidores web Nginx y lighttpd y el caché varnish salieron de este proyecto.

Las grandes ganancias provienen de utilizar un servidor web muy ligero, muy rápido y muy modular (Apache e IIS no lo es) con un caché muy ligero y muy rápido para evitar tener que procesar lo mismo dos veces . Para un servidor de concurrencia alta, incluso el almacenamiento en caché por unos segundos puede ahorrarle cientos o miles de procesos. Al cortar una página estática en una serie de solicitudes AJAX, puede almacenar en caché las partes más estáticas independientemente de los bits que cambian con frecuencia.

En lugar de usar mod_blah que integra su programa en un servidor web, use FastCGI o similar que coloca sus programas en sus propios pequeños servidores de aplicaciones. Esto les permite funcionar independientemente del servidor web, posiblemente en máquinas remotas y con balanceo de carga. Esto le permite escalar fácilmente su potencia de procesamiento.

Eventualmente va a micro-optimizar partes realmente importantes del código de su aplicación hasta el punto en que el lenguaje importa, pero puede enfocarse en las partes realmente importantes en lugar de tener que hacer todo el proyecto únicamente según el rendimiento bruto .

0

This post en serverfault sugiere que podría escribir un módulo de extensión en nginx para servir contenido dinámico.

Dichos módulos deben compilarse con código de máquina nativo, por lo que es más probable que sean más rápidos que ejecutar Perl.

+0

Gracias, pero algún tipo No quiero usar C/C++ para escribir la página web, Python puede ser preferido ... ¿Parece web.py bueno? –

3

Independientemente de qué tan rápido sea su código, en algún momento el cuello de botella dejará de ser su código y comenzará a ser el servidor web.

2

Siempre que no esté utilizando la interfaz CGI [1] para hablar con el servidor web, el lenguaje no tendrá un impacto notable en el rendimiento en el 99% de los casos. Las excepciones son aquellas en las que realiza un pesado proceso de back-end en lugar de simplemente tomar algo de una base de datos, masajearlo ligeramente y enviarlo al usuario, y, si está haciendo ese tipo de cosas, usted ' Probablemente sea mejor hacerlo asincrónicamente si es posible y rellenar los resultados en una base de datos para ser masajes y verlos más tarde.

La razón es, simplemente, que la conexión de red y los tiempos de transferencia de datos serán mucho más largos que el tiempo de ejecución de su programa que ni siquiera es divertido. Si lleva 2 segundos establecer una conexión de red con el servidor y realizar la transmisión de datos en cada dirección, a nadie le importará si el procesamiento en el servidor agrega 0.1 so 0.2 s además de esos 2 s de actividad de la red.

[1] Nótese que estoy hablando aquí de la CGI de vainilla "poner en marcha un nuevo proceso para dar servicio a cada solicitud entrante" modelo, no el módulo Perl CGI (CGI.pm/use CGI). Existen formas de use CGI al tiempo que se utiliza un proceso de larga duración que maneja múltiples solicitudes a lo largo de su vida útil.

1

La arquitectura y el diseño del sistema son más importantes que la elección de idioma para una aplicación de alto tráfico.

Pero seleccionar un idioma no es lo primero que debe hacer, a menos que tenga pensado escribir todo desde cero.

Debe seleccionar un conjunto de herramientas.

Si desea tener algo lo antes posible, consulte las aplicaciones web existentes. ¿Qué satisface tus necesidades? ¿Qué tan personalizable es? ¿Cumple con los requisitos de rendimiento/escalabilidad? De ser así, el idioma que use será el idioma que usa su aplicación.

Si no puede encontrar una buena coincidencia en las aplicaciones existentes, consulte diferentes marcos, Catalyst, Rails, Squatting, Camping, Jifty, Django. Hay a nice list of them on Wikipedia.

Debería poder encontrar un marco que haga el trabajo, muchos de ellos. Elige algunos contendientes y elige uno. El idioma que use será el idioma que usa su marco.

-1

No creo que sea más rápido que otras opciones comunes como PHP, Python, Ruby, Java o C#.

+0

mod_perl permite una integración muy estrecha con Apache (su programa se convierte en una subrutina dentro de Apache), por lo que puede ser más rápido. –

+0

@Alexandr Ciornii wow, gracias por el downvote. Sin embargo, no hay evidencia de que Perl tenga un rendimiento superior al de PHP, Python, Perl, etc. en Apache. –

1

Realmente no existe la "página de alto rendimiento". Es como preguntar cuál es el automóvil más rápido (y si mira lo suficiente Top Gear, sabe que no es una respuesta simple). Tienes que pensar en lo que realmente quieres hacer (es decir, la tarea en particular), lo que tienes que hacer para que eso ocurra y qué herramientas funcionarían mejor para eso.

¿Va a haber mucha gente haciendo cosas pequeñas o menos personas haciendo cosas realmente grandes? ¿Todo va a suceder de una vez (es decir, picos), o va a ser una demanda constante? ¿Envías pequeños fragmentos de datos o muestras grandes?

Supongamos que cada parte fuera lo más rápido posible. Es una fantasía segura, pero considéralo de todos modos. Ahora que todo es lo más rápido posible, clasifique cada parte según cuán relativamente rápido sean. ¿Cuál es la parte más lenta? ¿Es acceso al disco? ¿Red IO? ¿Disponibilidad de enchufes?

Si no estás en el punto en el que ya estás pensando en esto, el lenguaje probablemente no es tan importante como tu habilidad con él.

Hay muchos libros sobre rendimiento web. :)

Cuestiones relacionadas