简体   繁体   English

FastCGI C ++与脚本语言(PHP / Python / Perl)

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

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). (告诉我为什么一个或另一个岩石,或一个或另一个糟透了)。

scripting languages may be slower than C, but is this a problem? 脚本语言可能比C慢,但这是一个问题吗? almost never. 几乎从不。 and if the performance becomes a problem, you start to translate only the critical parts. 如果性能成为问题,您开始只翻译关键部分。

twitter/ruby is a good example; twitter / ruby​​就是一个很好的例子; 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). 一些语言功能(首先让ruby很好)只是防止不同类型的优化(jruby家伙有一篇很棒的文章关于这个...是ola bini?不记得了)。

still, twitter is powered by ruby, because ruby is fast enough . 仍然,Twitter由红宝石提供动力,因为红宝石足够快 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. 不久前,“博客”报道Twitter出于性能原因迁移到scala ......事实是,只有消息队列(以及后端的其他部分)转移到scala。 yahoo runs on a mixture of languages; 雅虎运行各种语言; php for the frontend, other, faster languages are used where performance is critical. 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 你可以在更短的时间内获得比支持网络的c-coders更便宜的python开发人员维护你的应用程序
  • no compiling, short dev cycles 没有编译,短的开发周期

another pro-scripting point: many of the scripting languages support inlining or inclusion of fast (C) code: 另一个支持脚本的点:许多脚本语言支持内联或包含快速(C)代码:

  • python, inline c python,内联c
  • php: extensions in c php: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!) 通过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. 我认为,特别是在网络开发中,高级脚本的优点远远超过了缺点。

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是我所熟悉的主要语言,所以我用C.写错了(相当大规模的)Web应用程序。 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. C的字符串处理和内存管理很繁琐,而且由于我缺乏Web应用程序的经验,它很快就变成了一个难以维护的项目。

C++ would be significantly better, mainly because std::string is much nicer than char* . C ++会明显更好,主要是因为std::stringchar*好得多。

However, now I'd use Python every time (though PHP is not a terrible choice, and perhaps easier to get started with). 但是,现在我每次都使用Python(虽然PHP不是一个糟糕的选择,也许更容易上手)。 Python's string handling is awesome, and it handles Unicode seamlessly. Python的字符串处理非常棒,它可以无缝地处理Unicode。 Python has much better web tools and frameworks than C++, and its regex handling and standard libraries (urllib, email, etc) work very well. Python比C ++有更好的Web工具和框架,它的正则表达式处理和标准库(urllib,电子邮件等)工作得很好。 And you don't have to worry about memory management. 而且您不必担心内存管理。

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. 我可能只在网络应用程序中使用C或C ++,如果我受到严格的RAM限制(比如在嵌入式微型计算机上),或者我在Google工作并编写了一个必须响应数千个查询的搜索引擎每秒。

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. 使用C ++可能会导致应用程序比PHP,Perl或Python快得多,并且比C#或Java快一些 - 除非它花费大部分时间等待数据库,在这种情况下不会有差别。 This is actually the most common case. 这实际上是最常见的情况。

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. 另一方面,由于benhoyt提到的原因,用C ++开发Web应用程序需要更长的时间并且难以维护。 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). 此外,它更有可能包含严重的安全漏洞(现在每个人都最担心SQL注入和XSS - 但如果他们用C ++编写他们的webapps,那将是缓冲区溢出,并且它们将被整个网络变为pnwned而不仅仅是数据)。

And that's why almost nobody writes web apps in C++ these days. 这就是为什么现在几乎没有人用C ++编写Web应用程序。

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++. 随着STL的到来和Boost解析文本的开发在C ++中变得非常容易。 Two years ago, if I would have to parse CSV data I would use Python or PHP. 两年前,如果我必须解析CSV数据,我会使用Python或PHP。 Now I use C++ with STL/Boost. 现在我使用C ++和STL / Boost。 Reading CSV file into vectors? 将CSV文件读入矢量? No problem, simple getline + boost::split + lexical_cast. 没问题,简单的getline + boost :: split + lexical_cast。 Computing sum of data in a vector of pairs? 计算对矢量中的数据总和? No problem: 没问题:

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++. 字符串操作,正则表达式,算法,OOP等等。在C ++中,一切都已经很好地定义和成熟。 If your app will be real app-like, and not parsing text-based, then C++ also good choice with its OOP features. 如果您的应用程序将是真正的应用程序,而不是解析基于文本,那么C ++也是其OOP功能的不错选择。

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++. 如果您认为该值是在内存管理中创建的,请仔细进行类设计并使每晚构建工作,然后使用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. 您将花费大量时间编写大量代码来执行重要操作,例如删除不再引用的对象。

