Announce Cowboy 2.0.0-pre.4 and make 2.0 the default

1 files changed, 120 insertions, 144 deletions

diff --git a/articles/index.xml b/articles/index.xml
index 0e8c3dea..40507060 100644
--- a/articles/index.xml
+++ b/articles/index.xml
@@ -6,10 +6,129 @@
     <description>Recent content in Articles-rsses on Nine Nines</description>
     <generator>Hugo -- gohugo.io</generator>
     <language>en-us</language>
-    <lastBuildDate>Mon, 28 Nov 2016 00:00:00 +0100</lastBuildDate>
+    <lastBuildDate>Tue, 03 Jan 2017 00:00:00 +0100</lastBuildDate>
     <atom:link href="https://ninenines.eu/articles/index.xml" rel="self" type="application/rss+xml" />
     
     <item>
+      <title>Cowboy 2.0 pre-release 4</title>
+      <link>https://ninenines.eu/articles/cowboy-2.0.0-pre.4/</link>
+      <pubDate>Tue, 03 Jan 2017 00:00:00 +0100</pubDate>
+      
+      <guid>https://ninenines.eu/articles/cowboy-2.0.0-pre.4/</guid>
+      <description>&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Cowboy &lt;code&gt;2.0.0-pre.4&lt;/code&gt; has been released!&lt;/p&gt;&lt;/div&gt;

+&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;This is the new recommended version of Cowboy.

+While I would not recommend putting it in production

+just yet, I do recommend you start writing new

+applications with this Cowboy version.&lt;/p&gt;&lt;/div&gt;

+&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;The most significant changes in the pre-release are:&lt;/p&gt;&lt;/div&gt;

+&lt;div class=&#34;ulist&#34;&gt;&lt;ul&gt;

+&lt;li&gt;

+&lt;p&gt;

+A new architecture: there now is one process per

+  connection and one process per request. This was

+  done because HTTP/2 allows running requests concurrently.

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;li&gt;

+&lt;p&gt;

+Stream handlers. Every request, response and data goes

+  through stream handlers. They are meant to replace hooks

+  and more. They will be documented in a future pre-release.

+  Check &lt;code&gt;cowboy_stream&lt;/code&gt; and &lt;code&gt;cowboy_stream_h&lt;/code&gt; if interested.

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;li&gt;

+&lt;p&gt;

+Numerous changes to the &lt;code&gt;cowboy_req&lt;/code&gt; interface. This

+  is very close to final. Check the manual for what changed.

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;li&gt;

+&lt;p&gt;

+The Req object is no longer passed in Websocket callbacks.

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;li&gt;

+&lt;p&gt;

+It is now possible to send frames directly from &lt;code&gt;websocket_init/1&lt;/code&gt;.

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;li&gt;

+&lt;p&gt;

+SPDY support was removed, now that we have HTTP/2.

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;li&gt;

+&lt;p&gt;

+Update Ranch to 1.3. We still depend on Cowlib master

+  for the time being.

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;li&gt;

+&lt;p&gt;

+A much improved manual.

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;/ul&gt;&lt;/div&gt;

+&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;The manual received a lot of love. It now has one page per

+function with a detailed description, arguments list, return

+value, changelog and examples. It also links to the other

+relevant manual pages: &lt;a href=&#34;https://ninenines.eu/docs/en/cowboy/2.0/manual/&#34;&gt;https://ninenines.eu/docs/en/cowboy/2.0/manual/&lt;/a&gt;&lt;/p&gt;&lt;/div&gt;

+&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;I am quite proud of the manual right now. While more

+improvements can be made, what we have now is way better

+than before. Feedback for further improvements is welcome!&lt;/p&gt;&lt;/div&gt;

+&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;This is a significant step toward Cowboy 2.0. Almost all

+the breaking changes are in. A few more pre-releases are

+planned and will be released on a weekly basis (with exceptions).&lt;/p&gt;&lt;/div&gt;

+&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Cowboy is now tested and supported with Erlang/OTP 18.0 or above

+on Arch Linux, FreeBSD, OSX, Ubuntu and Windows 7. Contact me

+if you can provide permanent access to another platform for the

+purposes of testing.&lt;/p&gt;&lt;/div&gt;

