FastCGI C++ 与脚本语言（PHP/Python/Perl）

FastCGI C++ vs. A Script Language (PHP/Python/Perl)

提问by The Unknown

What are the ups and downs of using FastCGI C++ vs. PHP/Python/Perl to do the same job.

使用 FastCGI C++ 与 PHP/Python/Perl 来做同样的工作有什么优缺点。

Any performance or design pitfalls or using one over the other? Even your opinions are welcome. (Tell me why one or the other rocks, or one or the other sucks).

任何性能或设计缺陷或使用其中一个？甚至你的意见也是受欢迎的。（告诉我为什么一个或另一个岩石，或者一个或另一个很烂）。

采纳答案by Ben Hoyt

Several years ago, I more or less learned web app programming on the job. C was the main language I knew, so I wrote the (fairly large-scale) web app in C. Bad mistake. C's string handling and memory management is tedious, and together with my lack of experience in web apps, it quickly became a hard-to-maintain project.

几年前，我或多或少地在工作中学习了 Web 应用程序编程。C 是我所知道的主要语言，所以我用 C 编写了（相当大规模的）Web 应用程序。错误的错误。C 的字符串处理和内存管理很乏味，再加上我缺乏 Web 应用程序的经验，它很快成为一个难以维护的项目。

C++ would be significantly better, mainly because std::stringis much nicer than char*.

C++ 会明显更好，主要是因为std::string它比char*.

However, now I'd use Python every time (though PHP is not a terrible choice, and perhaps easier to get started with). Python's string handling is awesome, and it handles Unicode seamlessly. Python has much better web tools and frameworks than C++, and its regex handling and standard libraries (urllib, email, etc) work very well. And you don't have to worry about memory management.

但是，现在我每次都会使用 Python（尽管 PHP 不是一个糟糕的选择，而且可能更容易上手）。Python 的字符串处理非常棒，它可以无缝地处理 Unicode。Python 拥有比 C++ 更好的 Web 工具和框架，并且它的正则表达式处理和标准库（urllib、电子邮件等）运行良好。而且您不必担心内存管理。

I'd probably only use C or C++ for a web app if I was severely RAM-constrained (like on an embedded micro) or if I worked at Google and was coding a search engine that was going to have to respond to thousands of queries per second.

如果我的 RAM 受到严重限制（例如在嵌入式微型上），或者如果我在 Google 工作并且正在编写一个必须响应数千个查询的搜索引擎，我可能只会将 C 或 C++ 用于网络应用程序每秒。

回答by stefs

scripting languages may be slower than C, but is this a problem? almost never. and if the performance becomes a problem, you start to translate only the critical parts.

脚本语言可能比 C 慢，但这是一个问题吗？几乎从不。如果性能成为问题，您就开始只翻译关键部分。

