que - PHP vs. Java ¿hay diferencias en el consumo de energía?
que diferencias existen entre java y php (12)
¿Por consumo energético te refieres a vatios de consumo energético?
No estoy 100% seguro, pero incluso si esto es cierto, creo que esto es similar a la optimización de una parte de su código, que se ejecuta en el 0.01% del tiempo de ejecución de su programa.
Los problemas que serán causados por el cambio (cambios en las plataformas de producción / lanzamiento, pérdida de tiempo de la curva de aprendizaje, nuevos costos de software empresarial, etc.) serán bastante drásticos. No puedo ver que se tome una decisión tan importante, excepto después de una tarea de análisis empresarial seria y específica de la empresa y los resultados correspondientes.
Sin embargo, esto debería hacer para una discusión interesante.
Escuché un rumor de que Java consume menos energía que PHP y me preguntaba si esto sería cierto y cómo. Actualmente estoy trabajando en una empresa donde basamos la mayoría de nuestras aplicaciones en PHP. El consumo de energía nunca ha sido el problema para nosotros, pero estamos trabajando en proyectos más grandes donde podría ser importante. Nos encanta PHP para el desarrollo web y nos preguntamos cómo se puede propagar tal rumor y si es cierto.
El ejemplo que escuché fue que Facebook está cambiando exactamente por esa razón a Java (aunque no puedo encontrar nada de esto en Google).
Dado que un cliente mío me está haciendo esta pregunta, me encantaría probar si es cierto.
A las computadoras no les importa particularmente si están ejecutando Java o PHP. El consumo de energía es prácticamente lo mismo. La pregunta se convierte en una cuestión de rendimiento: si puede atender más solicitudes con un servidor, necesitará menos servidores y consumirá menos energía. O, alternativamente, si no está haciendo aplicaciones de escala web, atienda sus solicitudes más rápidamente y pase más tiempo inactivo, lo que consume menos energía.
Por supuesto, teniendo en cuenta Java puro y PHP puro, Java como lenguaje JIT''ed tipificado estáticamente es, por supuesto, más rápido. La pregunta es más bien cuál puede hacer más rápido dados los miembros del equipo y el esfuerzo de desarrollo disponible para usted.
Mi opinión es que la mejor manera es mezclar idiomas, usar herramientas de infraestructura basadas en Java existentes, como Terracotta para construir las partes críticas de rendimiento y algo más ágil para construir una lógica de presentación y negocios compleja pero no tan pesada.
Al igual que muchas preguntas comparativas aquí, es probable que tenga que encontrar un punto de referencia para determinar realmente si eso es cierto.
lesswatts.org tiene un poco de información sobre la administración de energía de las aplicaciones , así como varios otros aspectos del consumo de energía en los sistemas Linux. Como nota al margen, parecen estar usando PHP, por lo que podría valer algo en sí mismo :)
Siguen repitiendo que debe usar PowerTOP para determinar qué aplicaciones causan el mayor consumo de energía y, como mínimo, pueden ver en la captura de pantalla que están revisando las activaciones de inactividad.
La mayoría de las veces, un servidor web está inactivo, luego "sirve" durante un breve momento, luego vuelve a esperar a que la próxima conexión sirva. En ese sentido, PHP contribuiría muy poco a todo el proceso: solo la porción de servicio. Así que me pregunto si el punto de referencia real fue una comparación de un servidor web particular basado en Java versus Apache / PHP que sirve páginas similares. Si ese fue el caso, en realidad no es una comparación justa de PHP y Java: cualquiera de los dos considerados como que sirven a una página real solo está activo por milisegundos a la vez, por lo general. Creo que el servidor web real, el que está seleccionando o sondeando las conexiones, es el que estaría acaparando el poder.
Entiendo que muchas empresas grandes tienen dificultades con el crecimiento de la demanda de recursos en sus centros de datos. Estos incluyen tanto espacio como consumo de energía. Entonces, puedo creer que la racionalización de las aplicaciones, favoreciendo el bajo consumo de recursos, es una estrategia que se está adoptando.
Si el uso de Java, PHP o cualquier otra tecnología de implementación probablemente sea el factor determinante del consumo de energía, es menos obvio para mí.
Si implementáramos una pieza particular de la función de optimización para el consumo de recursos en, digamos, Interpretado Básico, Java y C, que esperamos que necesiten la mayoría de los recursos de ejecución.
Necesitaría ver algunas pruebas sólidas, pero podría creer que un lenguaje interpretado puro podría consumir más que Java, e incluso con JIT, etc., a su vez, podría consumir más que C.
Ahora suponga (puramente hipotéticamente, no estoy diciendo que este sea el caso) que fue más un esfuerzo para desarrollar en C que en Java, y más esfuerzo para desarrollar en Java que en Basic. ¿Cómo cambiaría el esfuerzo de desarrollo y mantenimiento contra ese consumo de recursos?
Realmente difícil de hacer. Si alguien me dijera que se están mudando a Java solo en función del consumo de energía, realmente me gustaría saber más. ¿Cuáles son los costos de hacerlo? ¿Dónde estaba el punto de equilibrio? [Por cierto, trabajo casi exclusivamente en Java, me encantaría poder decir "ganamos, ¡veamos cuánta potencia tenemos!"]
Esta es la misma pregunta que lenguaje tiene el mejor rendimiento. Ahora, para casi todos los proyectos con los que la mayoría de los programadores se ponen en contacto. La forma en que escribe el sistema supera con creces las tecnologías utilizadas (dado que el sistema está bien especificado).
La elección del rendimiento de la escritura de lenguaje es imho para sistemas integrados y científicos. Usted elige el idioma de acuerdo con el problema a resolver, y muy rara vez por la eficiencia de la CPU.
Nuevamente, es cómo diseña y escribe el sistema lo que determina qué tan eficiente será.
Esta es una pregunta difícil de responder a menos que, como se mencionó sobre los puntos de referencia, establezca algunas reglas para la comparación.
Por ejemplo, comparar un shooter en primera persona Java3D con una página web de PHP sería injusto, ya que Java perdería.
Si observa los marcos de Java, puede comparar estos tres: Tomcat + JDK 6 + JSP Apache + PHP Scala + Lift framework
Incluí Scala, ya que se compila en el código de bytes de Java y espero que sea más barato para el poder.
No estoy seguro de cuál sería el ganador, apostaría por Scala, pero usted querrá asegurarse de que tiene implementada la misma aplicación y luego comparar el uso de energía.
PHP probablemente ganará cuando Apache y PHP parece ser más bajo en el uso de memoria que Java, pero realmente no puedo comparar Scala y PHP.
La gran incógnita para mí es que si llama al mismo código Java, entonces ya se ha convertido en código nativo y, por lo tanto, se ejecutará más rápidamente, pero JSP debe precompilarse para aprovechar Java.
Pero, si usa tecnologías Web2.0, entonces cambia, a medida que coloca la mayor parte de la carga en el navegador, si tiene una aplicación javascript grande, simplemente está haciendo llamadas al servidor, lo que reducirá el uso de energía en el servidor como el El trabajo de renderización se pasa al navegador. En ese punto, el JIT para Java debería entrar en juego, y Java o Scala esperaría ser más bajo en el uso de energía.
Una gran prueba, IMO, sería ver si podemos obtener el mismo rendimiento que reducimos el tamaño de la máquina, por lo tanto, si necesita 3 computadoras para PHP o Java, que tienen carga equilibrada, y 1 máquina Scala puede tener la misma actuación, entonces ganará Scala (usando Lift).
La eficiencia energética es un campo completo en sí mismo. Medir el rendimiento suele ser la mejor manera de hacerlo (dado el mismo hardware). Si se compara un hardware diferente, entonces es un juego de pelota completo.
Por lo tanto, dado el mismo hardware, si una pila de software puede funcionar mejor que otra pila de software, significa que la pila de software con mejor rendimiento usará menos potencia "por solicitud" que la otra. Si la diferencia de rendimiento es lo suficientemente grande como para que pueda consolidar sus servidores en menos, ¡entonces es una ganancia aún mayor!
Hay muchas otras consideraciones:
Centros de datos Considere que los servidores están alojados en centros de datos que se enfrían. Los servidores generan calor y el calor debe eliminarse para proteger el hardware. Las unidades de aire acondicionado no tienen granularidad infinita. Su eficiencia suele venir con el volumen. Entonces, si reduzco mi número de servidores de 2 a 1, es posible que haya ahorrado el consumo de energía de un servidor, pero probablemente no haya mucho en costos de refrigeración. Pero si cambiar mi arquitectura me permite cortar 100 servidores ... ¡eso es un gran ahorro!
Hardware y dispositivos periféricos Utilizando la pila de software SW más eficiente en el uso de la energía y ejecutándola en un servidor Pentium 4 = estupidez;) El software con mayor eficiencia energética no puede compensar el hardware ineficiente. Una lección interesante aquí es: "deje que los tipos de hardware se preocupen por el poder". Te preocupas por llevar tu aplicación al mercado. Cuando su aplicación puede generar ingresos, siempre puede comprar la última CPU hexa-deca Core 5 de 16 núcleos y obtener instantáneamente su eficiencia energética;)
Virtualización Si su aplicación es de bajo volumen, consolidarla en una máquina virtual que se ejecuta en un sistema de múltiples núcleos probablemente le ahorrará más energía que reescribirla en su pila de software SW más eficiente y ejecutarla en un servidor independiente.
Tiempo del programador Necesitas que los programadores conozcan la pila de software "más eficiente". Debes considerar si esa es la herramienta correcta. Los programadores usan las computadoras para desarrollar el software y, cuanto más tiempo necesiten desarrollar (si están limitados a las herramientas equivocadas), más energía se consume. Sin mencionar que tendrás que pagarles más horas. Esto generalmente anula cualquier preocupación por el consumo de energía porque los costos aquí son magnitudes más altas.
Si su única preocupación es la eficiencia energética, sí, use todas las herramientas de la bolsa para llegar allí. Pero la mayoría de las veces, esa es solo una pequeña variable en el esquema general de las cosas, y también la menor parte de su costo.
Me sorprendió esta pregunta hasta que realicé una búsqueda en Google, que resultó this . Es un tema serio, uno en el que no habría pensado.
Ahora que lo estoy pensando, creo que se convierte en un problema de quién paga la factura eléctrica. La estrategia de Sun de Java consistía en vender servidores: grandes posibilidades para la parte de atrás, clientes ligeros para la parte delantera.
Tal vez tecnologías como Flex mueven más trabajo al cliente y lo dejan con un mayor porcentaje de la factura eléctrica.
Pero me sorprendería ver un ranking de idiomas por uso de energía.
Una pregunta muy interesante. Lo estoy votando.
Qué problema tan fascinante. ¿No sería interesante escribir una aplicación en varios idiomas, implementarla en un hardware idéntico y medir el consumo de energía? Me encantaría verlo.
Si realmente te vuelves loco, ¿qué tal una herramienta de monitoreo de rendimiento que, además de mostrarte dónde se consumía la memoria y la CPU en cada parte de tu aplicación, también te mostraría dónde se estaba usando la mayor cantidad de energía?
Ahora me gustaría poder votar esta pregunta de nuevo.
Obviamente, las técnicas de computación modernas utilizan muchos más recursos de los que solían usar, y esto equivale directamente al consumo de energía. Una vez que utilizáramos un socket antiguo simple para transferir datos binarios a través de la red y un procesador de 100Mhz lo manejaría, ahora tenemos una pila de software donde los datos se convierten a texto XML y luego se transfieren a través de un servicio web a través de http sobre ese mismo socket, y nos preguntamos por qué necesitamos un procesador de 3 GHz con spods de RAM para obtener un rendimiento decente :)
Ese es el problema, lo único que puede hacer al respecto es hacer que su código sea más eficiente. Por lo general, esto significa usar un lenguaje de nivel inferior y una menor dependencia de los marcos o bibliotecas de propósito general. Definitivamente no intente colocar capas de software si no puede evitarlo.
A la programación moderna no le gusta esto: hay un impulso hacia la productividad del programador, el empleo de programadores más económicos y la reingeniería del código todo el tiempo (es decir, la reescritura), por lo que el código debe ser fácil de crear (y algunas veces mantener). Como resultado, para obtener lo mejor tendrá que compensar estos factores. La manera estándar de hacer esto en la industria es simplemente mezclar sistemas de acuerdo con su uso.
Actualmente, el rendimiento máximo es el código C / C ++, y la productividad máxima del programador parece ser los lenguajes de script. Entonces, lo mejor de ambos es escribir su lógica de negocios principal en un lenguaje de script como Python, y usarla para llamar "ayudantes de poder" dedicados escritos en C / C ++. Si necesita más rendimiento, puede escribir más de su código en el C / C ++ subyacente. Si necesita más desarrollo rápido de RAD, escriba más en el lenguaje de script.
Mi consejo para el OP es que no se vuelva a escribir en Java, puede que tenga un mejor rendimiento en general, pero costará tanto que puede que no valga la pena. En su lugar, tome los bits intensivos de su aplicación y vuelva a escribirlos tan eficientemente como pueda y llámelos desde su PHP existente. luego observe su arquitectura general y reduzca la dependencia de protocolos ineficientes y estructuras de datos. Por ejemplo: si reemplaza XML con JSON, encontrará que tiene la misma funcionalidad pero con una fracción del tamaño de los datos y los recursos necesarios para analizar y reformatear los datos.
Realmente dudo que sea solo un problema de lenguaje.
Las plataformas en cuestión tienen tanta variabilidad para hacer que cualquier comparación genérica sea discutible. Para nombrar algunos puntos de variabilidad.
- Servlet contenedor para Java (Tomcat, Glassfish, Websphere, Jetty, ...)
- Servidor web para PHP (Apache, IIS, lighttpd, nginx, ...)
- Opcode caches para PHP
- Bibliotecas y marcos de imágenes utilizados.
- Sistemas operativos
- Discos duros involucrados
- Enfriamiento
- Algoritmos sobre la propia aplicación.
Realmente dudo que puedas aislar tantas variables en una métrica útil. A lo sumo, puede elegir dos aplicaciones equivalentes (teniendo en cuenta todas las opciones de la plataforma) utilizando el mismo hardware y compararlas. Luego mejora lo peor hasta que supere a la mejor. La medida correcta sería tanto los vatios por hora como las solicitudes por segundo, creo.
Sin embargo, lo que se señala en la respuesta de Ants (promocionarlo) es el punto crucial: la plataforma con mejor rendimiento siempre será más eficiente en cuanto a consumo de energía, dada la demanda suficiente , porque podrá atender la misma cantidad de solicitudes con menos hardware.
Pero la plataforma con mejor rendimiento no depende únicamente del lenguaje, depende de las cosas mencionadas anteriormente (y algunas más).
Si bien muchas de las facetas relacionadas con estas preguntas ya se han explorado en profundidad aquí, hay al menos una más que analizar.
Una aplicación web PHP típica duplica mucho esfuerzo de una solicitud a otra, simplemente porque el entorno de ejecución de PHP (o el contexto) no es persistente en todas las solicitudes.
Como una aplicación web Java típica tiene la capacidad de persistir en el estado directamente, sin pasos adicionales o invalidación de caché, no es necesario, por ejemplo, realizar consultas SQL duplicativas al estilo de PHP para obtener la misma información para cada solicitud. En cambio, una aplicación web de Java a menudo almacena la información compleja para el análisis actual en una estructura de datos nativa en el montón, al que se accede en nanosegundos, en lugar de milisegundos.
Como el procesador tiene que hacer mucho menos trabajo para realizar estas funciones básicas de acceso a datos, el trabajo requiere menos energía por unidad de valor para el cliente.
Un código más eficiente consume menos recursos, incluida la energía. Java en general tiene una implementación más rápida y eficiente, por lo que todos los demás factores son constantes, y es probable que Java consuma menos energía al ejecutarse en un servidor.
Pero todos los demás factores no son constantes . No se sabe qué cambios se basan en su decisión de usar PHP o Java. Por ejemplo, Java demora más en desarrollarse, lo que significa que los programadores de Java tienen sus computadoras encendidas por más tiempo, y su uso de energía puede superar sus ahorros en el servidor.
Si usted es Google, Amazon o alguna otra compañía que atiende literalmente miles de millones de solicitudes cada día desde miles de servidores, me preocuparía por esto. De lo contrario, su escala no es lo suficientemente grande como para hacer afirmaciones positivas sobre el consumo de energía, por lo que cualquier decisión que tome será tan contraproducente como productiva porque es imposible incluir todos los factores relevantes.
Un ejemplo relevante es hace unos meses, cuando corrió el rumor de que podría ahorrar energía configurando el fondo de su escritorio en negro. La idea era que el negro == no hay luz, por lo que no usabas tanta luz. Google (una de las pocas empresas con suficiente consumo de energía para hacer que este tipo de investigación sea productiva) realizó algunos experimentos e investigó, y descubrió que las pantallas LCD producen luz blanca sin importar qué, y las filtra pasando una segunda corriente a través de los píxeles de una manera diferente. Entonces, al establecer un píxel en negro, está configurando su filtración al máximo, y en realidad está utilizando la mayor cantidad de energía posible. El fondo de escritorio con mayor ahorro de energía (al menos en una pantalla LCD) es un fondo blanco . Sin embargo, dado que los fondos blancos dañan los ojos de las personas, pocas personas configuran sus fondos de escritorio en blanco y el rumor de que los fondos negros ahorran energía aún prevalece.
Por lo tanto, para resumir la historia, preocuparse por esto probablemente haga más daño que bien.