¿La velocidad de un lenguaje de programación es importante para las aplicaciones web?

Question

Veo una gran cantidad de puntos de referencia entre PHP, Python, Ruby, etc. en todo Internet. Ruby ha recibido muchas críticas por ser súper lentas, lo que lleva a los desarrolladores a rechazar su uso para el desarrollo web por "razones de rendimiento". Pero, ¿el rendimiento del intérprete realmente importa para las aplicaciones web? ¿No está el cuello de botella ubicado en la base de datos el 99% de las veces? Entonces, ¿por qué todos se están volviendo locos?

Nota: Me doy cuenta de que en algunos casos extremos, como ciertas aplicaciones web matemáticas/científicas, el rendimiento importa mucho, pero no estoy hablando de eso; Estoy hablando de sus redes sociales promedio, desbordamientos de pila, etc.

Answer 1

¿El rendimiento es importante? Finalmente, seguro.

Pero su sitio web tendrá que conseguir tan grande que usted está en los millones de visitas por rango mes antes incluso será un problema para usted fuera de la optimización tradicional (por ejemplo, una correcta indexación en su base de datos).

No creo que el disgusto de Ruby tenga tanto que ver con el rendimiento (aunque ha habido problemas con esto). Es más que no está probado, tiene una reputación de inestabilidad y forzó un marco muy rígido para ti (sí, sé que puedes usar Ruby sin rieles, etc.). No soy fanático de Ruby por la misma razón por la que no soy fanático de los frameworks pesados ​​de PHP como CakePHP o Symfony: encuentro que estos frameworks son demasiado invasivos y tan pesados ​​que ya no estás haciendo PHP. Compare esto con framewrks más ligeros como CodeIgniter, que tienen un retorno de la inversión mucho mejor (imho).

Answer 2

No creo que su pregunta esté muy bien pensada.

Primero afirma que la mayoría de las aplicaciones web no requieren un rendimiento fantástico en el lado de la aplicación de las cosas, lo que probablemente sea cierto para muchas de ellas. A continuación, brinde algunos ejemplos de aplicaciones web que do requieren un buen rendimiento, y agítelas diciendo que las personas simplemente las escriben en C++ o Java.

Bueno, ¿no crees que prefieren escribir en Ruby o Python? ¡Tal vez por eso la gente está interesada en medir el desempeño de Ruby y Python!

EDIT: OK, por lo que está interesado en aplicaciones web muy comunes. De manera que usted y yo podemos ver que hay dos posibilidades:

• Rendimiento de hecho es importante, es por eso que están preocupados por Ruby y Python y el rendimiento de PHP.

• El rendimiento no es importante, por lo que se confunden, y o bien ignoran ese hecho o hacen una excusa.

Answer 3

¿El rendimiento es importante para las aplicaciones web?

Sí! ¡Incluso más que para aplicaciones de escritorio!

Con una aplicación de escritorio, si la necesita puede usar casi todos los recursos considerables disponibles para la computadora de sus usuarios.Con una aplicación web, una computadora tiene que manejar potencialmente la ejecución de su aplicación para un lote de usuarios simultáneos. Si no puedes lograr que lo haga fácilmente, estás en un problema real.

Answer 4

Puede importar mucho, dependiendo del contexto. La mayoría de los sitios web se ejecutan en servidores de alojamiento compartido donde eso se suma. Con unos cientos de aplicaciones web ejecutándose en la misma caja, tendrá cuellos de botella en la CPU y la memoria.

Answer 5

Ese no debería ser el centro de su pregunta. En su lugar, debe centrarse en cómo el contenido puede entregarse al usuario final de la manera más eficiente posible. Si una aplicación web está bien escrita, creo que cualquier lenguaje importante del lado del servidor es una buena opción.

Answer 6

Lo que debería hacer temblar de miedo en la esquina es que varios estudios realizados por amazon.com y google.com han encontrado que un < 1 segundo de disminución en el tiempo de carga de página tuvo un impacto significativo (para ellos) en sus tasas de conversión y por lo tanto, ganancia.

Por lo tanto, el rendimiento es muy importante, incluso para sitios pequeños. La pregunta es cuánto importará. Perder el .1% de las ventas realmente no importa cuando haces 100 únicas al día, pero cuando estás haciendo 10 millones, entonces de repente, el .1% te cuesta mucho dinero.

Incluso pequeños cambios en los tiempos de respuesta pueden tener efectos significativos. Google encontró que pasar de un resultado de 10 cargando la página en 0,4 segundos a cargando la página de 30 resultados en 0,9 segundos disminuyendo el tráfico y los ingresos publicitarios por 20% (Linden 2006). Cuando la página de inicio de Google Maps se redujo de 100KB a 70-80 KB, el tráfico aumentó un 10% en la primera semana y un 25% adicional en las siguientes tres semanas (Farber 2006). Las pruebas en Amazon revelaron resultados similares: cada 100 ms de aumento en el tiempo de carga de Amazon.com disminuyeron las ventas en un 1% (Kohavi y Longbotham 2007). Los experimentos en Microsoft en Live Search mostraron que cuando la búsqueda páginas de resultados se redujeron en 1 segundo: (Kohavi 2007)

