<div dir="ltr"><div style>I agree that having a web request process be "debuggable" using the sys module can be quite useful. So far no users of Elli has told me of such a wish. For myself and the users of Elli I know of, process_info/2 has been very helpful in debugging the web request processes.<br>
</div><div style><br></div><div style>If you want a webserver that strictly follows the OTP principles, maybe you should use Cowboy. There are both pros and cons with doing so and as is pretty obvious, people have different views of the tradeoffs. Some might think it is an absolute requirement to strictly follow the OTP principles, others might think there are cases when it doesn't make much sense.<br>
</div><div style><br></div><div style>Elli is not meant to be everything to everybody. If you find it hard to debug Elli, cursing my name is misplacing your anger and won't help you achieve anything. I happily help anybody who comes to me with questions.<br>
</div><div style><br></div><div style>Knut</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 26, 2013 at 4:48 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">They are not short lived. Spawning unsupervised processes is only fine if you spawn the process to do exactly one thing and that thing cannot get the process stuck (otherwise you got an invisible leak). And you say it yourself, your processes do keep-alive. So they can be open for quite a while.<br>
<br>
Now if a request handler gets stuck for one reason or another, and the process is supervised, it takes about 5 minutes to find what's wrong because the OTP tools and libraries do all the work for you in figuring it out. You don't have to think, you already know how to deal with issues.<br>
<br>
If the process isn't supervised, you cut yourself from most of the documented tools and techniques, for example none of your processes will show up in observer. You also force your users to figure out the alternative ways to debug things instead of what they use everywhere else (see Fred's posts [1] and [2]). You have to write custom code to extract metrics, logging will work in unexpected ways, etc. And the worse part is that you essentially reimplemented a supervisor in your Elli server process.<br>
<br>
Yesterday I was debugging an issue and found out file:consult/1 calls were getting stuck (bug report incoming, still testing things). If I was using Elli, I would have cursed your name many times because of all the time I'd have lost trying to understand how to debug this thing.<br>
<br>
Following OTP principles is one of Cowboy's most important feature, and this will soon be improved again by making even request processes special processes that you can debug like you would a gen_server. At this point everything will be a special process. This is especially important since the Web continues moving toward long-running connections with Websocket, SPDY and HTTP/2.0.<br>
<br>
[1] <a href="http://ferd.ca/poll-results-erlang-maintenance.html" target="_blank">http://ferd.ca/poll-results-<u></u>erlang-maintenance.html</a><br>
[2] <a href="http://ferd.ca/code-janitor-nobody-s-dream-everyone-s-job-and-how-erlang-can-help.html" target="_blank">http://ferd.ca/code-janitor-<u></u>nobody-s-dream-everyone-s-job-<u></u>and-how-erlang-can-help.html</a><div class="im">
<br>
<br>
On 06/26/2013 11:23 AM, Knut Nesheim wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I'm a bit curious to your comments about unsupervised processes in Elli<br>
and Elli not following the OTP principles. Why do you think unsupervised<br>
request processes is a bad thing? They are short-lived and you cannot<br>
restart them in any meaningful way.<br>
<br>
It is true that Elli does not hook any of the processes it creates into<br>
a supervisor. As a user of Elli, you include the Elli "server" inside<br>
your supervision tree. This server starts linked acceptor processes<br>
which accepts a new connection, then handles the request (and<br>
keep-alive) before they die and the Elli server starts a new acceptor.<br>
If any of these processes exits abnormally, Elli knows about it. If you<br>
wish to find these processes to debug something, you can use<br>
elli:get_acceptors(ElliPid) or process_info(ElliPid, links). Mochiweb<br>
and Yaws does more or less the same.<br>
<br>
Knut<br>
<br>
<br>
On Tue, Jun 25, 2013 at 10:06 PM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a><br></div><div class="im">
<mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>> wrote:<br>
<br>
You'd also end up with tons of unsupervised processes, which isn't a<br>
good thing when you want to see what's wrong in your production<br>
system later on (something I last did today and do quite regularly<br>
when consulting). That's the biggest difference between the two,<br>
Cowboy follows OTP principles, elli doesn't. Unfortunately<br>
supervision does have a cost when you need to accept many<br>
short-lived processes quickly, but we have done a lot of work in<br>
Ranch to reduce that cost as much as possible. You could always<br>
replace Ranch with something that doesn't supervise if you really<br>
need to optimize to death, but so far even the handful of companies<br>
that I know that use it for ad bidding and other high frequency<br>
purposes haven't had the need to do that.<br>
<br>
In short: removing supervision only looks good on benchmarks.<br>
<br>
<br>
On 06/25/2013 09:52 PM, okeuday wrote:<br>
<br>
When I use their benchmark here:<br></div>
<a href="https://github.com/yesodweb/__benchmarks" target="_blank">https://github.com/yesodweb/__<u></u>benchmarks</a><div class="im"><br>
<<a href="https://github.com/yesodweb/benchmarks" target="_blank">https://github.com/yesodweb/<u></u>benchmarks</a>><br>
(as mentioned here:<br></div>
<a href="http://www.yesodweb.com/blog/__2011/03/preliminary-warp-__cross-language-benchmarks" target="_blank">http://www.yesodweb.com/blog/_<u></u>_2011/03/preliminary-warp-__<u></u>cross-language-benchmarks</a><br>
<<a href="http://www.yesodweb.com/blog/2011/03/preliminary-warp-cross-language-benchmarks" target="_blank">http://www.yesodweb.com/blog/<u></u>2011/03/preliminary-warp-<u></u>cross-language-benchmarks</a>>)<div class="im">
<br>
to test elli, here:<br>
<a href="https://github.com/knutin/elli" target="_blank">https://github.com/knutin/elli</a><br>
<br>
I get 99000 req/s. The (httperf) test of CloudI's http_req erlang<br>
service using cowboy gives 13358 req/s. cowboy has more<br>
features, so<br>
that can explain the extra average latency which limits throughput.<br>
<br>
If you want to understand why their benchmark isn't decent, read<br>
this:<br></div>
<a href="http://www.mnot.net/blog/2011/__05/18/http_benchmark_rules" target="_blank">http://www.mnot.net/blog/2011/<u></u>__05/18/http_benchmark_rules</a><div class="im"><br>
<<a href="http://www.mnot.net/blog/2011/05/18/http_benchmark_rules" target="_blank">http://www.mnot.net/blog/<u></u>2011/05/18/http_benchmark_<u></u>rules</a>><br>
<br>
So, if you want something faster in Erlang, you could use ellis,<br>
however, keep in mind their testing isn't long enough to be<br>
meaningful<br>
(due to garbage collection and other impacts on performance).<br>
<br>
<br>
On Tuesday, June 25, 2013 10:38:25 AM UTC-7, BM Kim wrote:<br>
<br>
Damian Dobroczyński <qoocku <at> <a href="http://gmail.com" target="_blank">gmail.com</a><br></div>
<<a href="http://gmail.com" target="_blank">http://gmail.com</a>> <<a href="http://gmail.com" target="_blank">http://gmail.com</a>>> writes:<br>
<br>
><br>
> W dniu <a href="tel:25.06.2013%2013" value="+12506201313" target="_blank">25.06.2013 13</a> <tel:25.06.2013%2013>:51, BM Kim pisze:<div><div class="h5"><br>
> > Hi folks,<br>
> ><br>
> > First of all, I want to apologise for my poor english<br>
skills,<br>
> > since english is not my first language, but I'll try<br>
my best<br>
> > to formulate my quesions as clear as possible.<br>
> ><br>
> > Second, I've just begun to learn erlang, so if I'm asking<br>
> > obvious "noob" questions I apologise for that too in<br>
advance...<br>
> ><br>
> > Anywho, now to my actual question:<br>
> ><br>
> > I am planning to write a high-performance server<br>
application in<br>
erlang,<br>
> > which will primarily handle HTTP requests. After some<br>
reseach with<br>
google,<br>
> > I narrowed down my choices to cowboy, misultin and<br>
mochiweb and<br>
decided<br>
> > to go with the cowboy library first...<br>
> ><br>
> > Looking at some tutorials, I've quickly built a small<br>
server<br>
capable of<br>
> > serving static files and was eager to see first<br>
benchmark-results...<br>
> > I've also built a small Haskell server using Warp<br>
library to<br>
compare it<br>
> > with erlang's cowboy...<br>
> ><br>
> > But my first impression was, that my cowboy server is<br>
much much<br>
slower<br>
than<br>
> > expected when serving static-files and after some<br>
research I<br>
found a<br>
presentation<br>
> > of the cowboy's author claiming that cowboy shouldn't<br>
be used for<br>
serving<br>
> > static-files. So I modified the server code, so that<br>
it replies<br>
to every<br>
> > request with in-memory 4Kb binary blob and compared it<br>
with my<br>
haskell<br>
warp<br>
> > server serving 4kb static file...<br>
> ><br>
> > this is my simple cowboy's http handler:<br>
> ><br>
> ><br>
<br></div></div>
------------------------------<u></u>__----------------------------<u></u>--__----------<div class="im"><br>
> ><br>
> > blob() -><br>
> > [<<0:8>> || _ <- lists:seq(1,4096)].<br>
><br>
> First, try to replace blob/0 function with this:<br>
><br>
> blob() -> <<0:(4096*8)>>.<br>
><br>
> Then, restart the test and report ;)<br>
><br>
<br>
<br>
Hi,<br>
<br>
Thank you very much for pointing out the obvious mistake...<br>
After correcting it, I got improvement from 5940 req/s to<br>
8650 req/s...<br>
<br>
But still much slower than the haskell warp-server, which<br>
has throughput<br>
of 38000 req/s...<br>
<br>
But I have another question regarding blob/0. Is it going to be<br>
evaluated<br>
only once (like GHC would do) since it is a pure<br>
expression? I'm not<br>
so sure, since erlang is not pure and any function can have<br>
side-effects<br>
which you can't mark as with the IO monad in Haskell...<br>
<br></div>
______________________________<u></u>___________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-q...@erlang.org" target="_blank">erlang-q...@erlang.org</a> <mailto:<a href="mailto:erlang-q...@erlang.org" target="_blank">erlang-q...@erlang.org</a><u></u>> <javascript:><br>
<a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><br>
<<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>><br>
<<a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><br>
<<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>>><br>
<br>
<br>
<br>
<br>
______________________________<u></u>___________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><br>
<a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><div class="im"><br>
<<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>><br>
<br>
<br>
<br>
--<br>
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br></div>
______________________________<u></u>___________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><br>
<a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><br>
<<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>><br>
<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
-- <br>
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
</div></div></blockquote></div><br></div></div>