Announcement

Collapse
No announcement yet.

Gatling: High-Performance Open-Source Server

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

  • phoronix
    started a topic Gatling: High-Performance Open-Source Server

    Gatling: High-Performance Open-Source Server

    Phoronix: Gatling: High-Performance Open-Source Server

    After recently bringing up the G-WAN web-server, a Phoronix reader brought up Gatling. The Gatling software is a high-performance open-source web-server not known as widely as Apache, Nginx, or lighttpd...

    http://www.phoronix.com/vr.php?view=MTE0NDQ

  • JanC
    replied
    Originally posted by pejakm View Post
    A few things I've noticed:

    - "file not found" error if there's no trailing "/" on directory name
    Which is technically correct according to the HTTP/URL specs, although not exactly "DWIM"...

    Leave a comment:


  • russofris
    replied
    Lol, My sincerest apologies. I just received some numbers and it appears that we might have been trolled by a press release..




    We can all pass GO and collect $200 and not give Gatling another thought.

    F

    EDIT: Realized I was being unfair to Michael, as he is not an SA.
    Last edited by russofris; 07-23-2012, 12:01 PM.

    Leave a comment:


  • russofris
    replied
    Originally posted by curaga View Post
    Cache. That 2mb binary will barely fit in L2, but many cpus have 64 or 128kb of L1 already. Having the entire binary in L1 code cache surely has an effect.
    Yes, but "an effect on what"? Currently the an answer is "an effect on a RPS scenario that doesn't appear to ever happen in real life".

    Again, I'm looking for a use case where these servers fit. I might be willing to concede on a web-statics profile, but am calling Gatling (and supporters) out on the RPS figures they give. What are the RPS when you're actually serving something useful? How does that compare to Apache's httpd? Does it outweigh the loss of functionality? Does it outweigh the support overhead of a heterogeneous http tier?

    I'm surprised that they're not pimping the latency benefits over RPS hokum.

    F

    Leave a comment:


  • curaga
    replied
    @Size - Arbitrary for x86, becoming arbitrary for SOC. I'm not certain what the benefit of "smaller" is other than "being smaller", which isn't typically a limitation on X86. Apache is pretty small at about 2MB for a stripped down binary.
    Cache. That 2mb binary will barely fit in L2, but many cpus have 64 or 128kb of L1 already. Having the entire binary in L1 code cache surely has an effect.

    Leave a comment:


  • russofris
    replied
    Originally posted by chithanh View Post
    Gatling has a totally different use case from Apache. No amount of compile-time options will make Apache into a 125k static x86 binary. As it says on the homepage, gatling was developed to sustain the Slashdot effect and similar flash crowd events.
    @Size - Arbitrary for x86, becoming arbitrary for SOC. I'm not certain what the benefit of "smaller" is other than "being smaller", which isn't typically a limitation on X86. Apache is pretty small at about 2MB for a stripped down binary.

    @Slashdot: When a site is slashdot'ed, Apache is rarely the tier that tips over. It's typically the middleware tier or DB tier, manifested as a 500 to the user. I see magical numbers being put out there like "15000 requests per second". I do not believe that this occurs in any real-world setting, with the exception of DDOS style attacks.

    I could see size being a factor for SOC embedded implementations of the pre-flash era, or on home brew flash based routers, but x86? Seriously? I can see RPS being an issue if you have an optimized cluster serving web-statics to users, but the statics would need to be very small for > 10000 to occur (hello world).

    Does anyone here run a stack that exceeds 1000 RPS, or 50 TPS? To put things in perspective, a Tier 2 network operator (ATT, Verizon, Sprint) rarely exceeds 50 TPS, which is about 500-2000 RPS on the front end depending on the workflow. I don't believe that the Apple store exceeds 50TPS.

    Still confused, as I am unable to reconcile the numbers with any plausible real-world scenario. A go-kart is small and fast, but I have yet to see a scenario where it would be a good fit.

    I'll drop my friends at Amazon an e-mail to see what their numbers look like.

    F

    Leave a comment:


  • chithanh
    replied
    Originally posted by russofris View Post
    I'm really curious as to why this even necessitated an article. What does Gatling have that Apache httpd does not offer, or can not be achieved with simple compile time options? While a book can be written on the reverse perspective, I've always wondered what makes all of these lightweight httpd servers attractive.
    Gatling has a totally different use case from Apache. No amount of compile-time options will make Apache into a 125k static x86 binary. As it says on the homepage, gatling was developed to sustain the Slashdot effect and similar flash crowd events.

    Originally posted by curaga View Post
    Defaults, IIRC. ./configure
    So this means the compiler flags were empty, ie. without any optimization at all? Also configure scripts typically detect what is installed on the system and adjust the build based on that.

    Leave a comment:


  • curaga
    replied
    Originally posted by chithanh View Post
    The Monkey benchmarks are of limited value, as the exact build parameters for nginx are not known. Normally you build a monolithic binary with exactly the features you want.
    Defaults, IIRC. ./configure

    Leave a comment:


  • russofris
    replied
    I'm really curious as to why this even necessitated an article. What does Gatling have that Apache httpd does not offer, or can not be achieved with simple compile time options? While a book can be written on the reverse perspective, I've always wondered what makes all of these lightweight httpd servers attractive.

    F

    Leave a comment:


  • chithanh
    replied
    Thanks to the fact that gatling does not attempt to support dynamic content, there needs not be any fast-paced development.

    The Monkey benchmarks are of limited value, as the exact build parameters for nginx are not known. Normally you build a monolithic binary with exactly the features you want.

    Leave a comment:

Working...
X