twitter/ruby is a good example; ruby is slow. some of the language features (that make ruby nice in the first place) just prevent different kinds of optimization (there is a great article by the jruby guy about this ... was it ola bini? can't remember).

twitter/ruby 就是一个很好的例子；红宝石很慢。一些语言特性（首先使 ruby​​ 变得很好）只是阻止了不同类型的优化（jruby 家伙有一篇关于这个的很棒的文章......是 ola bini 吗？不记得了）。

still, twitter is powered by ruby, because ruby is fast enough. not long ago, "the blogs" reported twitter migrating to scala for performance reasons ... the truth was, only the messaging queue (and other parts of the backend) moved to scala. yahoo runs on a mixture of languages; php for the frontend, other, faster languages are used where performance is critical.

尽管如此，twitter 还是由 ruby​​ 提供支持，因为 ruby足够快。不久前，“博客”报道了 Twitter 出于性能原因迁移到 Scala 的情况……事实是，只有消息队列（和后端的其他部分）迁移到了 Scala。雅虎使用多种语言；php 作为前端，其他更快的语言用于性能至关重要的地方。

so, why is performance not that important? there are several reasons:

那么，为什么性能不那么重要？有几个原因：

• database bottleneck: not the scripting is slow, the database is
• clientside bottleneck: rendering in the browser takes longer than the request. optimize the server side, and nobody will notice
• horizontal scaling: often it's cheaper to add another server and thus triple the requests/sec than to optimize the app
• developer time and maintenance are the most expensive parts of your project. you'll get more cheap python devs that maintain your app than web-enabled c-coders in less time
• no compiling, short dev cycles

• 数据库瓶颈：不是脚本很慢，而是数据库很慢
• 客户端瓶颈：在浏览器中呈现的时间比请求的时间长。优化服务器端，没人会注意到
• 水平扩展：与优化应用程序相比，添加另一台服务器从而使请求数/秒增加三倍通常更便宜
• 开发人员的时间和维护是项目中最昂贵的部分。您将在更短的时间内获得比支持 Web 的 c 编码器更便宜的 Python 开发人员来维护您的应用程序
• 无需编译，开发周期短

another pro-scripting point: many of the scripting languages support inlining or inclusion of fast (C) code:

另一个支持脚本编写的点：许多脚本语言支持内联或包含快速 (C) 代码：

• python, inline c
• php: extensions in c
• server-side javascript via rhino: direct access to java/jvm (a good example for this is orf.at, one of the biggest websites in austria, powered by helma- serverside jvm-interpreted javascript!)

• python，内联c
• php：c 中的扩展
• 通过 rhino 的服务器端 javascript：直接访问 java/jvm （一个很好的例子是 orf.at，奥地利最大的网站之一，由helma提供支持- 服务器端 jvm 解释的 javascript！）

i think, especially in web developement the pros of high-level scripting far outweight the cons.

我认为，尤其是在 Web 开发中，高级脚本的优点远远超过缺点。

回答by Michael Borgwardt

Using C++ is likely to result in a radically faster application than PHP, Perl or Python and somewhat faster than C# or Java - unless it spends most of its time waiting for the DB, in which case there won't be a difference. This is actually the most common case.

使用 C++ 可能会产生比 PHP、Perl 或 Python 快得多的应用程序，并且比 C# 或 Java 快一些——除非它花费大部分时间等待 DB，在这种情况下不会有区别。这实际上是最常见的情况。

On the other hand, due to the reasons benhoyt mentioned, developing a web app in C++ will take longer and will be harder to maintain. Furthermore, it's far more likely to contain serious security holes (nowadys everyone worries most about SQL injection and XSS - but if they were writing their webapps in C++ it would be buffer overflows and it would be their entire networks getting p0wned rather than just the data).

另一方面，由于 benhoyt 提到的原因，用 C++ 开发 Web 应用程序将花费更长的时间并且更难维护。此外，它更有可能包含严重的安全漏洞（现在每个人都最担心 SQL 注入和 XSS——但如果他们用 C++ 编写他们的 web 应用程序，那将是缓冲区溢出，并且他们的整个网络都会被 p0wned 而不仅仅是数据）。

And that's why almost nobody writes web apps in C++ these days.

这就是为什么现在几乎没有人用 C++ 编写 Web 应用程序的原因。

回答by Michael Borgwardt

I think that someone should be a pioneer in Webapp/C++ topic, to test the ground and provide proof of concept solutions.

我认为有人应该成为 Webapp/C++ 主题的先驱，以测试地面并提供概念验证解决方案。

With arrival of STL and development of Boost parsing text happened to be extremely easy with C++. Two years ago, if I would have to parse CSV data I would use Python or PHP. Now I use C++ with STL/Boost. Reading CSV file into vectors? No problem, simple getline + boost::split + lexical_cast. Computing sum of data in a vector of pairs? No problem:

随着 STL 的出现和 Boost 的发展，使用 C++ 解析文本变得非常容易。两年前，如果我必须解析 CSV 数据，我会使用 Python 或 PHP。现在我将 C++ 与 STL/Boost 结合使用。将CSV文件读入向量？没问题，简单的 getline + boost::split + lexical_cast。计算成对向量中的数据总和？没问题：

pair<int, double> sum_int_double(pair<int,double> & total, pair<struct in_addr, pair<int,double> > & a) {
    total.first += a.second.first;
    total.second += a.second.second;
    return total;
}
pair<int,double> mixedSum = accumulate(mixedVec.begin(), mixedVec.end(), emptyPair, sum_int_double);

Transferring data from map into vector of pairs? No problem:

将数据从地图传输到成对向量？没问题：

mixedVec.assign(amap.begin(), amap.end());

Everything is well defined and sharp. String operations, regexps, algorithms, OOP, etc. everything is well defined and mature in C++. If your app will be real app-like, and not parsing text-based, then C++ also good choice with its OOP features.

一切都清晰明了。字符串操作、正则表达式、算法、OOP 等。一切都在 C++ 中定义明确且成熟。如果您的应用程序将是真正的应用程序，而不是基于文本的解析，那么 C++ 也是具有 OOP 功能的不错选择。

回答by S.Lott

The question is "where's the value created?"

问题是“创造的价值在哪里？”

If you think the value is created in Memory management, careful class design and getting the nightly build to work, then use C++. You'll get to spend lots of time writing a lot of code to do important things like deleting objects that are no longer referenced.

如果您认为价值是在内存管理、仔细的类设计和每晚构建工作中创造的，那么请使用 C++。您将花费大量时间编写大量代码来执行重要的操作，例如删除不再引用的对象。

If you think the value is in deploying applications that people can use, then use Python with the Django framework. The Django tutorial shows you that within about 20 minutes you can have an application up and running. It's production-ready, and you could focus on important things:

如果您认为价值在于部署人们可以使用的应用程序，那么将 Python 与 Django 框架结合使用。Django 教程向您展示了在大约 20 分钟内您可以启动并运行一个应用程序。它是生产就绪的，您可以专注于重要的事情：

• The model. Just write the model in Python, and the ORM layer handles all of the database interaction for you. No SQL. No manual mapping.

• The presentation. Just design your pages in HTML with a few {{}}"fill in a value here" and a few {% for thing in object_list %}constructs and your pages are ready to go. No string manipulation.

• The view functions. Write simple Python functions to encapsulate the processing part of your site. Not validation (those are in forms), not presentation (that was in the templates), not the underlying model (that was in the model classes), but a little bit of authorization checking, query processing and response formulation. Since Python has a rich set of collection classes, this code winds up being very short and to the point.

• Other stuff. URL mappings are Python regexes. Forms are matched to your model; you can subclass the defaults to add customized input validation and processing.

• Wonderful unit testing framework for low-level model features as well as end-to-end operations.

• 该模型。只需用 Python 编写模型，ORM 层就会为您处理所有数据库交互。没有 SQL。没有手动映射。

• 演示文稿。只需使用一些{{}}“在此处填写一个值”和一些{% for thing in object_list %}结构来设计 HTML 页面，您的页面就可以使用了。没有字符串操作。

• 视图功能。编写简单的 Python 函数来封装站点的处理部分。不是验证（在表单中），不是表示（在模板中），不是底层模型（在模型类中），而是一点点授权检查、查询处理和响应公式。由于 Python 有一组丰富的集合类，因此这段代码非常简短且切中要害。

• 其他的东西。URL 映射是 Python 正则表达式。表格与您的模型相匹配；您可以将默认值子类化以添加自定义输入验证和处理。

• 用于低级模型功能以及端到端操作的精彩单元测试框架。

No memory management, no scrupulous class design with abstracts and interfaces. No worrying about how to optimize string manipulation. No nightly build. Just create the stuff of real value.

没有内存管理，没有带有抽象和接口的严谨的类设计。不用担心如何优化字符串操作。没有夜间构建。只创造真正有价值的东西。

回答by rstaveley

If you want to be able to implement web services in an existing running process (e.g. daemon), which is written in C/C++. It makes sense to make that process implement the FastCGI protocol for that interface. Get Apache to deal with HTTP (2-way SSL etc) to the outside world and field requests through FastCGI through a socket. If you do this in PHP, you have to get PHP to talk to your process, which means maintaining PHP code as well as your process.

如果您希望能够在现有的运行进程（例如守护进程）中实现 Web 服务，该进程是用 C/C++ 编写的。让该进程为该接口实现 FastCGI 协议是有意义的。让Apache通过socket通过FastCGI处理对外的HTTP（2-way SSL等）和字段请求。如果您在 PHP 中执行此操作，则必须让 PHP 与您的进程对话，这意味着维护 PHP 代码以及您的进程。

回答by pts

Having a FastCGI web application (no matter C++, PHP, Perl, Python, Ruby etc.) gives you better initial startup time than a CGI application. By initial startup timeI mean the time elapsed between the time the web server receives the request and the time the the first code line you've written is run, so the initial startup time is the minimum time visitors of your web application have to wait for each request. It is not unusual to have an initial startup time of 1 second, especially if your application is large or you are using a large framework (such as Ruby on Rails). FastCGI keeps your applications running after it has responded to the first request, so FastCGI reduces the initial startup time of all subsequent requests (except for the very first one), usually down to a few milliseconds.

拥有 FastCGI Web 应用程序（无论是 C++、PHP、Perl、Python、Ruby 等）为您提供比 CGI 应用程序更好的初始启动时间。通过初始启动时间我的意思是Web服务器接收请求和你写的第一行代码在运行时的时间之间的时间间隔，因此初始启动时间是最小时间您的Web应用程序的游客不得不等待对于每个请求。初始启动时间为 1 秒并不罕见，尤其是当您的应用程序很大或者您正在使用大型框架（例如 Ruby on Rails）时。FastCGI 使您的应用程序在响应第一个请求后保持运行，因此 FastCGI 将所有后续请求（第一个请求除外）的初始启动时间减少到几毫秒。

If you use PHP, usually its default configuration provides a good enough initial response time (even without FastCGI), but please make sure you use a PHP accelerator on your production server (see http://en.wikipedia.org/wiki/PHP_accelerator) to get better performance.

如果您使用 PHP，通常它的默认配置提供足够好的初始响应时间（即使没有 FastCGI），但请确保您在生产服务器上使用 PHP 加速器（请参阅http://en.wikipedia.org/wiki/PHP_accelerator) 以获得更好的性能。

Most programming languages and frameworks let you run the same application in different server modes (such as CGI, FastCGI, built-in webserver, Apache module), by changing the application's configurations, without changing the code. FastCGI is usually not the best choice while writing the application, because after you change the code, you may have to restart the application so it picks up your changes, but it is usually cumbersome to restart a FastCGI application. Restarting CGI or a built-in webserver is much easier. You should set up FastCGI only in the production configuration.

大多数编程语言和框架允许您通过更改应用程序的配置，而无需更改代码，以不同的服务器模式（例如 CGI、FastCGI、内置 web 服务器、Apache 模块）运行相同的应用程序。在编写应用程序时，FastCGI 通常不是最佳选择，因为在您更改代码后，您可能必须重新启动应用程序以便它接受您的更改，但重新启动 FastCGI 应用程序通常很麻烦。重新启动 CGI 或内置网络服务器要容易得多。您应该只在生产配置中设置 FastCGI。

回答by Artyom

There are people who asked this before: http://cppcms.sourceforge.net/wikipp/en/page/main

之前有人问过这个：http: //cppcms.sourceforge.net/wikipp/en/page/main

CppCMS project provides a framework for web development using C++.

CppCMS 项目提供了一个使用 C++ 进行 Web 开发的框架。

You can take a look on following benchmarks to understand what is the difference: http://cppcms.sourceforge.net/wikipp/en/page/benchmarks-- about two orders of magnitude.

您可以查看以下基准以了解有什么区别：http: //cppcms.sourceforge.net/wikipp/en/page/benchmarks- 大约两个数量级。

The problem of PHP/Python that they are very slow, there are many problems in caching data in FastCGI process of PHP.

PHP/Python很慢的问题，PHP的FastCGI进程缓存数据有很多问题。

The biggest issue of C++ is a low amount of resources of development for Web in C++. However, taking a framework like CppCMS makes the life much simpler.

C++ 的最大问题是在 C++ 中用于 Web 的开发资源量很少。然而，采用像 CppCMS 这样的框架使生活变得更加简单。

回答by Jason Baker

There is a middle ground here. Python (and I believe Perl and Ruby) allow you to call functions from C. 99 times out of 100, you won't need to. But it's nice to know that the option is there if you need it.

这里有一个中间立场。Python（我相信 Perl 和 Ruby）允许您从 C 调用函数。100 次中有 99 次，您不需要。但是很高兴知道如果您需要该选项就在那里。

Usually for webapps, the speed of the programming language simply isn't an issue. In the time it takes to execute a single database query, a processor can execute a few billion instructions. It's about the same for sending and receiving http data.

通常对于 webapps，编程语言的速度根本不是问题。在执行单个数据库查询所需的时间内，处理器可以执行数十亿条指令。发送和接收http数据大致相同。

回答by Monkey

Well... You will save memory and CPU power with C/C++ vs Python/Perl/Ruby/Java/.NET. If the resources saved by using C/C++ represents a large fraction of the total resources available (a FastCGI running on the embedded board of a robot), then yeah, C/C++. Else, why bother ?

嗯...与 Python/Perl/Ruby/Java/.NET 相比，您将使用 C/C++ 节省内存和 CPU 能力。如果使用 C/C++ 节省的资源占可用资源总量的很大一部分（运行在机器人嵌入式板上的 FastCGI），那么是的，C/C++。否则，何必呢？