If you think the value is in deploying applications that people can use, then use Python with the Django framework. 如果您认为该值是在部署人们可以使用的应用程序,那么将Python与Django框架一起使用。 The Django tutorial shows you that within about 20 minutes you can have an application up and running. Django教程告诉您,在大约20分钟内,您可以启动并运行应用程序。 It's production-ready, and you could focus on important things: 它是生产就绪的,你可以专注于重要的事情:

  • The model. 该模型。 Just write the model in Python, and the ORM layer handles all of the database interaction for you. 只需在Python中编写模型,ORM层就可以为您处理所有数据库交互。 No SQL. 没有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. 只需使用一些{{}} “在这里填写一个值”和一些{% for thing in object_list %}构造中的页面来设计HTML页面,您的页面就可以开始了。 No string manipulation. 没有字符串操作。

  • The view functions. 视图功能。 Write simple Python functions to encapsulate the processing part of your site. 编写简单的Python函数来封装站点的处理部分。 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. 由于Python有一组丰富的集合类,因此这段代码非常简短。

  • Other stuff. 其他的东西。 URL mappings are Python regexes. URL映射是Python正则表达式。 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. 用于低级模型功能以及端到端操作的精彩单元测试框架。

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. 只需创造真正有价值的东西。

If you want to be able to implement web services in an existing running process (eg daemon), which is written in C/C++. 如果您希望能够在现有的运行进程(例如守护程序)中实现Web服务,该进程是用C / C ++编写的。 It makes sense to make that process implement the FastCGI protocol for that interface. 使该进程实现该接口的FastCGI协议是有意义的。 Get Apache to deal with HTTP (2-way SSL etc) to the outside world and field requests through FastCGI through a socket. 让Apache处理HTTP(双向SSL等)到外部世界,并通过套接字通过FastCGI进行现场请求。 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. 如果您在PHP中执行此操作,则必须让PHP与您的流程进行通信,这意味着维护PHP代码以及您的流程。

