2

Today I found web-framework written in ANSI C - G-WAN.

I like it, but it is not open source and maintained only by one developer. I am afraid of using it in production.

Do you know any more serious frameworks, that allow to write web services in ANSI C?

I am interested only in ANSI C, not C++.

UPD: I googled Raphters framework. Now I am cheking it out.

Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105
Nikolay Fominyh
  • 8,946
  • 8
  • 66
  • 102
  • Looks like you've been very superficial in your scrutiny of the [G-WAN web and application server](http://gwan.ch). Hard to see how anyone could be more serious about his software than the G-WAN developer. The current release might not be fit for production (depends on what you want to do), but it already outperforms everything else, including nginx. – Lumi Jul 17 '11 at 14:37
  • G-WAN is backed by a 15-year old company, not by a single developer. – Gil Sep 01 '12 at 04:28
  • @Gil, it was not about team size. It was about maturity. What will happen to G-WAN, if lead developer will leave it? Nginx backed by open source community, and 15 years old company can't substitute it. Sorry, if I injured you. – Nikolay Fominyh Sep 03 '12 at 07:35

4 Answers4

3

If you don't want to go with G-WAN, try out NGINX, which is widely deployed and one of the fastest web servers out there, and a more than decent piece of work even according to the judgment of G-WAN's author. There's also a good howto page.

Lumi
  • 14,775
  • 8
  • 59
  • 92
  • I know about nginx, but it's hard to write ANSI C scripts for it to generate dynamic content. Or I missunderstand something? :) – Nikolay Fominyh Jul 17 '11 at 14:56
  • 2
    No, you're not missing anything. For C *scripts*, you'd use G-WAN; but you were asking for "frameworks, that allow to write web services in ANSI C". I do think that can be done using nginx, albeit not as easily as with G-WAN. – Lumi Jul 17 '11 at 15:08
  • I have started look for ANSI C framework, because it's hard for me to write extensions for NGINX. And also Igor doesn't recomend to write extensions that use DB connection for it. – Nikolay Fominyh Jul 17 '11 at 17:03
  • http://www.wikivs.com/wiki/G-WAN_vs_Nginx The Discussion is what you should read not the article. The vast majority of Pro G-WAN information is written by its developers. The benchmarking are not done fairly and they contain fair to many variables to make them reliable. – Case Jun 30 '12 at 01:22
  • 2
    @Iscariot - I'm quite sure the wiki page you're referring to was written by Pierre, GWAN's author; I recognize his style of writing. If so, that in itself doesn't make the information wrong. (Some of it, however, may well be.) I realize there's a polemic and militant aspect to this discussion, which, however, I'm not interested in. I think both GWAN and NGINX are excellent. I believe their authors are genius developers, far better than I'll ever be. As to which one's better at a given moment, that's a moot point to me. Were I to focus on C server development, I'd give both a try. – Lumi Jul 01 '12 at 16:08
  • 2
    Nginx modules are considerably more complex to write (and therefore slower) than G-WAN servlets. That's a fact. – Gil Sep 01 '12 at 04:31
1

Working on G-WAN, I also value the ability to use C for a server.

Your pick, Raphters (like Nginx by the way), was also started "by one developer only".

But Raphters started in 2011 (is it more mature than G-WAN starting in 2009?) and the last update is almost one year old (is it better maintained than G-WAN?).

The author of Raphters says "G-WAN comes with more though". He might know better than us.

If you are looking for "any more serious frameworks, that allow to write web services in ANSI C" then look at Tuxedo, developed by AT&T in the 1980s.

After 30 years, Tuxedo is 'mature', 'well-maintained', and ORACLE (the new owner) is most probably here to stay.

But Tuxedo does not provide the performance of G-WAN (850,000 TPS). Below is the same weightp test on the same machine for Tuxedo (15,000 TPS and quickly dying despite the powerful hardware):

 Concurrency / min / average / max
 ---------------------------------
 1,    5477,    6151,     8161
 10,   7894,   11416,    15451
 20,   8177,   11894,    15578
 30,   10064,  13246,    15499
 40,   1,        909,     8885
 50,   1,         18,      130
 60,   1,          1,        1
 70,   1,          1,        1
 80,   1,          1,        1
 90,   1,          1,        1
 100,  1,          1,        1

An ApacheBench (AB) test of Tuxedo confirms the test above (AB is slower than weighttp used above):

ab -n 100000 -c 10 -k "http://127.0.0.1:8080/"

Server Software:        Oracle
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /
Document Length:        266 bytes

