Perl vs C
Zend, eAccelerator, memcached — что только
люди не придумают, лишь бы на C не писать! 
Любой ньюб знает, что “на C — быстрее, а на asm-е — ва-а-аще со скоростью света летать будет”. Только ни один ньюб не знает, на сколько именно быстрее. Ибо ньюб.
Я давно хотел проверить, насколько больше запросов сможет обработать C-процесс, в сравнении с Perl-скриптом.
Подопытный — скрипт голосования: принимает id из QUERY_STRING, IP-адрес из REMOTE_ADDR и добавляет их простым INSERT-ом в таблицу mysql. Немного подробнее о таком принципе занесения голосов я писал в Tips&Tricks 2. Оба варианта подключались к веб-серверу (nginx) по FastCGI через unix socket.
Perl-скрипт использовал CGI::Fast и DBI. Для C-варианта я использовал библиотеку fcgi_stdio, тесты проводились на моем скромном VPS с CentOS. Из-за того, что физическим сервером пользуюсь не я один, получился небольшой разброс в абсолютных значениях, но относительная разница оставалась очень ощутимой.
Тестировалось стандартным ab -n 1000 -c 10, “Requests per second”, средние значения:
Perl: 933 запроса/сек
C: 2896 запроса/сек (в 3 раза больше!)
Напоминаю, тесты повторял несколько раз, цифры немного отличались, но всегда разница была примерно в 3-4 раза.
А еще, кроме выигрыша в производительности, C-процесс занимает в несколько раз меньше памяти. В моем случае — в 3.5 раза.
Filed under: Технологии | 19 Comments
Tags: c, fastcgi, perl
Даже вчитываться не стал.
Не смеши сравнивать интерпретатор и скомпилированный код.
2KMiNT21: см. первый абзац.
Мне было интересно, насколько быстрее.
ох.. ну понятно что на си оно быстрее, но пример имхо не очень убедительный вышел, там же видимо через либы к mysql подключается, и собственно подключение к бд и вставка время кушают , так что говорить что именно сравнивается перловый скрипт с сишным видимо здесь не очень уместно ))
2kwt: подключение к БД происходит один раз при старте скрипта/бинарника. Что касается выполнения запроса — абсолютное большинство веб-приложений работают с БД, так что без этого никуда.
угу, но все ж контрольку с скриптом который что-то типа print-а обычного делает, то
же надо было бы сделать, для ясности в каких там местах выигрыш идет,
все одно спасибо – мне тема интересная, я данные на сервак таким способом иногда закачиваю, через интерфейсный скрипт который который их в таблицы инсертит, попробую на си сделать приемник и поковыряться (сейчас на PHP) – вдруг и впрямь все так волшебно окажется
2kwt: лучше INSERT DELAYED попробуйте или LOAD DATA, а такие вещи я бы переписывать не стал.
Уважаемый Антон! Не могли бы Вы пояснить причину использования “-c 10″ в ab?
Скрипты в студию… Имхо затык должен был быть на стороне mysql… Что-то не вериться что обработка запроса занимает сильно больше времени чем складирование его в базу… В общем смутные сомнения )))
2Igor Gerdler: ИМХО, это нормальное значение для эмуляции пиковой загрузки. Можно бы было и чуть меньше, но во время тестов лучше перенагрузить, чем недонагрузить.
2Vinny: обычный INSERT, таблица небольшая. Чего ему затыкаться-то?!
http://ugnich.com/vote/vote.pl.txt
http://ugnich.com/vote/vote.c.txt
Из скриптов кое-что чуть-чуть повыкидывал, но оно к делу не относится.
Антон, Вы не указали, сколько использовалось FastCGI экземпляров. Я предположил, что один (это нормальный, с моей точки зрения, вариант), тогда непонятно, зачем использовать 10 одновременных обращений, т.к. разницы с одним обращением не будет никакой. Если количество экземпляров 10, не могу согласиться, что это “нормальное значение для эмуляции пиковой загрузки”. Возможно 100 (или лучше 256, как максимальное значение для Apache при компиляции по умолчанию – хоть какое-то оправдание), но никак не 10.
Антон, в дополнение предлагаю померять производительность модифицированного кода:
#!/usr/bin/perl
use strict;
use DBI;
use CGI::Fast;
my $dbh=DBI->connect(”dbi:mysql:dbname=db;host=localhost”,”login”,”passw”);
$dbh->{mysql_auto_reconnect}=1;
my $sth = $dbh->prepare(’INSERT INTO table(f1,f2) VALUES (?,?)’);
FCGI: while(my $q=new CGI::Fast()) {
my $id=$q->param(’id’) || 0;
if($id>0) {
if( $sth->execute( $id, INET_ATON($ENV{’REMOTE_ADDR’}) ) eq ‘0E0′ ) { print “Status: 403 Forbidden\n\n”; }
else { print “Status: 200 OK\n\n”; }
} else { print “Status: 500 Internal Server Error\n\n”; }
}
Только не относительно perl и C, а относительно Вашего и этого варианта. При условии разных REMOTE_ADDR, результаты могут несколько изменится.
И для чего использовать INET_ATON, разве REMOTE_ADDR на нагруженном сервере может быть доменным именем?
2Igor Gerdler: да, один экземпляр. Разница небольшая есть, nginx ведь запросы в очередь ставит. Ну а я старался по-ближе к реальным боевым действиям.
Что касается тестирования, прошу меня простить, но вряд ли смогу сейчас этим заняться. Кусок кода, который мы рассматриваем — это часть проекта, запуск которого намечен на понедельник. Надеюсь, вы понимаете…
В принципе, мои исходники у вас есть, может быть, вы сами проведете небольшой тест?
Интересная статья!
2Ugnich Anton: я предполагал что вставка строки в базу будет занимать существенное время работы программы…Видимо, по крайней мере для перла, это не так… Что ж, рад за mysql, шустро
2Vinny: mysql ведь тоже не в дефолтной конфигурации.
2Виктор: ну хоть бы пару слов по теме, а то на спам похоже.
Значит так а почему тогда большинство высоконагрузочных сервисов типа mail.ru на перл пхп и других скриптах???
) Вот так. Поэтому скриптам лучше поручить много мелких запросов, но оч часто, а СИ коду большие объёмы данных но редко ))
не помню где читал почему для веба используют именно скрипты. Во время исполнения С приложения порождается поток а он занимает память и процессорное время.(я могу немного ошибаться рекомендую точно выяснить у гуру dklab.ru например
Автор ищи больше инфы!
2generator2003:
На чем эти сервисы написаны и как работают — мы с вами точно знать не можем.
Почитайте про FastCGI.
С точностью до наоборот. Частые одинаковые запросы должны обрабатывать быстрые FastCGI-процессы, а редкие и разные обращения — обычные скрипты.
Никогда про таких не слышал.
Знаю только КЕНгуру. 
Автору спасибо за тестирование и скрипты доступные для скачивания! В интернете все в основном устраивают “священные войны” по-поводу того какой язык “самый-самый”, а Ugnich Anton взял да и протестировал в “боевый условиях” взаимодействие Perl и C с MySQL.
Браво!
А что, спасибо.. есть повод задуматься