8

I'm asking the question after reading this article http://stevehanov.ca/blog/index.php?id=95

Also isn't it a penalty to use cgi instead of fastcgi ?

Update: why some people do pretend like in answer "that you get 20-30% performance improvement" ? Is it pure guess or is this number coming from solid benchmark ? I have looked at HipHop performance is more in the scale of 10 times.

user52875
  • 3,020
  • 22
  • 21
user310291
  • 36,946
  • 82
  • 271
  • 487
  • The referenced article ends by suggesting that the web server be built into the C++ application, bypassing CGI altogether. That might be really fast. – Mark Ransom Jul 22 '11 at 17:09
  • 2
    Either way, it propably won't be very fast w.r.t programmer performance as in development speed ;) –  Jul 22 '11 at 17:19
  • @Mark he says "In this model, you write your C++ program as a CGI script directly" so he's not bypassing cgi as far as I can understand – user310291 Jul 23 '11 at 16:53
  • @user310291, a couple of pages after that he adds: "But there is a third strategy: If you write your own webserver, you can cut out the middleman and serve the request directly." – Mark Ransom Jul 23 '11 at 16:57
  • @Mark then my question isn't about third strategy. – user310291 Jul 23 '11 at 17:28

6 Answers6

20

I've done webdev in a few languages and frameworks, including python, php, and perl. I host them myself and my biggest sites get around 20k hits a day.

