Как я могу сравнить различные языки / фреймворки?
Я хотел бы сравнить производительность разных языков и / или разных фреймворков на одном языке. Это нацелено на серверные языки, используемые для веб-разработки. Я знаю, что сравнение яблок с яблоками невозможно, но я бы хотел, чтобы это было как можно более объективно. Вот несколько идей:
- Простая страница "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/
Но если вам действительно нужно выяснить, какая инфраструктура будет быстрее для ВАШЕГО проекта, вам нужно будет написать модель вашего проекта с использованием этой инфраструктуры и протестировать ее.
Вы проведете много времени и поймете, что все было потрачено впустую.
После завершения тестов вы узнаете, что циклы из 1000000 пустых итераций далеки от реальной жизни и достигают уровня Apache.
Тогда вы не узнаете о кэшах опкодов, которые разрушат все ваши предыдущие результаты.
Затем вы узнаете, что один запрос к БД займет в 1000 раз больше времени, чем вызов API, поэтому ваши сравнения методов доступа к базе данных действительно бесполезны.
Затем вы узнаете о memcache, который позволит вам просто перепрыгнуть через некоторые ужасные узкие места, которые вы уже обнаружили, и т. Д. И т. Д. И т. Д.