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

Question

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

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).

Answer 1

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.

C++ would be significantly better, mainly because std::string is much nicer than 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.

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.

Answer 2

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.

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).

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

Answer 3

You can use FastCGI with PHP/Python/Ruby/Perl to get runtime performance that should be enough until your site grows really big. 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.

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.

Answer 4

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

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:

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.

Answer 5

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 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. 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.

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.

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.

Answer 6

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.

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).

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.

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

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

• 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!)

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

Answer 7

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.

Answer 8

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.

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:

• 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.

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.

Answer 9

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

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

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.

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

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.

Answer 10

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.

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.

Answer 11

Too bad there are no benchmarks of C/C++ vs 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).
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.
Naturally if you want to deploy fast applications you should use C/C++.

At the end of the day the compiled language is faster. But probably finding good C/C++ devs is hard nowdays?

Cheers,

Answer 12

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 ?

Answer 13

Probably someone of you could be interesting in Wt [1], a web toolkit entirely written in C++. It could be an alternative to cppCMS. I'm trying both in these christmas holidays..

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