Announcement

Collapse
No announcement yet.

G-WAN Web Server Claims Speed Records, Features

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Comment


    • #42
      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
      Buy the domain name Monkey.io and launch your business with a premium domain and a high quality logo.



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


      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

      Comment


      • #43
        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?

        Comment


        • #44
          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

          Comment


          • #45
            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

            Comment


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

              Comment


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

                Comment


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

                  Comment


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

                    Comment


                    • #50
                      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

                      Comment

                      Working...
                      X