Perl vs C в веб-приложениях, результаты теста

    Я давно хотел проверить, насколько больше запросов сможет обработать C-процесс, в сравнении с Perl-скриптом.
    Проверял на простом скрипте с одним SQL-запросом, дабы избежать влияния mysql. Веб-сервер nginx, использовалось FastCGI.

    Подопытный — скрипт голосования: принимает 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 раза.

    З.Ы. Очень хотелось запостить это в «Веб-разработку», но, видимо, кармой не вышел. :) Если кто добавит кармы — буду благодарен.
    А пока посты на схожую тематику можно почитать у меня в блоге: http://blog.ugnich.com/

    Комментарии 26

      0
      В следующий раз пробуйте ассемблер, коллега (:
        0
        Мне больше нравится идея модуля к ядру, по типу khttpd в линуксе. :)
          0
          Lighttpd и nginx дают практически ту же скорость без соответствующей кучи проблем.
            0
            Не воспринимайте всерьез. Это была такая же шутка, как и про ассемблер. ;)
              0
              Но ведь кто-то может принять её всеръез ибо на ассемблере никто веб-сайтов не пишет, а TUX реально существует (и я его даже несколько лет назад использовал) - просто сейчас нужды в нём уже нет...
        +1
        Подскажите, что еще почитать (желательно на русском) по использованию C в веб-приложениях.
        Может есть примеры, решения.
        • НЛО прилетело и опубликовало эту надпись здесь
            0
            Взял из головы, а что?
            Перед этим смотрел в интернете, нет ли каких устоявшихся методик тестирования, но ничего конкретного не нашел.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Один - точно мало. Можно бы было около 5-и, но в тестировании лучше перенагрузить, чем недонагрузить.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Нет:
                    Complete requests: 1000
                    • НЛО прилетело и опубликовало эту надпись здесь
            0
            Очень хотелось бы посмотреть на исходники сравниваемых программ. Лично мне хотелось бы попытаться воспроизвести эксперимент на реальном стабильном сервере.
              0
              ОК, Выложу немного позже.
                0
                http://ugnich.com/vote/vote.pl.txt
                http://ugnich.com/vote/vote.c.txt
                Кое-что лишнее повыкидывал из них, что к делу не относится. А в остальном - тестируйте на здоровье. Если где будете постить результаты - не забудьте ссылку на blog.ugnich.com, ну и мне сообщите, с удовольствием почитаю.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Нет, не тестировал. Предпочитаю nginx. :)
                0
                По-моему, абсолютно очевидно, что на Си почти всё будет быстрее. Однако "почти" — это не значит, что всё. Скорость и сложность разработки web-приложений на Си оставляет этот язык далеко позади PHP и прочих, специально заточенных для web, языков. На Си невыгодно писать программы с малым сроком жизни.
                Если сайт или его часть работает медленно, то прибегают к оптимизации кода. Если оптимизация не помогла, то прикручивают всякие ускорители и кеширующие инструменты. Если и это не помогает, то тут разработчики ещё очень крепко призадумуются, стоит ли часть функциональности перекладывать на плечи Си или проще и дешевле обновить сервер...
                Почему дешевле, да потому, что время Си-программиста стоит гораздо дороже PHP-программиста.
                Так что сравнения "C vs PHP/Ruby/JSP/... для web" изначально некорректны и однозначно Си останется в проигрыше (хотя бы потому, что предназначен он для решения других задач).
                Да, не спорю, для собственного развития можно попрактиковать такой подход. Но в крупных, динамически развивающихся проектах, когда код одного файла в течении дня может поменяться почти полностью (причём несколько раз), Си делать нечего. С ним разработка пойдёт гораздо медленнее, хотя вроде делов-то всего ничего — отредактировать исходник и две секунды на компиляцию... уж поверьте.
                  0
                  Несмотря на то что в последнее время больше всего пишу на C/C++ - поддерживаю и одобряю. Проблема большинства web-проектов - это черезмерная нагрузка на SQL-сервер. Тут никакой C не спасёт. А вот если вы переросли одну машину с SQL-сервером - тут уже и до необходимости использовать C/C++ недалеко...

                  Вообще число три (для красоты многие говорят про "пи") - оно магическое: C может позволить в три раза сократить потребности в оборудовании, но втрое же замедляет разработку. Посчитайте баланс - и сразу станет ясно: нужен вам C/C++ или нет... Считать погоду или ядрёную бомбу на кластере в 100'000 CPU - ясно что даже не C/C++, а FORTRAN: все затраты окупятся сколько бы программисты ни стоили. А вот web-сайт на трёх машинках - тут вряд ли...
                    0
                    > Проблема большинства web-проектов - это черезмерная
                    > нагрузка на SQL-сервер...
                    > А вот если вы переросли одну машину с SQL-сервером -
                    > тут уже и до необходимости использовать C/C++ недалеко...
                    Те же яйца, но в профиль. Если SQL-сервер сильно нагружен, то тут и Си ему не поможет. Си только обработает данные быстрее. А извлечёт он их из БД с той же скоростью что и другие языки.
                      0
                      Если с данными не справляется при должной оптимизации один мощный сервер, то нужно разводить кластер, предобработку, постобработку, очереди и прочая, прочая. В тяжелых случаях идёт отказ от SQL вообще. Когда в проекте возникают такие сложности - скорость разработки неизбежно падает независимо от языка, стоимость оборудования растёт и затраты на C/C++-программиста уже не кажутся черезмерными...

                      Это не закон - это просто хорошо работающее правило...
                      0
                      Вы забываете что веб-проектами могут быть не только форум, социальная сеть или поисковик, работающие на полноценном "большом" сервере, но и веб-интерфейс для какого-либо оборудования, например для ADSL-модема или маршрутизатора.
                        0
                        Для оборудования обычно веб- интерфейс не испытывает больших нагрузок =)
                          +1
                          Согласен, но и железо используется не самое мощное. Я не знаю как там на самом деле, может и правда на С уже все давно забили. Но у меня есть повод верить в С как язык и для веба тоже. Год назад проскакивала вакансия в D-Link и была такая вот тестовая задача:

                          Требуется некий тестовый проектик. ANSI C. Без плюсов-классов-пых-пыхов и прочих перлов и яв(жав,джав). Выдаёт HTML-страниицы на stdout. Требования:

                          a) Многостраничность.
                          б) Поддержка линков не только во внешний инет, но и на свои эти вот страницы.
                          в) Структурированность, логичность и масштабируемость кода... хоть и будет это оцениваться достаточно субъективно(с нашей точки зрения :-)).
                          г) Устойчивость к ошибкам. Всё и всегда должно проверяться. При возникновении
                          каких-либо неполадок, будь то неверный запрос или отсутствие переменной
                          окружения, etcetera, пользователь должен подробно уведомляться о проблемах
                          посредством того же HTML. Падение работы бинаря(типа "ошибки сегментации".. ну или "access violation" в оффтопике) - недопустимый случай.
                          д) Приветствуется многосырцовость, наличие хидеров и, вообще, юниксвей.
                          е) Формирование проекта на основе automake/autoconfig будет воспринято "на
                          ура", хотя здесь может быть удобней написать makefile самостоятельно. На выбор.
                            0
                            Для мелкого железа есть lua.

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

                  Самое читаемое