+&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Cowboy is now available from four locations:&lt;/p&gt;&lt;/div&gt;

+&lt;div class=&#34;ulist&#34;&gt;&lt;ul&gt;

+&lt;li&gt;

+&lt;p&gt;

+&lt;a href=&#34;https://git.ninenines.eu/cowboy.git&#34;&gt;https://git.ninenines.eu/cowboy.git&lt;/a&gt;

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;li&gt;

+&lt;p&gt;

+&lt;a href=&#34;https://github.com/ninenines/cowboy.git&#34;&gt;https://github.com/ninenines/cowboy.git&lt;/a&gt;

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;li&gt;

+&lt;p&gt;

+&lt;a href=&#34;https://bitbucket.org/ninenines/cowboy.git&#34;&gt;https://bitbucket.org/ninenines/cowboy.git&lt;/a&gt;

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;li&gt;

+&lt;p&gt;

+&lt;a href=&#34;https://gitlab.com/ninenines/cowboy.git&#34;&gt;https://gitlab.com/ninenines/cowboy.git&lt;/a&gt;

+&lt;/p&gt;

+&lt;/li&gt;

+&lt;/ul&gt;&lt;/div&gt;

+&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;They are updated at the same time so there is no real difference.&lt;/p&gt;&lt;/div&gt;

+&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Cowboy 2.0 will be released once all the breaking changes

+are completed and the temporarily removed features are

+added back.&lt;/p&gt;&lt;/div&gt;

+&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Thanks for your patience. I know it took a long time.&lt;/p&gt;&lt;/div&gt;

+&lt;hr/&gt;

+&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Half-price on all donations because I need a new hat:&lt;/p&gt;&lt;/div&gt;

+&lt;form action=&#34;https://www.paypal.com/cgi-bin/webscr&#34; method=&#34;post&#34; style=&#34;display:inline&#34;&gt;

+&lt;input type=&#34;hidden&#34; name=&#34;cmd&#34; value=&#34;_donations&#34;&gt;

+&lt;input type=&#34;hidden&#34; name=&#34;business&#34; value=&#34;[email protected]&#34;&gt;

+&lt;input type=&#34;hidden&#34; name=&#34;lc&#34; value=&#34;FR&#34;&gt;

+&lt;input type=&#34;hidden&#34; name=&#34;item_name&#34; value=&#34;Loic Hoguin&#34;&gt;

+&lt;input type=&#34;hidden&#34; name=&#34;item_number&#34; value=&#34;99s&#34;&gt;

+&lt;input type=&#34;hidden&#34; name=&#34;currency_code&#34; value=&#34;EUR&#34;&gt;

+&lt;input type=&#34;hidden&#34; name=&#34;bn&#34; value=&#34;PP-DonationsBF:btn_donate_LG.gif:NonHosted&#34;&gt;

+&lt;input type=&#34;image&#34; src=&#34;https://www.paypalobjects.com/en_US/i/btn/btn_donate_LG.gif&#34; border=&#34;0&#34; name=&#34;submit&#34; alt=&#34;PayPal - The safer, easier way to pay online!&#34;&gt;

+&lt;img alt=&#34;&#34; border=&#34;0&#34; src=&#34;https://www.paypalobjects.com/fr_FR/i/scr/pixel.gif&#34; width=&#34;1&#34; height=&#34;1&#34;&gt;

+&lt;/form&gt;

+</description>
+    </item>
+    
+    <item>
       <title>Ranch 1.3</title>
       <link>https://ninenines.eu/articles/ranch-1.3/</link>
       <pubDate>Mon, 28 Nov 2016 00:00:00 +0100</pubDate>
@@ -1469,148 +1588,5 @@ expressions so I thought it was a good idea to anticipate.&lt;/p&gt;&lt;/div&gt;
 </description>
     </item>
     
-    <item>
-      <title>Erlang Scalability</title>
-      <link>https://ninenines.eu/articles/erlang-scalability/</link>
-      <pubDate>Mon, 18 Feb 2013 00:00:00 +0100</pubDate>
-      
-      <guid>https://ninenines.eu/articles/erlang-scalability/</guid>
-      <description>&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;I would like to share some experience and theories on

-Erlang scalability.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;This will be in the form of a series of hints, which

