35

为什么像 C 这样的语言最终没有被用于 Web 开发?编译后的速度提升肯定对重负载站点有用吗?

4

15 回答 15

27

另一个很好的理由是,在大型服务器上,执行速度与其说是连接速度问题,不如说是连接速度问题。大部分时间都花在发送和接收数据上,而不是数字运算上。实际上,在某些进行大量计算的 Web 服务中硬运算可能作为编译程序运行的。

另外,解释型语言不需要编译(在大型项目中可能需要时间),因此它更适合 Web 解决方案的典型敏捷开发。

于 2008-12-04T11:50:18.060 回答
24

大多数 Web 应用程序都与数据库通信。绝大多数这些应用程序几乎将所有时间都花在与数据库通信上。因此,对于应用程序的任何给定请求,应用程序服务器中的处理量很小,然后在等待数据库时会出现长时间的停顿。由于任何请求的一小部分时间都花在了实际的应用程序服务器代码上,因此通过用 C/C++ 编写代码来优化该代码只会在响应时间上获得很小的、可能不明显的改进。

因此,与其专注于 C/C++ 并节省最后一个 CPU 周期,不如担心开发人员的工作效率。开发人员非常昂贵。而且,它们在脚本语言甚至 Java 中的生产力通常比在 C/C++ 中高得多。

当然,这也有例外。如果对您的应用程序的某些请求是 CPU 或内存密集型的,它们应该用 C/C++ 编写。但是,对于您的应用程序的其余部分,您最好专注于优化您的算法、数据结构、与数据库的通信以及开发人员的生产力,而不是优化您的语言。

于 2008-12-04T12:34:11.073 回答
14

与 C 相比,脚本语言具有以下优点:

  1. 更快的发展
  2. 今天,所有与这个问题相关的内容都是在运行时编译的。在某些情况下,这可以使它们比等效的 C 程序更快,因此性能不再是问题。
  3. 维护成本低得多
  4. 您可以使用敏捷方法(如单元测试)进行开发,这会产生更好的代码。是的,你也可以在 C 中做到这一点,但要付出更多的努力。
  5. 当您进行 Web 开发时,您拥有可以为您完成大部分工作的庞大框架。
  6. 他们更愿意改变。实施一项新功能可能需要几分钟时间。
  7. 如果出现问题,您可以登录服务器,在控制台中启动文本编辑器并修复问题,有时无需重新启动。
于 2008-12-04T12:24:02.810 回答
11

C 早期用于 Web 应用程序 - 我在其中编写了各种 CGI 脚本。

然而,随着时间的推移,效率更高的语言(例如 C# 和 Java - 当然不只是那些)已被证明对于 Web 应用程序来说“足够高效”。请注意,C# 和 Java 都被编译为中间代码,然后进行 JIT 编译,从而实现“大致”本机代码性能。为什么我们要使用 C 来代替?

据我所知,即使是传统的“真正解释”的语言,如 PHP,现在也经常在执行时编译。(特别是我对 PHP 的了解都是二手的。也许它总是被编译过......同样我确信有些网络平台仍然总是被解释。)

于 2008-12-04T11:48:23.337 回答
9

至少在最初,后端代码(我假设您正在谈论的内容)所做的很多工作都是面向文本的。他们要么直接从头开始构建页面,要么将数据库中的数据与模板结合起来。

C 并不...总是非常适合文本处理。C 字符串是非常基本的,虽然 C 中的文本处理当然可以快速执行,但开发起来通常需要更长的时间,并且需要一些更深的技能才能正确,而不是帮助你更多的语言。

于 2008-12-04T11:45:18.740 回答
9

好问题。原因基本上是由于网络的发展。分步骤思考:

1)“网络”上的基本文本 -> 2)添加到文本中的一些“标记” -> 3)“中心”标签和“选框”形成!!!什么进展!!!-> 4) 在客户端编写脚本!!!5) -> 嗯...在服务器上编写脚本!!!

虽然我形成这个答案有点愚蠢,但这是真的。互联网,尤其是“网络”,是一个惊人的进化过程。确实,更强大的语言(和更高性能的语言)的需求只是最近才出现的。

另外,看看工具。我在记事本(和其他一些简单的应用程序)中做了我的 PHP。当我第一次做 Web 开发时,我的电脑没有足够的硬盘空间来支持 Visual Studio 2008 :)

旁白但是:那里有“.exe”应用程序(我认为“ SunBiz ”发布到“exe”),并且有一段时间编译了cgi应用程序,但它们要少得多。

于 2008-12-04T12:30:10.693 回答
9

值得指出的是,大多数脚本语言(Python、Ruby 等)很容易(几乎是微不足道地)桥接到 C。(我刚刚为 Python 程序编写了一些 C 扩展,它的简单程度给我留下了深刻的印象。)如果网站/Web 应用程序由于使用“慢”脚本语言确实存在一些瓶颈,通常可以使用 C 等更快的语言编写性能关键部分。事实上,这就是 Google 搜索、Facebook 等大型应用程序等等,确实如此——他们用脚本语言编写界面,并使用 C 等其他语言完成繁重的工作。