* Queries per user declined by 1.0%, and 
* Ad clicks per user declined by 1.5% 

Después de reducir la página de resultados de búsqueda por 2 segundos:

* Queries per user declined by 2.5%, and 
* Ad clicks per user declined by 4.4% 

http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/

Answer 7

mayoría de los sitios liberar el código de primera versión tan pronto como el sitio es funcional. Si tienen éxito, muy pronto habrá páginas de varios segundos, y tendrán que asistir al hardware o al software, y supongo que sugieren una distinción implícita entre el código de la página y el software de la base de datos.

¿Se está preguntando si no deberíamos molestarnos con el código de la página y asumir que hay problemas de escalado no relacionados con el hardware en la base de datos? Esa no es mi experiencia; aunque suele ser la base de datos que se publica más pronto porque, como las herraduras, con demasiada frecuencia es lo suficientemente buena (siempre que la respuesta sea la esperada)

Pero he visto mucho más código de página que intentaba hacer qué las bases de datos están diseñadas para hacer (por ejemplo, con matrices) que viceversa (por ejemplo, cursores), con consecuencias igualmente perjudiciales para la velocidad y la escalabilidad.Y la optimización de una consulta de base de datos es en mi experiencia menos trabajo que la reparación de código PHP.

Creo que la mayoría de los problemas de velocidad no son el lenguaje (o el propio dbms) sino la calidad del diseño y el código. Entonces, creo que los buenos desarrolladores estarían más preocupados por si un lenguaje facilita o no el buen diseño y el buen código, no la velocidad con la que se ejecuta.

Answer 8

Aquí hay un par de argumentos diferentes: debido a que el código se está ejecutando en su servidor, y si su código es ineficiente, entonces se sobrecargará y se degradará la experiencia para todos.

La otra cara de la moneda es you need to be successful for it to matter, como dijo Ted Dziuba tan elocuente y profano. Los lenguajes "lentos" tienden a ser mucho más rápidos de desarrollar y más expresivos que los lenguajes compilados, por lo que permiten a un equipo crear un sitio y ejecutarlo más rápidamente.

Answer 9

En mi experiencia, una vez que realmente empiezas a estar ocupado, es en la base de datos donde puedes hacer la mayor DIFERENCIA.

Pero también agregaría otra consideración, y así de 'grande' es el tamaño de su página en términos de imágenes, solicitudes JS y HTTP. Podrías tener un sitio muy lento porque tu base de datos y tu código de aplicación increíblemente rápidos crearon un monstruo de una página web con imágenes e imágenes infladas. :)

Answer 10

jfar comienza por el camino correcto. En cuanto a qué tan impactante es tu lenguaje en esto, es probable que el perfil demuestre que tu lenguaje no es tu cuello de botella.

• Evite la compilación por solicitud como old-scool cgi. La mayoría de los marcos web modernos deben ser residentes entre las solicitudes.
• Si no cambia mucho, genere y sirva estático.
• Comprimir. Habilite gzip si puede, y quite el espacio en blanco y los comentarios. El espacio en blanco es para desarrollo y depuración.
• Averigüe el caso de uso db prevaleciente, consulta o inserte, y sintonice el correcto.
• Guarda en caché/renderiza lo que puedas.
• Pruebe la evaluación comparativa de diferentes servidores de aplicaciones, si usted es el operador, la gente le permitirá cambiar/actualizar.

¿Alguien más tiene algunos consejos genéricos de sintonía web o enlaces a otras preguntas de SO?

Is there a good book on web application performance tuning?

Answer 11

que tienes razón. La mayoría de las veces el cuello de botella será independiente de su lenguaje de servidor. Por supuesto, el 90% de todas las estadísticas se compilan sobre la marcha, pero yo diría que 9 de cada 10 veces el cuello de botella dependerá del ancho de banda/las velocidades de transferencia o las operaciones de la base de datos.

Suponiendo que hace un buen uso de cada idioma, hay casos limitados donde el rendimiento de PHP vs Python vs Ruby vs .NET vs lo que sea que el usuario note. Cuando cosas como el análisis de XML y la compresión se realizan a gran escala, entonces puede comenzar a darse cuenta, pero de lo contrario me limitaría a lo que es más eficiente.

A menudo, algunas de las mayores mejoras en la velocidad del sitio web pueden provenir de la compresión de gzip y del uso cuidadoso de la caché/caducidad del contenido. Y ambas cosas se pueden configurar en Apache o IIS. Escribí sobre ese tema aquí: http://swortham.blogspot.com/2007/10/three-ways-to-improve-your-websites.html