-may or may not be accompanied with explanations as to why

-things are this way, or how they improve or reduce the scalability

-of a system. I will try to do my best to avoid giving falsehoods,

-even if that means a few things won&amp;#8217;t be explained.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;sect1&#34;&gt;

-&lt;h2 id=&#34;_nifs&#34;&gt;NIFs&lt;/h2&gt;

-&lt;div class=&#34;sectionbody&#34;&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;NIFs are considered harmful. I don&amp;#8217;t know any single NIF-based

-library that I would recommend. That doesn&amp;#8217;t mean they should

-all be avoided, just that if you&amp;#8217;re going to want your system to

-scale, you probably shouldn&amp;#8217;t use a NIF.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;A common case for using NIFs is JSON processing. The problem

-is that JSON is a highly inefficient data structure (similar

-in inefficiency to XML, although perhaps not as bad). If you can

-avoid using JSON, you probably should. MessagePack can replace

-it in many situations.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Long-running NIFs will take over a scheduler and prevent Erlang

-from efficiently handling many processes.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Short-running NIFs will still confuse the scheduler if they

-take more than a few microseconds to run.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Threaded NIFs, or the use of the &lt;code&gt;enif_consume_timeslice&lt;/code&gt;

-might help allievate this problem, but they&amp;#8217;re not a silver bullet.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;And as you already know, a crashing NIF will take down your VM,

-destroying any claims you may have at being scalable.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Never use a NIF because &#34;C is fast&#34;. This is only true in

-single-threaded programs.&lt;/p&gt;&lt;/div&gt;

-&lt;/div&gt;

-&lt;/div&gt;

-&lt;div class=&#34;sect1&#34;&gt;

-&lt;h2 id=&#34;_bifs&#34;&gt;BIFs&lt;/h2&gt;

-&lt;div class=&#34;sectionbody&#34;&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;BIFs can also be harmful. While they are generally better than

-NIFs, they are not perfect and some of them might have harmful

-effects on the scheduler.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;A great example of this is the &lt;code&gt;erlang:decode_packet/3&lt;/code&gt;

-BIF, when used for HTTP request or response decoding. Avoiding

-its use in &lt;em&gt;Cowboy&lt;/em&gt; allowed us to see a big increase in

-the number of requests production systems were able to handle,

-up to two times the original amount. Incidentally this is something

-that is impossible to detect using synthetic benchmarks.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;BIFs that return immediately are perfectly fine though.&lt;/p&gt;&lt;/div&gt;

-&lt;/div&gt;

-&lt;/div&gt;

-&lt;div class=&#34;sect1&#34;&gt;

-&lt;h2 id=&#34;_binary_strings&#34;&gt;Binary strings&lt;/h2&gt;

-&lt;div class=&#34;sectionbody&#34;&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Binary strings use less memory, which means you spend less time

-allocating memory compared to list-based strings. They are also

-more natural for strings manipulation because they are optimized

-for appending (as opposed to prepending for lists).&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;If you can process a binary string using a single match context,

-then the code will run incredibly fast. The effects will be much

-increased if the code was compiled using HiPE, even if your Erlang

-system isn&amp;#8217;t compiled natively.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Avoid using &lt;code&gt;binary:split&lt;/code&gt; or &lt;code&gt;binary:replace&lt;/code&gt;

-if you can avoid it. They have a certain overhead due to supporting

-many options that you probably don&amp;#8217;t need for most operations.&lt;/p&gt;&lt;/div&gt;

-&lt;/div&gt;

-&lt;/div&gt;

-&lt;div class=&#34;sect1&#34;&gt;

-&lt;h2 id=&#34;_buffering_and_streaming&#34;&gt;Buffering and streaming&lt;/h2&gt;

-&lt;div class=&#34;sectionbody&#34;&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Use binaries. They are great for appending, and it&amp;#8217;s a direct copy

-from what you receive from a stream (usually a socket or a file).&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Be careful to not indefinitely receive data, as you might end up

-having a single binary taking up huge amounts of memory.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;If you stream from a socket and know how much data you expect,

-then fetch that data in a single &lt;code&gt;recv&lt;/code&gt; call.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Similarly, if you can use a single &lt;code&gt;send&lt;/code&gt; call, then