Having a FastCGI web application (no matter C++, PHP, Perl, Python, Ruby etc.) gives you better initial startup time than a CGI application. 拥有一个FastCGI Web应用程序(无论是C ++,PHP,Perl,Python,Ruby等)可以为您提供比CGI应用程序更好的初始启动时间。 By initial startup time I 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. 初始启动时间是指Web服务器收到请求的时间与您编写的第一个代码行运行之间经过的时间,因此初始启动时间是Web应用程序的访问者必须等待的最短时间对于每个请求。 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). 初始启动时间为1秒并不罕见,特别是如果您的应用程序很大或者您使用的是大型框架(例如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在响应第一个请求后使应用程序保持运行,因此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. 大多数编程语言和框架允许您通过更改应用程序的配置而不更改代码,以不同的服务器模式(例如CGI,FastCGI,内置Web服务器,Apache模块)运行相同的应用程序。 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. 在编写应用程序时,FastCGI通常不是最佳选择,因为在更改代码之后,您可能必须重新启动应用程序才能获取更改,但重新启动FastCGI应用程序通常很麻烦。 Restarting CGI or a built-in webserver is much easier. 重新启动CGI或内置Web服务器要容易得多。 You should set up FastCGI only in the production configuration. 您应该仅在生产配置中设置FastCGI。

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++. C ++最大的问题是C ++中Web的开发资源很少。 However, taking a framework like CppCMS makes the life much simpler. 但是,采用像CppCMS这样的框架可以简化生活。

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. Python(我相信Perl和Ruby)允许你从100中调用99次函数,你不需要。 But it's nice to know that the option is there if you need it. 但是很高兴知道如果你需要的话可以选择。

Usually for webapps, the speed of the programming language simply isn't an issue. 通常对于webapps,编程语言的速度根本不是问题。 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. 发送和接收http数据大致相同。

Well... You will save memory and CPU power with C/C++ vs Python/Perl/Ruby/Java/.NET. 那么......你将使用C / C ++和Python / Perl / Ruby / Java / .NET来节省内存和CPU的能力。 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++. 如果使用C / C ++节省的资源占可用总资源的很大一部分(在机器人的嵌入式板上运行的FastCGI),那么,是的,C / C ++。 Else, why bother ? 否则,为什么要这么麻烦?

Probably someone of you could be interesting in Wt [1], a web toolkit entirely written in C++. 可能有人会对Wt [1]感兴趣,这是一个完全用C ++编写的Web工具包。 It could be an alternative to cppCMS. 它可能是cppCMS的替代品。 I'm trying both in these christmas holidays.. 我在这些圣诞节假期都在尝试..

[1] http://www.webtoolkit.eu/wt [1] http://www.webtoolkit.eu/wt

You can use FastCGI with PHP/Python/Ruby/Perl to get runtime performance that should be enough until your site grows really big. 您可以将FastCGI与PHP / Python / Ruby / Perl一起使用,以获得足够的运行时性能,直到您的站点变得非常大。 And even then, you can make architectural improvements (database tuning, caching etc) to scale even more without abandoning scripting languages. 即使这样,您也可以在不放弃脚本语言的情况下进行体系结构改进(数据库调优,缓存等)以进行更多扩展。 Some pretty large sites are done in PHP/Python/Ruby/Perl. 一些非常大的站点是用PHP / Python / Ruby / Perl完成的。

The big gain you get by using high-level languages is programmer performance. 使用高级语言获得的巨大收益是程序员性能。 And that is what you should worry about first. 这就是你应该首先担心的事情。 It will be more important to respond quickly to feature demands from users, than to trim some milliseconds off the page response time. 对用户的功能需求做出快速响应比对页面响应时间缩短几毫秒更为重要。

Too bad there are no benchmarks of C/C++ vs Perl CGI. 太糟糕了,没有C / C ++与Perl CGI的基准。
Without FastCGI I think C/C++ would be a lot faster, with FastCGI possibly it'll be faster (but maybe a little less - all the initialization part is executed once). 如果没有FastCGI,我认为C / C ++会快得多,FastCGI可能会更快(但可能会更少 - 所有初始化部分都执行一次)。
Again this is very application dependent, so some sort of benchmarks for different dynamic web pages should be provided. 这又是非常依赖于应用程序的 ,因此应该为不同的动态网页提供某种基准。

Personally I think that if your company has resources it should/could invest in C/C++ (given that they have to find proper ones...), otherwise is better to stick to a scripting language. 我个人认为,如果你的公司有资源,它应该/可以投资C / C ++(考虑到他们必须找到合适的......),否则最好坚持使用脚本语言。
Naturally if you want to deploy fast applications you should use C/C++. 当然,如果要部署快速应用程序,则应使用C / C ++。

At the end of the day the compiled language is faster. 在一天结束时,编译语言更快。 But probably finding good C/C++ devs is hard nowdays? 但是现在很难找到好的C / C ++开发人员吗?

Cheers, 干杯,

C++ is a strongly typed language...ie you can declare ints, floats, etc....generally you can program more efficiently than you can with weakly typed languages. C ++是一种强类型语言...即你可以声明整数,浮点数等....通常你可以比使用弱类型语言更有效地编程。 Facebook reported a 50% improvement when switching from PHP to C++. Facebook报告称,从PHP切换到C ++时,性能提高了50%。 I would consider scripting languages to be prototyping languages...when you want production level efficiency use a compiled language. 我认为脚本语言是原型语言......当你想要生产水平效率使用编译语言时。

我通过Google进行的每次搜索都表明,C / C ++为需要诸如在网页中搜索信息或从数据库获取信息等功能的Web应用程序提供了最佳性能。

There are some new answers for this. 对此有一些新的答案。

  1. If you need a compiled application, you might find that Google's Go language is a nice compiled language with modern features. 如果您需要一个已编译的应用程序,您可能会发现Google的Go语言是一种具有现代功能的优秀编译语言。
  2. Writing an application in a scripting language (I use Perl) can be done through frameworks like Mojolicious or Dancer , and then by employing a PSGI/Plack controller it can run on CGI, FastCGI, mod_perl, native servers (like Hypnotoad from Mojolicious) or cloud deployment, all without modification. 用脚本语言编写应用程序(我使用Perl)可以通过MojoliciousDancer等框架完成,然后使用PSGI / Plack控制器,它可以运行在CGI,FastCGI,mod_perl,本机服务器(如Mojolicious的Hypnotoad)或云部署,都没有修改。 Similar concepts exist for other scripting languages. 其他脚本语言也存在类似的概念。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM