Web-frameworks: Yaws

[dalbhat]

• Language : Erlang (Yaws) @waghanza
• Repo : https://github.com/klacke/yaws
• Author : @klacke

[waghanza]

@dalbhat Thanks for this, having erlang here will be :heart:

[dalbhat]

I suspect it would perform very highly on the benchmarks. Another thing your benchmark perhaps doesn't test is performance under stress/against DDOS attacks etc (I'm super tired and haven't really read into what it tests yet). Erlang web servers and yaws in specific are known for being very, very resistant to attack and being extremely stable.

[waghanza]

@dalbhat Indeed. This project is about performance checking in general use case :stuck_out_tongue: Actually, there is not plan to add such a feature (check performance in some specific use case / situation), but any idea is :heart:

[waghanza]

Hi @klacke @vinoski,

Are you OK to include yaws in this list ?

Regards,

[vinoski]

@waghanza Sure, that's fine, and thanks for checking.

One problem I can see is that Yaws supports several different server application models, and each performs differently. For example, a .yaws page is typically an HTML page with Erlang/Yaws code embedded between <erl> ... </erl> tags; when a client requests it, it's processed to find the embedded code, compile it, cache the compilation result for future requests, and replace what's between those tags with the result of running that code. Another model, an appmod, is a compiled Erlang module that fulfills requests for resources specified in configuration. There are a few others, plus of course you could always have a plain old static page. So my questions are:

1. Which model will you measure?
2. Who will develop the code to be measured?
3. Are we allowed to review what's been implemented and deployed?

[OvermindDL1]

Yaws is not a super efficient web server, it is a very capable server though, a full stack thing with lots of features, but compared to cowboy (pure web serving, basically no features) there is no comparison on speed, so I wouldn't actually expect it to do terribly well (although it will scale to multiple cores very nicely).

[vinoski]

@OvermindDL1 That sounds about right. With Yaws we don't focus on speed because

• Speed means different things to different users and different workloads
• Our users never complain about speed
• Frankly, speed is overrated — I wrote about this general problem in the context of enterprise middleware way back in 2003, but it all applies to web servers too: http://steve.vinoski.net/pdf/IEEE-The_Performance_Presumption.pdf

Even so, looking at the many results already being measured here, there's quite a wide variation in speed and performance across the various systems, which is why it's fine with me if Yaws is added to the mix.

[waghanza]

This project is about showing performance (with the same implementation for each framework). The initial goal is not to have a performance race, as you said @vinoski performance could mean a lot of thinks :heart:

Basically, the implementation here suits for a specific use case, a CRUD api

[waghanza]

@OvermindDL1 @vinoski if you want to give a try, the rules are in https://github.com/the-benchmarker/web-frameworks/issues/221#issue-328459520

if no I will give a try, and ask for review :stuck_out_tongue:

[OvermindDL1]

@waghanza Shouldn't those rules be amended to state that the ID needs to be cast/converted to an integer as well?

And I haven't implemented a Yaws server in 10 years, I doubt I'd do it right for the modern Yaws... ^.^;

[waghanza]

@OvermindDL1

Shouldn't those rules be amended to state that the ID needs to be cast/converted to an integer as well?

Yes, but I prefer to add a documentation for that after https://github.com/the-benchmarker/web-frameworks/pull/1207

And I haven't implemented a Yaws server in 10 years, I doubt I'd do it right for the modern Yaws... ^.^;

Neither do I, but anyway, I'll give a try on some day, but be my guest, if you want to