Any language and framework that has reasonable speed can be scaled up to take 20k hits a day just by throwing resources at it. Some take more resources than others. (Plone, Joomla. I'm looking at you).

My Witty sites (none in production yet) take a lot more (from memory around 5000% more) pounding (using seige) than for example my python sites. Ie. When I hit them as hard as I can with seige, the witty sites serve a lot more pages per second.

I know it's not a true general test though.

Other speed advantages that witty gives you:

Multi threading

If you deploy with the built in websrever (behind ha-proxy for example) and have your app be multi-threaded .. it'll load a lot less memory than say a perl or php app.

Generally with php and perl apps, you'll have Apache fire up a process for each incoming connection, and each process loads the whole php interpreter, all the code and variables and objects and what not. With heavy frameworks like Joomla and Wordpress (depending on the number of plugins), each process can get pretyy humungous on memory consumption.

With the Wt app, each session loads a WApplication instance (a C++ object) and it's whole tree of widgets and stuff. But the memory the code uses stays the same, no matter how many connections.

The inbuilt Web2.0 ness

Generally with traditional apps, they're still built around the old 'http request comes in' .. 'we serve a page' .. 'done' style of things. I know they are adding more and more AJAXy kind of thigns all the time.

With Wt, it defaults to using WebSockets where possible, to only update the part of the page that needs updating. It falls back to standard AJAX, then if that's not supported http requests. With the AJAX and WebSockets enabled clients, the same WApplication C++ object is continually used .. so no speed is lost in setting up a new session and all that.

In response to the 'C++ is too hard for webdev'

C++ does have a bit of a learning curve. In the mid nineties we did websites in Java j2ee. That was considered commercially viable back then, and was a super duper pain to develop in, but it did have a good advantage of encouraging good documentation and coding practices.

With scripting websites, it's easy to take shortcuts and not realize they're there. For example one 8 year old perl site I worked on had some code duplicated and nobody noticed. Each time it showed a list of products, it was running the same SQL query twice.

With a C++ site, I think it'd have less chance because, in the perl site, there wasn't that much programming structure (like functions), it was just perl and embedded html. In C++ you'd likely have methods with names and end up with a name clash.

Types

One time, there was a method that took an int identifier, later on we changed it to a uuid string. The Python code was great, we didn't think we needed to change it; it ran fine. However there was little line buried deep down that had a different effect when you passed it a string. Very hard to track down bug, corrupted the database. (Luckily only on dev and test machines).

C++ would have certainly complained a lot, and forced us to re-write the functions involved and not be lazy buggers.

With C++ and Java, the compiler errors and warns a lot of those sorts of mistakes for you.

I find unit testing is generally not as completely necessary with C++ apps (don't shoot me), compared to scripting language apps. This is due to the language enforcing a lot of stuff that you'd normally put in a unit test for say a python app.

Summary

From my experience so far .. Wt does take longer to develop stuff in than existing frameworks .. mainly because the existing frameworks have a lot more out of the box stuff there. However it is easier to make extremely customized apps in Wt than say Wordpress imho.

matiu
  • 7,469
  • 4
  • 44
  • 48
9

From people I've spoken with who've moved from PHP to Wt (a C++ web framework) reported significant improvements. From the small applications I've created using Wt to learn it, I've seen it run faster than the same PHP type applications I created. Take the information for what you will, but I'm sold.

JadziaMD
  • 2,690
  • 5
  • 31
  • 42
  • what "significant" ? 30% or 1000% that's my implicit question :) HipHop benchmark seems to say 1000%. – user310291 Jul 23 '11 at 16:59
  • @user310291 They've said between 110% to 200%, depending on their application, over their previous code base. – JadziaMD Jul 26 '11 at 17:27
5

This reminds me how 20-30 years ago people were putting Assembly vs C, and then 10-20 years ago C vs C++. Of course C++ will be faster than PHP/Rails but it'll take 5x more effort to build maintainable and scalable application.

The point is that you get 20-30% performance improvement while sacrificing your development resources. Would you rather have you app work 30% faster or have 1/2 of the features implemented?

Zepplock
  • 28,655
  • 4
  • 35
  • 50
  • No arguments from me that for many things proper C++ will take longer to write than your average PHP. Especially when frontend (UI) is involved. But C++ will scale a lot easier, because you can use a pure async design. – Cory Nelson Jul 22 '11 at 18:19
  • Cory, I'm not sure what you mean by "async design". Could you please explain. – Zepplock Jul 23 '11 at 04:16
  • +1: I embedded simple hand-made HTTP servers into couple of my C++ projects. the main reason - I know how to do this in C++ quickly, I'm experienced in C++ much more than in any other language, I don't need to bother with any 3rd-party libs, complicated deployment etc. But I never thought about performance gain, – Andriy Tylychko Jul 23 '11 at 08:06
  • @Zepplock Right now with PHP it's common to launch a dozen or more php-fcgi processes to work around non-scalable functions like `mysql_query`, which completely block the process while waiting for the query to complete. While it's blocked, the process isn't doing anything but waiting. With an async design, the process would be allowed to work on other requests while you wait---you could fold all those processes into a single one per CPU for higher scalability. – Cory Nelson Jul 23 '11 at 14:56
  • Thanks Cory. You have a very valid point. Although it would be more fair to compare with modern MVC frameworks like Ruby On Rails, which overcome all the issues you have described. – Zepplock Jul 23 '11 at 16:04
  • 1
    get 20-30% performance ? It should be more like 10 times better performance if you look at HipHop – user310291 Jul 23 '11 at 16:54
  • If you're going to compare anything to anything, they do need to be the same. Comparing C++ to Ruby On Rails is not apples to apples, comparing C++ to Ruby however is. – JadziaMD Aug 03 '11 at 17:31
  • 2
    Wt is such a library that make writing web applications in C++ easier than in Ruby or PHP, and makes your application run factors faster (for various reasons). A round-trip time of a few ms makes users happy. – user52875 Aug 15 '11 at 10:21
  • @user52875: I looked through the examples of pages generated by Wt and I didn't find MVC in there at all. The other shortcoming is no template support (haml, erb), etc. I also see html generated by concatenating strings, etc. This can be due to bad examples but overall it does not seem even close to modern web development frameworks (django, rails, symphony, etc) – Zepplock Aug 15 '11 at 20:08
  • @zepplock: Wt's MVC does not show in the generated pages, you have to look at the source code of the examples to see how it works (look at the widget gallery, topic MVC widgets). Wrt string concatenation: you seem to imply that a user has to compose a page by concatenating strings, which certainly is not the case. The concatenation of visible user strings is safe in Wt, since the render engine will filter out all unsafe constructs and therefore automatically protects against XSS attacks. Wt's template support resides in the WTemplate class. – user52875 Nov 11 '11 at 14:47
3

Most web applications are network-bound instead of processor-bound. Writing your application in C++ instead of a higher-level language doesn't make much sense unless you're doing really heavy computation. Also, writing correct C++ programs is difficult. It will take longer to write the application and it is more likely that the program will fail in spectacular ways due to misused pointers, memory errors, undefined behavior, etc. In general, I would say it is not worth it.

Zhehao Mao
  • 1,789
  • 13
  • 13
3

Whenever you eliminate a layer of interpretive or OS abstraction, you are bound to get some performance gain. That being said, the language or technology itself does not automatically mean all your problems are solved. I've fixed C++ code that took many hours to process a relatively simple set of records. The problem was in the implementation, and the fix was not related to the language's features or limitations.

Assuming things are all implemented correctly, you're sure to get better performance. The problem will be in finding the bugs. One of the problems with C++ is that many developers are currently "trained" or accustomed to having a lot of details related to memory management behind objects. This eliminates the need to consider things like, "What can happen if I pass this pointer around to several threads?" Sometimes it works well, but not always. You still have some subtleties of the language that you need to consider regardless of how the objects hide the nasty details.

In my experience, you'll need several seasoned C++ developers watching over the code to be able to keep the bugs and memory leaks from getting out of hand.

  • My question implicitely implies that I would have of course a C++ team. – user310291 Jul 23 '11 at 16:58
  • 2
    There are C++ developers, then there are C++ developers that know what they're doing. Longevity in using C++ does not necessarily imply the latter. You have to watch for the ones that don't know what they're doing and correct it quickly. This is an unfortunate reality of C++ development. –  Jul 24 '11 at 04:55
3

I'm certainly not sold on this. If you want a performance gain over PHP why not use a Java (or better yet Scala) framework? These are much better for web development, have nice, relatively easy to use frameworks and avoid a lot of the headaches of C++. I've always seen one of the main pluses of web-development (and most modern non-scientific/high performance applications) as being able to avoid the headaches that come along with C/C++ development.

dave
  • 12,406
  • 10
  • 42
  • 59
  • 1
    Java is still slower than C++ since it uses an abstraction layer which is the VM and garbage collection which automates memory management at the expense of performance. – user310291 Jul 23 '11 at 17:01
  • @user310291, that's true, but jumping to using C++ because PHP is too slow is quite a leap, and I question whether it's worth it to deal with all of the additional headaches. – dave Jul 23 '11 at 17:18