于 2008-12-04T14:05:28.723 回答
7

这主要是因为动态更改它们既快速又简单。编译语言需要一个必须与服务器匹配的开发环境。使用脚本,您可以使用 ftp 工具直接编辑文本然后保存。这种从任何操作系统或类型​​的任何计算机上执行此操作的能力已经多次挽救了我的生命(或者正确地说是我的网站生命)。

于 2008-12-04T12:00:56.603 回答
7

尝试在 Perl/PHP 中的 C 中进行一些字符串解析/操作,您就会知道。

BTW:为什么这么多人说性能不再是问题?对于小型主页/博客,我可能不是问题,但是大型 Web 应用程序仍然需要针对性能(cpu/网络/内存)进行调整,无论它们是用 java、php 还是 ruby​​ 编写的。

于 2008-12-04T12:50:14.740 回答
2

因此,与其专注于 C/C++ 并节省最后一个 CPU 周期,不如担心开发人员的工作效率。开发人员非常昂贵。而且,它们在脚本语言甚至 Java 中的生产力通常比在 C/C++ 中高得多。

哦,非常非常真实。如果使用更动态的语言将开发人员的一周时间缩短,那么您无需支付的那一周的程序员时间将为您购买额外的服务器。甚至多台服务器,如果您喜欢大量便宜的服务器而不是一些庞大的野兽。

对于世界上的大部分地区(即,不是谷歌/亚马逊/eBay/等),一台额外的服务器将足以弥补语言选择可能导致的任何原始性能损失。

于 2008-12-04T14:50:27.633 回答
1

以下是我对这个问题的看法:

  • 原始的 CGI 应用程序需要自己的操作系统进程,这当然是一种资源消耗。使用原生代码尝试将所有内容捆绑到一个进程中也不容易,因为如果应用程序出现问题,很容易导致整个服务器瘫痪。使用解释器或虚拟机更容易处理这些事情。你当然可以对本机代码做同样的事情,但我想实现框架会困难得多。最后,您将最终实现类似于解释器或 VM 的东西。
  • 解释语言可以跨操作系统移植。
  • 当然,最大的好处是您通过使用现代语言获得的生产力提升。
  • 性能当然很重要。然而,解释或 VM 语言在这方面变得越来越好(使用 JIT 编译等技术)并且正在接近本机代码的性能。此外,仅比较执行过程中花费的时间也是不公平的。您需要测量整个序列:接收来自服务器的请求、委托给适当的应用程序、执行、将结果返回给服务器。在所有这些方面,本机应用程序会更快吗?
于 2008-12-04T13:34:11.983 回答
1

动态语言的许多非常有用的特性,比如内省和像 eval() 这样的函数真的很难/不可能吗?以编译为本机代码的语言实现。

话虽如此,大多数“脚本”语言确实(即时)编译为某种中间代码,然后将其解释为(Python、Ruby、Perl),甚至可能 JIT 编译为本机代码(JSP、.NET)

于 2008-12-04T15:01:58.733 回答
0

我的公司为我们的 webapp 使用 C++(一个 ISAPI 扩展)。几乎所有内容都在编译后的二进制文件中完成。我们还将 JavaScript 引擎用于需要编写脚本的系统部分(是的,服务器端 JavaScript)。引用此设计的原因是速度,但年龄也是一个因素……这是一个旧代码库。此外,我们将我们的产品分发给我们的一些客户以托管他们自己,因此对其进行编译可以保护我们的源代码(许多解释语言可以简单地反编译,或者在 PHP 和 Perl 的情况下,根本不会编译)。

于 2008-12-04T13:41:10.377 回答
0

因为业界普遍认为执行速度无关紧要(正如公认的答案所证明的那样)。

我认为真正的原因是,如果您使用现有的框架,解释型语言更容易上手,并且它们使在 Web 应用程序上工作看起来很容易和有趣。

在很多很多情况下,您确实需要在 Web 应用程序中进行数字运算,但开发人员最终要么不这样做(因为它们很昂贵)和/或将任务委托给外部服务器:要么是数据库服务器,要么是一些其他服务器。

这可以从最近所谓的“微服务”架构的激增中看出。

于 2017-11-06T00:07:41.497 回答
-9

很久以前,脚本语言是 Web 开发的唯一选择。现在我们有了其他选择(Java、.NET ..),所以情况还不错。

C 作为一个平台对于 Web 开发来说并不是很成功,因为很难构建一个可以从 Web/应用程序服务器加载和执行的模块,但是构建动态 Web 应用程序的第一个框架之一是 Microsoft IIS 的 ISAPI 模块,主要是用 C++ 开发并编译。

于 2008-12-04T11:54:50.453 回答