-you should do so, to avoid going back and forth unnecessarily between

-your Erlang process and the Erlang port for your socket.&lt;/p&gt;&lt;/div&gt;

-&lt;/div&gt;

-&lt;/div&gt;

-&lt;div class=&#34;sect1&#34;&gt;

-&lt;h2 id=&#34;_list_and_binary_comprehensions&#34;&gt;List and binary comprehensions&lt;/h2&gt;

-&lt;div class=&#34;sectionbody&#34;&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Prefer list comprehensions over &lt;code&gt;lists:map/2&lt;/code&gt;. The

-compiler will be able to optimize your code greatly, for example

-not creating the result if you don&amp;#8217;t need it. As time goes on,

-more optimizations will be added to the compiler and you will

-automatically benefit from them.&lt;/p&gt;&lt;/div&gt;

-&lt;/div&gt;

-&lt;/div&gt;

-&lt;div class=&#34;sect1&#34;&gt;

-&lt;h2 id=&#34;_gen_server_is_no_silver_bullet&#34;&gt;gen_server is no silver bullet&lt;/h2&gt;

-&lt;div class=&#34;sectionbody&#34;&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;It&amp;#8217;s a bad idea to use &lt;code&gt;gen_server&lt;/code&gt; for everything.

-For two reasons.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;There is an overhead everytime the &lt;code&gt;gen_server&lt;/code&gt; receives

-a call, a cast or a simple message. It can be a problem if your

-&lt;code&gt;gen_server&lt;/code&gt; is in a critical code path where speed

-is all that matters. Do not hesitate to create other kinds of

-processes where it makes sense. And depending on the kind of process,

-you might want to consider making them special processes, which

-would essentially behave the same as a &lt;code&gt;gen_server&lt;/code&gt;.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;A common mistake is to have a unique &lt;code&gt;gen_server&lt;/code&gt; to

-handle queries from many processes. This generally becomes the

-biggest bottleneck you&amp;#8217;ll want to fix. You should try to avoid

-relying on a single process, using a pool if you can.&lt;/p&gt;&lt;/div&gt;

-&lt;/div&gt;

-&lt;/div&gt;

-&lt;div class=&#34;sect1&#34;&gt;

-&lt;h2 id=&#34;_supervisor_and_monitoring&#34;&gt;Supervisor and monitoring&lt;/h2&gt;

-&lt;div class=&#34;sectionbody&#34;&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;A &lt;code&gt;supervisor&lt;/code&gt; is also a &lt;code&gt;gen_server&lt;/code&gt;,

-so the previous points also apply to them.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;Sometimes you&amp;#8217;re in a situation where you have supervised

-processes but also want to monitor them in one or more other

-processes, effectively duplicating the work. The supervisor

-already knows when processes die, why not use this to our

-advantage?&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;You can create a custom supervisor process that will perform

-both the supervision and handle exit and other events, allowing

-to avoid the combination of supervising and monitoring which

-can prove harmful when many processes die at once, or when you

-have many short lived processes.&lt;/p&gt;&lt;/div&gt;

-&lt;/div&gt;

-&lt;/div&gt;

-&lt;div class=&#34;sect1&#34;&gt;

-&lt;h2 id=&#34;_ets_for_lolspeed_tm&#34;&gt;ets for LOLSPEED(tm)&lt;/h2&gt;

-&lt;div class=&#34;sectionbody&#34;&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;If you have data queried or modified by many processes, then

-&lt;code&gt;ets&lt;/code&gt; public or protected tables will give you the

-performance boost you require. Do not forget to set the

-&lt;code&gt;read_concurrency&lt;/code&gt; or &lt;code&gt;write_concurrency&lt;/code&gt;

-options though.&lt;/p&gt;&lt;/div&gt;

-&lt;div class=&#34;paragraph&#34;&gt;&lt;p&gt;You might also be thrilled to know that Erlang R16B will feature

-a big performance improvement for accessing &lt;code&gt;ets&lt;/code&gt; tables

-concurrently.&lt;/p&gt;&lt;/div&gt;

-&lt;/div&gt;

-&lt;/div&gt;

-</description>
-    </item>
-    
   </channel>
 </rss>
\ No newline at end of file