Announcement

Collapse
No announcement yet.

G-WAN Web Server Claims Speed Records, Features

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

  • #31
    Originally posted by 0xBADCODE View Post
    Marketing brainwashing.

    You see, nginx haves no trouble to saturate 1Gbps link on common desktop hardware and would do 10Gbps at decent server hardware, leaving a plenty of resources for other tasks, granted that other I/O like HDDs could keep up with such speeds. So in fact if you dont do things horribly wrong, in real world you would end up being I/O limited anyway so no way to gain more than that without further upgrade of hardware, etc

    Not to mention Nginx features very cool cache system which could make a day if you're slashdotted. You see, serving static copy is almost instant. Running PHP (or whatever) script is not. This way, an average cheap hardware could easily withstand slashdot effect.

    And yes, it comes with source. So I have it everywhere. Up to my ARM based NAS and MIPS based router, where low resources consumption counts 10 times as much as on x86.

    p.s. lack of source implies vendor lock-in and inability to choose OS and CPU arch except those "approved" by ppl who builds blob. And ton of other artificial restrictions. That's just stupid. FAIL.
    Almost any web server can saturate its network link if its role is limited to serving statics.
    Apache is rarely the first thing to fall down when a site exceed's capacity. When was the last time you went to a slashdot'ed site and exceeded the HTTP timeout? The vast majority of sites return a 500 (when the PHP/.NET/java middleware tips over) or a "MYSQL: Too Many Connections" when the DB tips over.

    I'm not saying Apache is perfect and Nginx is horrible, just that you present them a manner neither deserves.

    F

    Comment


    • #32
      Originally posted by bulletxt View Post
      LOL I love these trolls. They should get hired from Microsoft!


      That's pretty much it. Guess there was a need to boost up Phoronix page hits...

      Comment


      • #33
        Originally posted by uid313 View Post
        Interesting.
        But does it support PHP, Python, Ruby, Mono/.NET, Java?
        It supports CGI. FastCGI support is yet to be done.

        So, everything that does CGI is supported but not as fast as it could be. Read: PHP runs.

        How does it compare against Apache, nginx, lighttpd?
        I hope we'll find out when Michael does a bench. The official PR says it uses way less RAM and is faster serving static content. Also does C plugins like gwan if speed is needed. Its script support is lacking due to no fcgi right now.

        Comment


        • #34
          Originally posted by Danny3 View Post
          On laptop - Core2Duo @ 2GHz (dualcore):
          G-WAN ~ 36 000 RPS (requests per second)
          Did you tweak it? I just started it as root and put my "hello world" txt file in the www directory... nginx with a bit increased numbers.

          Tested with: ab -c 3000 -n 50000
          nginx: Requests per second: 12790.66 [#/sec] (mean)
          gwan: Requests per second: 12282.27 [#/sec] (mean)

          Siege breaks with -c 3000... Don't know what's up with that.
          siege -b -t10s -c1000
          nginx: Transaction rate: 1390.55 trans/sec
          gwan: Transaction rate: 1407.19 trans/sec

          I'm not convinced siege is working correctly...

          edit: i5 480m

          Comment


          • #35
            Originally posted by AJenbo View Post
            Even big companyes can abruptly drop support for certen products.
            It will probably be a while before MS drops IIS. Probably the day they fold.
            Not that I'd ever use IIS....

            Comment


            • #36
              Originally posted by LightBit View Post
              Of course, if you are using Linux.
              Can you think of anything better to run as a webserver?

              Comment


              • #37
                Yes, benchmark it

                Would love to see another third-party benchmark. I've been curious about G-WAN for a few months...even thinking about trying it out in production.

                If it truly benefits smaller servers it will be a great win for small business (open-source or not). I'm not worried about the future of the platform so much: If it works better now, great! It's so simple to configure that my two-year old can do it! And if it fails down the road...well, I tried. And I'll spend the five minutes copying my non-server specific HTML, CSS, and JS back over to a battle-tested web server.

                I currently use Nginx. Some people are calling G-WAN "marketing brainwash" among other things (not trying to single out any particular comment...just chose an example). Unless a trusted benchmark can actually show that it's nothing but brainwash...then it's just people wishing they were better marketers.

                Comment


                • #38
                  Originally posted by ChrisXY View Post
                  Did you tweak it? I just started it as root and put my "hello world" txt file in the www directory... nginx with a bit increased numbers.

                  Tested with: ab -c 3000 -n 50000
                  nginx: Requests per second: 12790.66 [#/sec] (mean)
                  gwan: Requests per second: 12282.27 [#/sec] (mean)

                  Siege breaks with -c 3000... Don't know what's up with that.
                  siege -b -t10s -c1000
                  nginx: Transaction rate: 1390.55 trans/sec
                  gwan: Transaction rate: 1407.19 trans/sec

                  I'm not convinced siege is working correctly...

                  edit: i5 480m
                  No, it didn't tweak it. There's nothing to tweak at G-WAN.
                  Tested with: ab -c 100 -n 50000 -k
                  On: Ubuntu 10.10 x64
                  -k: keep-alive does big difference.
                  Whitout keep-alive ab will open and close a new connection for every request and you will actually test the kernel's speed at opening and closing connections.

                  Comment


                  • #39
                    Ah, ok.

                    ab -k -c 3000 -n 200000
                    gwan: Requests per second: 66850.15 [#/sec] (mean)
                    nginx: Requests per second: 42711.20 [#/sec] (mean)

                    ab -k -c 100 -n 100000
                    gwan: Requests per second: 87978.53 [#/sec] (mean)
                    nginx: Requests per second: 33803.25 [#/sec] (mean)

                    Maybe I have my nginx a bit "mistuned" on my dualcore with ht (Not sure if 2 threads per (virtual) core make sense).
                    Code:
                    worker_processes  8;
                    events {
                        worker_connections  8192;
                        multi_accept on;
                    }

                    Comment


                    • #40
                      Originally posted by knurdtech View Post
                      Would love to see another third-party benchmark. I've been curious about G-WAN for a few months...even thinking about trying it out in production.
                      It doesn't contain GWAN, but may serve as a useful baseline.




                      F

                      Comment


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


                          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

                                Working...
                                X