Как я могу сравнить различные языки / фреймворки?

Я хотел бы сравнить производительность разных языков и / или разных фреймворков на одном языке. Это нацелено на серверные языки, используемые для веб-разработки. Я знаю, что сравнение яблок с яблоками невозможно, но я бы хотел, чтобы это было как можно более объективно. Вот несколько идей:

  • Простая страница "Hello World"
  • Инициализация объекта
  • Вызовы функций / методов
    • Тела метода будут варьироваться от пустых до больших
  • Доступ к файлу (чтение и запись)
  • Доступ к базе данных

Они могут быть измерены с помощью запросов в секунду, или я могу использовать for петля и петля много раз. Некоторые из этих тестов должны измерять накладные расходы, которые имеет язык (то есть: пустой вызов функции), а не то, насколько быстро они выполняют определенную задачу. Я приму некоторые меры предосторожности:

  • Они будут работать на той же машине, на новых установках с минимальным количеством процессов в фоновом режиме.
  • Я постараюсь настроить сервер в соответствии с официальной рекомендацией; Я не буду пытаться какие-либо оптимизации.

Как я могу улучшить это?

Источник

4 ответа

Решение

Я написал много модульных тестов, чтобы вы могли тестировать слои.

Например, напишите веб-сервис SOAP на PHP, Python и C#.

Написать веб-сервис REST на тех же языках (те же веб-сервисы, только два способа добраться до них). Этот должен иметь возможность возвращать JSON и XML как минимум.

Напишите модульные тесты на C# и Python для обслуживания клиентов и протестируйте REST с различными типами результатов (XML/JSON). Это важно, так как позже вам может потребоваться проверить, какой из них лучше всего подходит для конца, и JSON может быть быстрее для вас, чем XML, для вас (так и должно быть).

Таким образом, службы REST/SOAP должны идти к одному контроллеру, чтобы упростить вашу жизнь.

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

Я бы использовал одну базу данных для этого, если вы не хотите оценивать различные базы данных, но для веб-теста, просто сделайте это для фазы 2.:)

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

Затем у вас есть много цифр, и вы можете начать анализировать, чтобы увидеть, что работает лучше для вас.

Например, я узнал (пару лет назад, когда я это сделал), что JSON быстрее XML, а REST быстрее SOAP.

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

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

Я бы сделал это с каким-то реальным приложением, чтобы работа не пропадала, а просто дублировалась.

Источник

На http://shootout.alioth.debian.org/ есть много полезных советов (и огромное количество примеров тестов для разных языков).

C.

Источник

Лучше взять один из существующих тестов:

http://www.sellersrank.com/web-frameworks-benchmarking-results/

http://avnetlabs.com/php/php-framework-comparison-benchmarks

http://www.yiiframework.com/performance/

http://www.google.ru/search?q=php+benchmark+frameworks&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:ru:official&client=firefox

Но если вам действительно нужно выяснить, какая инфраструктура будет быстрее для ВАШЕГО проекта, вам нужно будет написать модель вашего проекта с использованием этой инфраструктуры и протестировать ее.

Источник

Вы проведете много времени и поймете, что все было потрачено впустую.
После завершения тестов вы узнаете, что циклы из 1000000 пустых итераций далеки от реальной жизни и достигают уровня Apache.
Тогда вы не узнаете о кэшах опкодов, которые разрушат все ваши предыдущие результаты.
Затем вы узнаете, что один запрос к БД займет в 1000 раз больше времени, чем вызов API, поэтому ваши сравнения методов доступа к базе данных действительно бесполезны.
Затем вы узнаете о memcache, который позволит вам просто перепрыгнуть через некоторые ужасные узкие места, которые вы уже обнаружили, и т. Д. И т. Д. И т. Д.

Источник
Другие вопросы по тегам