Phoenix did really well on the data updates (2nd best) but not as well on multiple queries, which should be roughly analagous. I wonder what’s up with that.
ChaseGilliam
sztosz
In Multiple Queries it’s just SELECT + serialization to json. In Data Updates it’s SELECT + UPDATE + serialization to json. You have relevant code here: https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Elixir/phoenix/web/controllers/page_controller.ex But i don’t judge those reults, neither looked at any optimizations.
But… i don’t like this try → resque, and why String.to_integer/1, and not Integer.parse/1 also why params["queries"] and not Map.fetch(params, :queries) It all looks too much like ruby or python… i don’t know. And as much I love Python, and work in Ruby(don’t love it though ;P) You have much better ways to express intent in Elixir, so why not use it?
I just don’t trust those benchmarks at all 
1
Nicd
They’re not equivalent though. It would be Map.fetch(params, "queries"). Personally I would pattern match it in the function head (def queries(conn, %{"queries" => queries_param}) do).
1
sztosz
ChaseGilliam
dsissitka
I believe today is the last day they’ll accept pull requests for round 13.
I’m testing it now. If it is I’ll try to get one in in time.
3
PragTob
Nicd
dsissitka
I was curious to see if replacing what they have now…
q = try do
case String.to_integer(params["queries"]) do
x when x < 1 -> 1
x when x > 500 -> 500
x -> x
end
rescue
ArgumentError -> 1
end
…with something like…
q = case Integer.parse(params["queries"]) do
{x, _} when x < 1 -> 1
{x, _} when x > 500 -> 500
{x, _} -> x
:error -> 1
end
…would have a significant effect on performance.
In short, their code (~677 RPS) was about 2% slower than my code (~691 RPS) and my code was about 0.6% slower than hard-coding q (~695 RPS). With differences that small I’m not sure how much of it was the code and how much of it was the testing environment.
Unfortunately we missed the deadline for round 13 pull requests. 
https://github.com/TechEmpower/FrameworkBenchmarks/pull/2348#issuecomment-260073040
2