PHP по сравнению с Java являются там различиями в потреблении энергии?
Как это было уже сказано, используют их для исключительных ситуаций только.
Всегда позволяют, чтобы пользователь постарался не выдавать исключение, например, если у Вас есть метод, который бросит, если что-то пойдет не так, как надо как это:
public void DoSomethingWithFile() {
if(!File.Exists(..))
throw new FileNotFoundException();
}
Предоставляют другой метод пользователю для вызова:
public bool CanDoSomething() {
return File.Exists(..);
}
Этот путь там вызывающая сторона может избежать исключений, если он хочет. Не смущайтесь бросать, если что-то неправильно - "перестали работать быстро", но всегда обеспечивают путь без исключений.
Также сохраняют Вашу иерархию класса исключений плоской и смотрят на стандартные исключения как InvalidStateException и ArgumentNullExcpetion.
12 ответов
Компьютеры не особо заботятся о том, выполняют ли они Java или PHP. Потребляемая мощность примерно такая же. Тогда вопрос становится вопросом производительности - если вы можете обслуживать больше запросов с одним сервером, вам понадобится меньше серверов и меньше энергии. Или, в качестве альтернативы, если вы не создаете приложения веб-масштабирования, обслуживайте ваши запросы быстрее и проводите больше времени в режиме ожидания, что потребляет меньше энергии.
Учитывая чистую Java и чистый PHP, Java как статически типизированный язык JIT, конечно, является Быстрее.
Я действительно очень сомневаюсь, что это проблема только языка.
Рассматриваемые платформы имеют настолько большую вариативность, что любое общее сравнение становится спорным. Назовем несколько моментов изменчивости.
- Контейнер сервлетов для Java (Tomcat, Glassfish, Websphere, Jetty, ...)
- Веб-сервер для PHP (Apache, IIS, lighttpd, nginx, ...)
- Кеши кодов операций для PHP
- Используемые библиотеки и фреймворки
- Операционные системы
- Задействованные жесткие диски
- Охлаждение
- Алгоритмы в самом приложении
Я действительно сомневаюсь, что вы можете выделить столько переменных в полезную метрику . В лучшем случае вы можете выбрать два эквивалентных приложения (с учетом всех вариантов платформы), использующих одно и то же оборудование, и сравнить их. Затем улучшайте худшее, пока оно не превзойдет лучшее. Я думаю, что правильным измерением будут и ватты в час, и запросы в секунду.
Я был удивлен этим вопросом, пока не выполнил поиск в Google, который показал это . Это серьезный вопрос, о котором я бы не подумал.
Теперь, когда я думаю об этом, я думаю, что встает вопрос о том, кто оплачивает счет за электричество. Стратегия Sun в отношении Java заключалась в продаже серверов: большое железо для задней части, тонкие клиенты для клиентской части.
Возможно, такие технологии, как Flex, возвращают клиенту большую часть работы и оставляют ему больший процент от счета за электричество.
Но я был бы удивлен, увидев рейтинг языков по потреблению энергии.
Очень интересный вопрос. Я голосую за.
Какая увлекательная проблема. Было бы интересно написать приложение на нескольких языках, развернуть его на идентичном оборудовании, а потребляемую мощность измерить? Я хотел бы это увидеть.
Если вы действительно сходите с ума, как насчет инструмента мониторинга производительности, который, помимо того, что показывает вам, где потреблялись память и процессор в каждой части вашего приложения, также показывал бы вам, где больше всего энергия использовалась?
Теперь я хотел бы снова проголосовать за этот вопрос.
Как и многие другие вопросы сравнения здесь, вам, вероятно, потребуется провести тест, чтобы действительно определить, правда ли это.
lesswatts.org содержит немного информации об управлении питанием приложений , а также некоторые другие аспекты энергопотребления в системах Linux. В качестве побочного примечания, они, похоже, используют PHP, так что это может чего-то стоить :)
Они продолжают повторять, что вы должны использовать PowerTOP , чтобы определить, какие приложения вызывают наибольшее потребление энергии, и вы можете видеть на скриншоте, что они, по крайней мере, проверяют пробуждение из бездействия.
Большую часть времени веб-сервер бездействует, затем он «обслуживает» очень короткое время, а затем возвращается в режим ожидания для следующего подключения для обслуживания. В связи с этим PHP будет очень мало способствовать всему процессу: только обслуживающая часть. Поэтому мне интересно, был ли реальный тест сравнением конкретного веб-сервера на основе Java с Apache / PHP, обслуживающим аналогичные страницы. Если бы это было так, то это не совсем справедливое сравнение PHP и Java - любой из двух рассматриваемых как обслуживающих фактическую страницу, как правило, активен только миллисекунды за раз. Я бы подумал, что реальный веб-сервер, который выбирает или опрашивает соединения, является единственным источником энергии.
Это не совсем справедливое сравнение PHP и Java - любой из двух, рассматриваемых как обслуживающая реальную страницу, обычно активен только миллисекунды за раз. Я бы подумал, что реальный веб-сервер, который выбирает или опрашивает соединения, является единственным источником энергии. Это не совсем справедливое сравнение PHP и Java - любой из двух, рассматриваемых как обслуживающая реальную страницу, обычно активен только миллисекунды за раз. Я бы подумал, что реальный веб-сервер, который выбирает или опрашивает соединения, является единственным источником энергии.Под потреблением энергии вы имеете в виду энергопотребление в ваттах?
Я не уверен на 100%, но даже если это правда, я думаю, что это похоже на оптимизацию части вашего кода , который выполняется в 0,01% времени выполнения вашей программы.
Проблемы, которые будут вызваны переключением (изменение платформ производства / выпуска, потеря времени на обучение, затраты на новое программное обеспечение для бизнеса и т. д.), будут довольно серьезными. Я не вижу принятия такого важного решения, кроме как после серьезного бизнес-анализа, специфичного для компании, и соответствующих результатов.
Однако это должно вызвать интересное обсуждение.
Я понимаю, что многие крупные компании испытывают трудности с ростом потребностей в ресурсах в их центрах обработки данных. К ним относятся как площадь пола, так и потребляемая мощность. Так что я вполне могу полагать, что рационализация приложений, благоприятствующая низкому потреблению ресурсов, - это стратегия, которая принимается.
Будет ли использование Java, PHP или любой другой технологии реализации, вероятно, определяющим фактором энергопотребления, менее очевидно для меня.
Если бы мы реализовали определенную часть функции, оптимизирующей потребление ресурсов, скажем, в Interpreted Basic, Java и C, что, как мы ожидаем, потребует больше всего ресурсов выполнения.
Мне нужно было бы увидеть некоторые веские доказательства, но я мог поверить, что чистый интерпретируемый язык может потреблять больше, чем Java, и даже с JIT и т. д. он, в свою очередь, может потреблять больше, чем C.
Теперь просто предположим (чисто гипотетически, я не говорю, что это так), что на C было приложено больше усилий, чем на Java, и на Java было больше усилий, чем на Basic. Как бы вы пожертвовали усилиями по разработке и сопровождению этим потреблением ресурсов?
Действительно сложно. Если бы кто-то сказал мне, что они переходят на Java Soleley из-за энергопотребления, я бы очень хотел узнать больше. Каковы затраты на это? Где была точка безубыточности? [Кстати, я работаю почти исключительно на Java, я бы хотел иметь возможность сказать: «Мы выигрываем, посмотрим, насколько у нас мало энергии!»]
Как бы вы пожертвовали усилиями по разработке и сопровождению этим потреблением ресурсов?Действительно сложно. Если бы кто-то сказал мне, что они переходят на Java soleley из-за энергопотребления, я бы действительно хотел узнать больше. Каковы затраты на это? Где была точка безубыточности? [Между прочим - я работаю почти исключительно на Java, я бы хотел иметь возможность сказать: «Мы выигрываем, посмотрим, насколько у нас мало энергии!»]
Как бы вы пожертвовали усилиями по разработке и сопровождению этим потреблением ресурсов?Действительно сложно. Если бы кто-то сказал мне, что они переходят на Java Soleley из-за энергопотребления, я бы очень хотел узнать больше. Каковы затраты на это? Где была точка безубыточности? [Кстати, я работаю почти исключительно на Java, я бы хотел иметь возможность сказать: «Мы выигрываем, посмотрим, насколько у нас мало энергии!»]
This is a difficult question to answer unless, as was mentioned about benchmarks, you set some rules for comparison.
For example, comparing a Java3D first-person shooter to a PHP webpage would be unfair, as Java would lose.
If you look at Java frameworks, then you may want to compare these three: Tomcat + JDK 6 + JSP Apache + PHP Scala + Lift framework
I included Scala as it compiles to java bytecode and I expect it will be cheapest for power.
I am not certain what would be the winner, I would bet on Scala, but you would want to ensure that you have the same application implemented and then just compare the power usage.
PHP will probably win as apache and PHP seems to be lower on memory usage than Java, but I can't really compare Scala and PHP.
The big unknown for me is that if you call the same java code then it has already been turned into native code and so will run more quickly, but JSP should be precompiled to take advantage of Java.
But, if you use Web2.0 technologies then it changes, as you put most of the load on the browser, if you have a large javascript application, then you are just making server calls, which will reduce power usage on the server as the render work is passed onto the browser. At that point the JIT for Java should come into play, and Java or Scala I would expect to be lower on power usage.
A big test, IMO, would be to see if we can get the same performance as we reduce the size of the machine, so, if you need 3 computers for PHP or Java, that are load balanced, and 1 Scala machine can have the same performance, then scala (using Lift) will win.
Энергоэффективность - это целое поле в себе. Обычно лучше всего измерять производительность (при том же оборудовании). Если сравнивается различное оборудование, то это совсем другая игра.
Таким образом, при том же оборудовании, если программный стек может работать лучше, чем другой программный стек, это означает, что более производительный программный стек будет потреблять меньше энергии. «на запрос», чем другой. Если разница в производительности достаточно велика для того, чтобы вы могли объединить свои серверы в меньшее количество, тогда это еще больший выигрыш!
Есть много других соображений:
Центры обработки данных Учтите, что серверы размещаются в охлаждаемых центрах обработки данных. Серверы выделяют тепло, и тепло необходимо отводить для защиты оборудования. Блоки A / C не имеют бесконечной детализации. Их эффективность обычно зависит от объема. Так что, если я уменьшу количество серверов с 2 до 1, я, возможно, сэкономлю энергопотребление одного сервера, но, вероятно, не так много на затратах на охлаждение. Но если изменение моей архитектуры позволит мне отключить 100 серверов ... это большая экономия!
Аппаратное обеспечение и периферийные устройства Использовать наиболее энергоэффективный стек ПО и запускать его на сервере Pentium 4 = глупость;) Самое энергоэффективное программное обеспечение не может компенсировать неэффективное оборудование. Вот один интересный урок: «пусть ребята из железа беспокоятся о мощности». Вы беспокоитесь о выводе своего приложения на рынок. Когда ваше приложение может приносить доход, вы всегда можете купить новейший 16-ядерный процессор Core 5 hexa-deca и мгновенно повысить энергоэффективность;)
Virtualizaton Если ваше приложение имеет небольшой объем, объединение его в виртуальную машину, работающую в многоядерной системе, вероятно, сэкономит вам больше энергии, чем его перезапись в вашем наиболее энергоэффективном стеке программного обеспечения и запуск его на автономном сервере.
Programmer Time Вам нужны программисты, знающие "самый энергоэффективный" программный стек. Вы должны подумать, правильные ли это инструменты. Программисты используют компьютеры для разработки программного обеспечения, и чем больше времени им нужно на разработку (если они ограничены неправильными инструментами), тем больше энергии потребляется. Не говоря уже о том, что вам придется платить им за большее количество часов. Обычно это перекрывает любые опасения по поводу энергопотребления, потому что затраты здесь намного выше.
Если вас беспокоит только энергоэффективность, да, используйте все инструменты в сумке, чтобы добраться туда. Но в большинстве случаев это всего лишь одна маленькая переменная в общей схеме вещей, а также наименьшая часть ваших затрат.
Более эффективный код действительно потребляет меньше ресурсов, в том числе энергии. Java в целом имеет более быструю и эффективную реализацию, поэтому при прочих равных условиях Java, вероятно, будет потреблять меньше энергии при работе на сервере.
Но все остальные факторы непостоянны . Невозможно сказать, какие изменения основаны на вашем решении использовать PHP или Java. Например, разработка Java требует больше времени, а это означает, что у программистов на Java компьютеры работают дольше, и их потребление энергии может превысить ваши сбережения на сервере.
Если вы являетесь Google, Amazon или другой компанией, которая обслуживает буквально миллиарды запросов каждый день с тысяч серверов, я бы побеспокоился об этом. В противном случае ваш масштаб недостаточно велик, чтобы делать какие-либо положительные утверждения о потреблении энергии. поэтому любое решение, которое вы примете, с такой же вероятностью будет контрпродуктивным, как и продуктивным, потому что невозможно учесть все соответствующие факторы.
Соответствующий пример - несколько месяцев назад, когда ходили слухи о том, что вы можете сэкономить энергию, установка черного фона рабочего стола. Мысль заключалась в том, что черный == нет света, поэтому вы не используете столько света. Google (одна из немногих компаний с достаточным энергопотреблением, чтобы сделать подобные исследования продуктивными) провела несколько экспериментов и провела некоторые исследования и обнаружила, что ЖК-экраны излучают белый свет, несмотря ни на что, и фильтруют его, пропуская второй ток через пиксели. по-другому. Таким образом, задав для пикселя черный цвет, вы устанавливаете его фильтрацию на максимум, фактически используя максимально возможную энергию. Самый энергосберегающий фон рабочего стола (по крайней мере, на ЖК-экране) - это белый фон. Однако, поскольку белый фон наносит вред глазам людей, немногие люди устанавливают белый фон для рабочего стола, и слухи о том, что черный фон экономит энергию, все еще распространены.
Короче говоря, беспокойство об этом, вероятно, принесет больше вреда. чем хорошо.
This is the same question as what language has the best performance. Now then, for just about every project most programmers ever get in contact with. How you write the system by far outweighs the technologies used (given that the system is speced ok).
The choice of language wrt performance is imho for embedded systems and scientists. You choose language according to what problem to solve, extremely seldom for how cpu efficient it is.
Again, it is how you design and write the system that determines how efficient it will be.
Очевидно, что современные вычислительные технологии используют намного больше ресурсов, чем раньше, и это напрямую связано с энергопотреблением. Однажды мы d использовать простой старый сокет для передачи двоичных данных по сети, и процессор 100 МГц будет обрабатывать его, теперь у нас есть программный стек, в котором данные преобразуются в текст XML, а затем передаются через веб-службу через http через тот же сокет, и мы задаемся вопросом, зачем нам нужен процессор с частотой 3 ГГц с оперативной памятью, чтобы получить достойную производительность :)
Итак, проблема в том, что единственное, что вы можете с этим сделать, - это сделать свой код более эффективным. Обычно это означает использование языка более низкого уровня и меньшую зависимость от фреймворков или библиотек общего назначения. Определенно не пытайтесь наслоить программные стеки, если вы ничего не можете с этим поделать.
Современному программированию это не нравится - есть толчок к повышению производительности программистов, нанимая более дешевых программистов, и все время переделывать код (т.е. переписывать его), чтобы код было легко создавать (а иногда и поддерживать). В результате, чтобы получить максимальную отдачу, вам нужно будет найти компромисс между этими факторами. Стандартный отраслевой способ сделать это - просто смешивать системы в соответствии с их использованием.
В настоящее время максимальная производительность - это код C / C ++, а максимальная продуктивность программиста, похоже, связана с языками сценариев. Итак, идеальный вариант - написать основную бизнес-логику на языке сценариев, таком как Python, и использовать его для вызова специальных «мощных помощников», написанных на C / C ++. Если вам нужна большая производительность, вы можете написать больше кода на базовом C / C ++. Если вам нужна более быстрая разработка RAD, пишите больше на языке сценариев.
Мой совет для OP - не переписывать на Java, он может быть лучше в целом, но вы ' будет стоить так дорого, что может не стоить того. Вместо этого возьмите наиболее интенсивные части вашего приложения и перепишите их настолько эффективно, насколько сможете, и вызовите их из существующего PHP. затем взгляните на свою общую архитектуру и уменьшите зависимость от неэффективных протоколов и структур данных. Например: если вы замените XML на JSON, вы обнаружите, что у вас та же функциональность, но с небольшой долей размера данных и ресурсов, необходимых для анализа и переформатирования данных.
Хотя многие аспекты, касающиеся этого вопроса, уже были подробно исследованы здесь, есть по крайней мере еще один, на который стоит обратить внимание.
Типичное веб-приложение PHP дублирует много усилий из один запрос к другому просто потому, что среда выполнения PHP (или контекст) не сохраняется между запросами.
Поскольку типичное веб-приложение Java имеет возможность сохранять состояние напрямую, без дополнительных шагов или недействительности кеша, ему не нужно, например, выполнять дублирующие SQL-запросы в стиле PHP для извлечения та же информация для каждого запроса. Вместо этого веб-приложение Java часто хранит сложную информацию для текущего анализа в собственной структуре данных в куче, доступ к которой осуществляется за наносекунды, а не за миллисекунды.