Comments 26
В следующий раз пробуйте ассемблер, коллега (:
Мне больше нравится идея модуля к ядру, по типу khttpd в линуксе. :)
Не воспринимайте всерьез. Это была такая же шутка, как и про ассемблер. ;)
Но ведь кто-то может принять её всеръез ибо на ассемблере никто веб-сайтов не пишет, а TUX реально существует (и я его даже несколько лет назад использовал) - просто сейчас нужды в нём уже нет...
Подскажите, что еще почитать (желательно на русском) по использованию C в веб-приложениях.
Может есть примеры, решения.
Может есть примеры, решения.
UFO just landed and posted this here
Очень хотелось бы посмотреть на исходники сравниваемых программ. Лично мне хотелось бы попытаться воспроизвести эксперимент на реальном стабильном сервере.
ОК, Выложу немного позже.
http://ugnich.com/vote/vote.pl.txt
http://ugnich.com/vote/vote.c.txt
Кое-что лишнее повыкидывал из них, что к делу не относится. А в остальном - тестируйте на здоровье. Если где будете постить результаты - не забудьте ссылку на blog.ugnich.com, ну и мне сообщите, с удовольствием почитаю.
http://ugnich.com/vote/vote.c.txt
Кое-что лишнее повыкидывал из них, что к делу не относится. А в остальном - тестируйте на здоровье. Если где будете постить результаты - не забудьте ссылку на blog.ugnich.com, ну и мне сообщите, с удовольствием почитаю.
UFO just landed and posted this here
По-моему, абсолютно очевидно, что на Си почти всё будет быстрее. Однако "почти" — это не значит, что всё. Скорость и сложность разработки web-приложений на Си оставляет этот язык далеко позади PHP и прочих, специально заточенных для web, языков. На Си невыгодно писать программы с малым сроком жизни.
Если сайт или его часть работает медленно, то прибегают к оптимизации кода. Если оптимизация не помогла, то прикручивают всякие ускорители и кеширующие инструменты. Если и это не помогает, то тут разработчики ещё очень крепко призадумуются, стоит ли часть функциональности перекладывать на плечи Си или проще и дешевле обновить сервер...
Почему дешевле, да потому, что время Си-программиста стоит гораздо дороже PHP-программиста.
Так что сравнения "C vs PHP/Ruby/JSP/... для web" изначально некорректны и однозначно Си останется в проигрыше (хотя бы потому, что предназначен он для решения других задач).
Да, не спорю, для собственного развития можно попрактиковать такой подход. Но в крупных, динамически развивающихся проектах, когда код одного файла в течении дня может поменяться почти полностью (причём несколько раз), Си делать нечего. С ним разработка пойдёт гораздо медленнее, хотя вроде делов-то всего ничего — отредактировать исходник и две секунды на компиляцию... уж поверьте.
Если сайт или его часть работает медленно, то прибегают к оптимизации кода. Если оптимизация не помогла, то прикручивают всякие ускорители и кеширующие инструменты. Если и это не помогает, то тут разработчики ещё очень крепко призадумуются, стоит ли часть функциональности перекладывать на плечи Си или проще и дешевле обновить сервер...
Почему дешевле, да потому, что время Си-программиста стоит гораздо дороже PHP-программиста.
Так что сравнения "C vs PHP/Ruby/JSP/... для web" изначально некорректны и однозначно Си останется в проигрыше (хотя бы потому, что предназначен он для решения других задач).
Да, не спорю, для собственного развития можно попрактиковать такой подход. Но в крупных, динамически развивающихся проектах, когда код одного файла в течении дня может поменяться почти полностью (причём несколько раз), Си делать нечего. С ним разработка пойдёт гораздо медленнее, хотя вроде делов-то всего ничего — отредактировать исходник и две секунды на компиляцию... уж поверьте.
Несмотря на то что в последнее время больше всего пишу на C/C++ - поддерживаю и одобряю. Проблема большинства web-проектов - это черезмерная нагрузка на SQL-сервер. Тут никакой C не спасёт. А вот если вы переросли одну машину с SQL-сервером - тут уже и до необходимости использовать C/C++ недалеко...
Вообще число три (для красоты многие говорят про "пи") - оно магическое: C может позволить в три раза сократить потребности в оборудовании, но втрое же замедляет разработку. Посчитайте баланс - и сразу станет ясно: нужен вам C/C++ или нет... Считать погоду или ядрёную бомбу на кластере в 100'000 CPU - ясно что даже не C/C++, а FORTRAN: все затраты окупятся сколько бы программисты ни стоили. А вот web-сайт на трёх машинках - тут вряд ли...
Вообще число три (для красоты многие говорят про "пи") - оно магическое: C может позволить в три раза сократить потребности в оборудовании, но втрое же замедляет разработку. Посчитайте баланс - и сразу станет ясно: нужен вам C/C++ или нет... Считать погоду или ядрёную бомбу на кластере в 100'000 CPU - ясно что даже не C/C++, а FORTRAN: все затраты окупятся сколько бы программисты ни стоили. А вот web-сайт на трёх машинках - тут вряд ли...
> Проблема большинства web-проектов - это черезмерная
> нагрузка на SQL-сервер...
> А вот если вы переросли одну машину с SQL-сервером -
> тут уже и до необходимости использовать C/C++ недалеко...
Те же яйца, но в профиль. Если SQL-сервер сильно нагружен, то тут и Си ему не поможет. Си только обработает данные быстрее. А извлечёт он их из БД с той же скоростью что и другие языки.
> нагрузка на SQL-сервер...
> А вот если вы переросли одну машину с SQL-сервером -
> тут уже и до необходимости использовать C/C++ недалеко...
Те же яйца, но в профиль. Если SQL-сервер сильно нагружен, то тут и Си ему не поможет. Си только обработает данные быстрее. А извлечёт он их из БД с той же скоростью что и другие языки.
Если с данными не справляется при должной оптимизации один мощный сервер, то нужно разводить кластер, предобработку, постобработку, очереди и прочая, прочая. В тяжелых случаях идёт отказ от SQL вообще. Когда в проекте возникают такие сложности - скорость разработки неизбежно падает независимо от языка, стоимость оборудования растёт и затраты на C/C++-программиста уже не кажутся черезмерными...
Это не закон - это просто хорошо работающее правило...
Это не закон - это просто хорошо работающее правило...
Вы забываете что веб-проектами могут быть не только форум, социальная сеть или поисковик, работающие на полноценном "большом" сервере, но и веб-интерфейс для какого-либо оборудования, например для ADSL-модема или маршрутизатора.
Для оборудования обычно веб- интерфейс не испытывает больших нагрузок =)
Согласен, но и железо используется не самое мощное. Я не знаю как там на самом деле, может и правда на С уже все давно забили. Но у меня есть повод верить в С как язык и для веба тоже. Год назад проскакивала вакансия в D-Link и была такая вот тестовая задача:
Требуется некий тестовый проектик. ANSI C. Без плюсов-классов-пых-пыхов и прочих перлов и яв(жав,джав). Выдаёт HTML-страниицы на stdout. Требования:
a) Многостраничность.
б) Поддержка линков не только во внешний инет, но и на свои эти вот страницы.
в) Структурированность, логичность и масштабируемость кода... хоть и будет это оцениваться достаточно субъективно(с нашей точки зрения :-)).
г) Устойчивость к ошибкам. Всё и всегда должно проверяться. При возникновении
каких-либо неполадок, будь то неверный запрос или отсутствие переменной
окружения, etcetera, пользователь должен подробно уведомляться о проблемах
посредством того же HTML. Падение работы бинаря(типа "ошибки сегментации".. ну или "access violation" в оффтопике) - недопустимый случай.
д) Приветствуется многосырцовость, наличие хидеров и, вообще, юниксвей.
е) Формирование проекта на основе automake/autoconfig будет воспринято "на
ура", хотя здесь может быть удобней написать makefile самостоятельно. На выбор.
Требуется некий тестовый проектик. ANSI C. Без плюсов-классов-пых-пыхов и прочих перлов и яв(жав,джав). Выдаёт HTML-страниицы на stdout. Требования:
a) Многостраничность.
б) Поддержка линков не только во внешний инет, но и на свои эти вот страницы.
в) Структурированность, логичность и масштабируемость кода... хоть и будет это оцениваться достаточно субъективно(с нашей точки зрения :-)).
г) Устойчивость к ошибкам. Всё и всегда должно проверяться. При возникновении
каких-либо неполадок, будь то неверный запрос или отсутствие переменной
окружения, etcetera, пользователь должен подробно уведомляться о проблемах
посредством того же HTML. Падение работы бинаря(типа "ошибки сегментации".. ну или "access violation" в оффтопике) - недопустимый случай.
д) Приветствуется многосырцовость, наличие хидеров и, вообще, юниксвей.
е) Формирование проекта на основе automake/autoconfig будет воспринято "на
ура", хотя здесь может быть удобней написать makefile самостоятельно. На выбор.
Sign up to leave a comment.
Perl vs C в веб-приложениях, результаты теста