Concurrency Level:      10
Time taken for tests:   12.462 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      48400000 bytes
HTML transferred:       26600000 bytes
Requests per second:    8024.45 [#/sec] (mean)
Time per request:       1.246 [ms] (mean)
Time per request:       0.125 [ms] (mean, across all concurrent requests)
Transfer rate:          3792.80 [Kbytes/sec] received

Looking at this, maybe you understand why G-WAN was created by its author: he could not find any Web framework able to port the Windows Desktop applications of his company to Web applications marketed as SaaS.

Gil
  • 3,279
  • 1
  • 15
  • 25
  • 1
    Problem here is that at the time of asking question I was looking for open-source mature C **framework**. `Tuxedo` has closed source also. However, now I believe that G-Wan is serious and has A-grade at performance. – Nikolay Fominyh Nov 10 '12 at 08:00
0

I'm working on different stuff using GWAN myself right now, but looking around I've also found monkey (http://monkey-project.com/). The real downside of it seems a lack in documentation and features, but other than that, it should also be able to do what you want.

Unfortunately I don't know any current benchmarks of GWAN vs Monkey, and have no reason to do one myself as long as I'll keep using GWAN, but the author of Monkey seems to think it's even faster than GWAN.

In regards to scripts, it should be possible to implement your own pipeline if needed, as I couldn't find any information regarding that for monkey (see: lack of documentation).

As this has already been answered, I'm just posting for completeness.

P.S.: If it looks interesting to you, you might also wanna have a look at http://duda.io/ which is a framework to implement webservices like websockets for monkey.

griffin
  • 1,261
  • 8
  • 24
  • **Monkey**: http://gwan.ch/imgs/core2_monkey_100k.png and **G-WAN**: http://gwan.ch/imgs/core2_gwan_100k.png (both tests done on unoptimized TCP/IP stack on a paltry Core2 Duo CPU). Note how Monkey is slower, less scalable and using more CPU and RAM than G-WAN. Tests done on more CPU Cores will turn even more to G-WAN's advantage. – Gil Jun 04 '13 at 12:21
  • Those graphics don't even list the used versions or what code was used on the individual servers so they really should not be trusted easily (I'm not saying that they are wrong, but there is just no real worth in them other than advertisement) Edit: The http last modified headers tell me that the graphics are probably at least from july 2012 (the files themselves, and thus the tests, may even be older). http://edsiper.linuxchile.cl/blog/2012/08/02/monkey_gwan_reputation/ has a newer one which shows the opposite. So if you want numbers, do benchmarks yourself and dont trust posted stuff ;) – griffin Jun 05 '13 at 08:48
  • griffin: actually, those tests were made and sent to us in June 2012 by **AMD**, a prominent hardware manufacturer (hence the lack of OS tuning) on a computer cluster using many of those Core2 CPUs. Unlike the author of Monkey you are quoting, AMD had no interest at cooking the numbers. The blog post you are referring to carefully avoided to compare servers by using a test that was exlusively relying on the *sendfile()* OS kernel call. Type 'man sendfile' to understand why this was technically irrelevant. – Gil Jun 05 '13 at 10:29
  • I know most of that talk already (except for the "being sent by AMD" - thanks for the helpful info on that!), and you probably meant to say that monkey was using sendfile in the test and GWAN was not (not using sendfile would be the wrong thing imho as those tests should be about total performance). On the other hand I could say that GWAN was caching the file, so really, to endusers it's the outcome that matters, not so much how it's achieved. Nevertheless I only wanted to point out to do your own benchmarks instead of trusting others blindly, which I still think is generally preferable. – griffin Jun 05 '13 at 10:43
  • P.S: I AM pretty happily using GWAN for some time now, but to get more people on the boat (-> more support subscribers) you might think about releasing new comparison benchmarks with current version of GWAN, Monkey, Apache, nginx, lighttpd, ... - probably a day of work or so, but I think it would really pay off in the long run (as most people would at least take those benchmarks as a general guideline of which server to take even if they'd do their own benchmarks) – griffin Jun 05 '13 at 10:48
  • 1
    (a) Paying customers were more interested in low latency of the scripted capabilities, security than in raw benchmarks, (b) it also means more FUD from unhappy competitors, and (c) it takes days, even for "fast" servers, see: http://www.rootusers.com/wp-content/uploads/2012/09/webserver_benchmark_elapsed_time.png for the times (measured by a really independent G-WAN user). – Gil Jun 06 '13 at 16:04
0

Maybe, after 3 years serving its own Web site and many others, you can stop "beeing afraid" about G-WAN.

And, for "any more serious frameworks" the choice is restricted:

  • G-WAN is faster and more scalable than all what I have seen so far (dozens)

  • G-WAN offers (edit & play) scripts in ANSI C, C++, Objective-C, Java.

  • G-WAN consists in a single executable of 150 KB and works without configuration.

To address one of the comments, Lua, Go, Python, Javascript are already supported by G-WAN and PHP will come soon.

Milan
  • 273
  • 3
  • 6
  • I realize this is somewhat of an older question/answer, but as it stands right now I believe support for php is not planning on being added until a thread safe library can be created/found which doesn't appear to be happening anytime soon. – sbditto85 Jul 11 '12 at 15:52
  • 1
    PHP is now supported by G-WAN (along 15 other programming languages: http://gwan.com/benchmark/babel.html). So Milan and his "will come soon" was right. – Gil Nov 10 '12 at 08:14