PHP и Java есть различия в потреблении энергии?

Question

Я слышал слух, что Java потребляет меньше энергии, чем PHP, и мне было интересно, если и как это будет правдой. В настоящее время я работаю в компании, где мы основываем большинство наших приложений на PHP. Потребление энергии никогда не было проблемой для нас, но мы работаем над большими проектами, где это может иметь значение. Мы любим PHP для веб-разработки и задаемся вопросом, как распространяются такие слухи, и насколько они правдивы.

Пример, который я слышал, был о том, что Facebook именно по этой причине переключается на Java (хотя я не могу найти ничего подобного в Google).

Так как мой клиент задает мне этот вопрос, я бы хотел доказательства, если это правда.

Answer 1

Хотя многие аспекты этого вопроса уже подробно изучены здесь, есть еще как минимум еще один вопрос, который стоит рассмотреть.

Типичное веб-приложение PHP дублирует много усилий от одного запроса к следующему, просто потому, что среда выполнения (или контекст) PHP не постоянна между запросами.

Поскольку типичное веб-приложение Java имеет возможность сохранять состояние напрямую, без дополнительных шагов или аннулирования кэша, ему не нужно, например, выполнять дублирующие SQL-запросы в стиле PHP для извлечения та же информация для каждого запроса. Вместо этого веб-приложение Java часто хранит сложную информацию для текущего анализа в собственной структуре данных в куче, доступ к которой осуществляется в наносекундах, а не в миллисекундах.

Поскольку процессору приходится выполнять значительно меньше работы для выполнения этих основных функций доступа к данным, для работы требуется меньше энергии на единицу потребительской ценности.

Answer 2

Очевидно, что современные компьютерные технологии используют намного больше ресурсов, чем раньше, и это прямо равно потреблению энергии. Если бы мы использовали обычный старый сокет для передачи двоичных данных по сети, и процессор с частотой 100 МГц справился бы с этим, теперь у нас есть программный стек, в котором данные преобразуются в текст XML, а затем передаются через веб-службу через http через тот же самый сокета, и мы задаемся вопросом, зачем нам нужен процессор 3 ГГц с частями оперативной памяти, чтобы получить приличную производительность:)

Так вот в чем проблема, единственное, что вы можете с этим сделать, - это сделать ваш код более эффективным. Как правило, это означает использование языка более низкого уровня и меньшую зависимость от универсальных сред или библиотек. Определенно не пытайтесь наслоить программные стеки, если вы не можете помочь.

Современному программированию это не нравится - есть толчок к повышению производительности труда программистов, использованию более дешевых программистов и постоянной переработке кода (т.е. переписыванию его), поэтому код должен быть простым в создании (и иногда поддерживать). В результате, чтобы получить лучшее, вам нужно обойтись без этих факторов. Промышленный стандартный способ сделать это - просто смешать системы в соответствии с их использованием.

В настоящее время максимальная производительность - это код C / C ++, а максимальная производительность для программиста - это языки сценариев. Итак, в идеале лучше всего написать свою основную бизнес-логику на языке сценариев, таком как Python, и использовать его для вызова выделенных «помощников по силе», написанных на C / C ++. Если вам нужно больше производительности, вы можете написать больше своего кода на базовом C / C ++. Если вам нужно больше быстрой разработки RAD, напишите больше на языке сценариев.

Мой совет для OP - не переписывать на Java, он может быть лучше в целом, но вы будете стоить так дорого, что может и не стоить того. Вместо этого возьмите интенсивные фрагменты своего приложения и переписайте их как можно эффективнее и вызывайте их из существующего PHP. затем взгляните на свою общую архитектуру и уменьшите зависимость от неэффективных протоколов и структур данных. Например: если вы замените XML на JSON, вы обнаружите, что у вас есть те же функциональные возможности, но на долю размера данных и ресурсов, необходимых для анализа и переформатирования данных.