Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 60

Thread: G-WAN Web Server Claims Speed Records, Features

  1. #41
    Join Date
    Mar 2010
    Location
    Slovenia
    Posts
    391

    Default

    Quote Originally Posted by droidhacker View Post
    Can you think of anything better to run as a webserver?
    It doesn't matter if it's better or not.
    I don't want to be bound to some OS.

  2. #42

    Default

    Quote Originally Posted by curaga View Post
    Monkey is 60kb, faster than gwan, and open source (gplv2). gwan beating apache and lighty is believable, for nginx it depends (nginx default config is absolute crap and doesn't scale).

    See
    http://monkey.io/benchmarks/x86_64_monkey_gwan


    Disclaimer: I'm working on monkey this gsoc.
    http://gwan.ch/blog and more specifically http://gwan.ch/blog/20120728.html


    Quote Originally Posted by DoDoENT View Post
    +1 for benchmark

    Being faster than nginx or lighttpd is really something difficult to achieve. I would really like to see G-WAN outperforming those servers.
    +1 another one

  3. #43
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,338

    Default

    Quote Originally Posted by AnotherHumanBeing View Post
    Ugh, I can begin to see why the gwan dude is considered a douche. Personal attacks, really? Bringing the guy's employer in over a hobby project, completely unrelated to the employer?


    Skipping all that vitriol, of his five points only two are valid.

    use the ridiculously slow siege client test tool (instead of the fast SMP weighttp program)
    This is a mere preference. Both siege and weighttp are multithreaded with async sockets. It's also invalid due to the fact that the same program was used for both servers, ie consistent environment.

    disable HTTP Keep-Alives (so you will test the TCP/IP stack rather than the server application)
    Again, same for both. Consistent environment.

    use one single unconstant test shot (instead many rounds to have a relevant min/average/max range)
    use one single concurrency (instead of the whole [1-1,000] concurrency range to see how servers behave)
    These are the valid points. But one should also vary the file size in addition.

    use a 200 KB binary file to test the Linux kernel (instead of a 100-byte HTML file to test the HTTP server)
    Again, same for both servers. Consistent environment, so this point is invalid.


    Testing a big-ish file instead of a tiny file does not invalidate a bench, it means that the results are these for *this-sized files*. Obviously if you were deploying a server, you'd test with the file sizes you're going to serve, and those can be radically different, from small html to big data.

    My conclusion? The guy was disappointed that gwan could lose at all, went ad-hominem, and did present valid data that gwan is better using tiny files. He neglected to mention the versions of both servers tested, but any bench has minor nitpicks.

    This is just more grounds for having a big third party test, right Michael?

  4. #44
    Join Date
    Jan 2009
    Posts
    466

    Default

    Quote Originally Posted by curaga View Post
    This is just more grounds for having a big third party test, right Michael?
    Possibly. I have not yet encountered a situation or problem that one of these lightweight http daemons fixes when compared to Apache httpd. Every time I see a claim that the new "Unicorn-httpd" is so much lighter and faster than Apache, it always turns out that it is only faster at a very particular level of concurrency, or when serving a very narrow range of file sizes.

    Sorry for the bias and skepticism, it's just that I've seen so many of these in the past, and none of them have really lived up to their propaganda.

    On a positive note, this thread has inspired me to write the fastest web server EVER. It is OSS and written in bash. Here's the code:

    Code:
    echo"" >~/TEST_200_RESPONSE ; while true ; do nc -l 80 <~/TEST_200_RESPONSE ; done
    It doesn't have all of the features that Apache HTTPD offers, but it's really fast!

    F

  5. #45
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,052

    Default

    But still, hard to argue against that:

    Code:
    worker_processes  5;
    events {
        worker_connections  320000;
        multi_accept on;
    }
    weighttp -t 2 -k -n 300000 -c1000 http://localhost/helloworld.txt
    nginx: finished in 8 sec, 217 millisec and 447 microsec, 36507 req/s, 8804 kbyte/s
    gwan: finished in 2 sec, 383 millisec and 258 microsec, 125878 req/s, 35403 kbyte/s

    weighttp -t 2 -k -n 300000 -c3000 http://localhost/helloworld.txt
    nginx: finished in 7 sec, 901 millisec and 427 microsec, 37967 req/s, 9156 kbyte/s
    gwan: finished in 2 sec, 572 millisec and 417 microsec, 116621 req/s, 32799 kbyte/s

  6. #46

    Default

    So... I guess either a lightweight web/app server with lots of unique features that "Claims Speed Records" is not a software worth benchmarking (who uses web/app servers nowadays anyway, right? ) - either it's so much easier to be biased and skeptic and wait for everybody to just forget about it.

  7. #47

    Default

    http://www.gwan.com/blog/20121001.html - still not worth benchmarking?

  8. #48
    Join Date
    Jun 2012
    Posts
    328

    Default

    Hmm? Proprietary? Install 32-bit libs to 64-bit system just to run server? Nope, thanks, they're probably kidding. I'm more than happy with Nginx performance to the date. And once it's open and popular, it's fairly easy to set up even for complicated things like CMS systems easily, etc. Running some abstract benchmarks is cool. Real world performance in some useful scenarion is way better. You see, with right approach nginx is usually I/O bound (disk or net). So there is no way to win anything more than that anyway.

  9. #49
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,338

    Default

    That's a fairly curious article. He was asked to accelerate a Java app.

    He rewrote it in C and gave it different parameters than the original used.


    I'll leave it as an exercise to the reader WTF.

  10. #50

    Default

    Wasn't point of the demo to use the ORACLE noSQL Database to test performance and scalability? Did the different parameters he used made the test easier? Are there any other app server able to outperform (or as the author puts it "able to merely run") it using JAVA, C or any other language?

    Bottom line is: IMHO if there was ever an app server worth benchmarking - it's G-WAN

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •