Gatling: High-Performance Open-Source Server

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

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

[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

[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]

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

[chithanh]

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.

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.

[curaga]

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

[russofris]

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

[chithanh]

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.

[ChrisXY]

I have to wonder how many potential contributors

Well, first you have to know that it's by no means a project with much contribution anyway, only almost only a one-man project:

 ~/gatling (cvs)-[gatling] % cvs log | grep author | grep leitner -c
980
 ~/gatling (cvs)-[gatling] % cvs log | grep author | grep -v leitner -c
5

There are hardly any websites using it and from googling I learned that back in 2003 it was written to experiment with new APIs (Benchmarks from back then) and another goal was to write a webserver that would survive being slashdotted.