Gatling: High-Performance Open-Source Server

[russofris]

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

[curaga]

@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.

[russofris]

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

[russofris]

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.

[JanC]

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"...