Lonestar ElixirConf 2017 talk about vutuv and Phoenix

Transcript

1. Stefan Wintermeyer @wintermeyer
2. Today I talk about •vutuv •WebPerformance •Phoenix for Newbies
3. Business Network Think LinkedIn but open-source (MIT), free and fast. Bonus: Less annoying emails.
4. free = big challenge In the first 3 months we got > 200,000 new accounts.
5. There are many different ways of using Phoenix.
6. @chris_mccord @wintermeyer The Two Extremes
7. @chris_mccord Push Messages • > 2 Million concurrent connections on a single server • JavaScript • Heavy Load • Speed
8. @wintermeyer vutuv • No message pushing • No JavaScript • Heavy Load • Speed • No money
9. vutuv differentiates itself from other business networks by speed.
10. WebPerformance Fully Loaded on the browser: 700 ms (DSL in Germany)
11. Loading Time from Dulles, VA https://www.webpagetest.org/video/compare.php?tests=170131_QQ_BHG,170131_9F_BHH,170131_49_BHJ DSL
12. Why is WebPerformance important?
13. Jakob Nielsen’s book „Usability Engineering“ from 1993 Delay User reaction 0 - 100 ms Instant 100 - 300 ms Feels sluggish 300 - 1000 ms Machine is working… 1 s+ Mental context switch 10 s+ I’ll come back later…
14. Web Search Delay Experiment Type of Delay Delay (ms) Duration (weeks) Impact on Avg. Daily Searches Pre-header 100 4 -0.20 % Pre-header 200 6 -0.59% Post-header 400 6 0.59% Post-ads 200 4 0.30% Source: https://www.igvita.com/slides/2012/webperf-crash-course.pdf
15. Numbers by SOASTA
16. Numbers by SOASTA
17. Network latency is our biggest problem. Why?
18. TCP Source: http://en.wikipedia.org/wiki/Transmission_Control_Protocol Latency
19. Download a 58 kB file from a US east cost server to a client in Frankfurt. Protocol: HTTP Roundtrip Time: 80 ms Zeit client server 0 ms SYN --> <-- SYN,ACK 80 ms ACK --> GET --> <-- 10 TCP Segmente (14.600 Bytes) 160 ms ACK --> <-- 20 TCP Segmente (29.200 Bytes) 240 ms ACK --> <-- 40 TCP Segmente (15.592 Bytes) 320 ms ACK --> Time to download a 58 kB file: 320 ms
20. TCP Slow-Start KB 0 55 110 165 220 Roundtrip 1. 2. 3. 4. 213 99 42 14 114 57 28 14
21. SSL adds at least 
 one roundtrip.
 
 HTTP/2.0 needs SSL.
22. HTTPS KB 0 50 100 150 200 Roundtrip 1. 2. 3. 4. 199 85 28 0 114 57 28 14 SSL
23. Above the fold target: 28 KB KB 0 50 100 150 200 Roundtrip 1. 2. 3. 4. 199 85 28 0 114 57 28 14 SSL
24. Latency is king! Bandwidth is not important for normal websites.
25. Frankfurt, Germany Sydney, Australia Sydney: https://www.webpagetest.org/result/170130_3H_S13/
 Frankfurt: https://www.webpagetest.org/result/170130_YJ_SRS/ DSL
26. Frankfurt, Germany Sydney, Australia Sydney: https://www.webpagetest.org/result/170130_3H_S13/
 Frankfurt: https://www.webpagetest.org/result/170130_YJ_SRS/ DSL
27. Frankfurt: https://www.webpagetest.org/result/170131_CX_B7D/
 Sydney: https://www.webpagetest.org/result/170131_XZ_B7P/ 3G Frankfurt, Germany Sydney, Australia
28. Frankfurt: https://www.webpagetest.org/result/170131_CX_B7D/
 Sydney: https://www.webpagetest.org/result/170131_XZ_B7P/ 3G Frankfurt, Germany Sydney, Australia
29. How do we tackle WebPerformance?
30. Set a time budget and stick to it! Our time budget is 1 second within Germany.
31. Start Render Document Complete
32. Important: We can not control the network!
33. What we can control: • Transfer Protocol (e.g. HTTP/1.1 vs. HTTP/2.0) • Compression (e.g. gzip vs. zopfli vs. brotli) • Amount of files • File size • Time the server needs to generate the HTML • Content (e.g. HTML, CSS, JavaScript, Images)
35. File size Time on the server
36. The Servers
37. We use NGINX, MySQL and Phoenix Framework. Bare metal. Debian Linux.
38. Phoenix is about 
 10 times faster 
 than Ruby on Rails. Yes, I did a proof of concept of vutuv with Ruby on Rails.
39. But just a fast programming language is not good enough! Remember: We have to run vutuv.de on a dime.
40. We avoid serving freshly generated HTML when possible. Hard Drives are much cheaper than CPU.
41. NGINX is our gatekeeper. It checks for cookies and routes accordingly. I did think of Varnish but hard drive is cheaper than RAM.
42. /var/www/vutuv/ cache - index.html - index.html.gz users - xyz.html - xyz.html.gz No Cookie = Static Content Cross-Site Request Forgery (CSRF)
43. 1,000,000 users x 28 KB = 26 GB
44. Rendering a user’s profile: 50 ms. Serving a static file: less than 1 ms.
45. The Avatars A little bit more than just https://github.com/stavro/arc
52. guetzli -quality 75 a.jpg /tmp/q75-a.jpg convert a.jpg /tmp/q75-a.jpg -fx 'hypot(65-i, 65-j) < 65 ? u : v' new_a.jpg https://github.com/google/guetzli
53. By that we save 15-20% of file size. We use https://github.com/stavro/arc for uploading and initial conversion and optimize during off peak times.
54. Compression
55. /var/www/vutuv/ cache - index.html - index.html.gz users - xyz.html - xyz.html.gz Provide a compressed version of a static file.
56. html-minifier --case-sensitive --collapse-boolean-attributes --collapse-whitespace --remove-comments --remove-optional-tags --remove-tag-whitespace --sort-attributes --sort-class-name --collapse-inline-tag-whitespace --conservative-collapse a.html > b.html Optimize before compress
57. Use zopfli instead of gzip. https://github.com/google/zopfli
58. For Phoenix live content use brotli in NGINX. https://github.com/google/brotli
59. Inlining
60. HTTP caching is good but for our time budget not good enough.
61. We inline a lot.
62. We inline all the CSS. Obviously we don’t use Twitter Bootstrap.
63. We inline many images.
66. Fill the Steps KB 0 50 100 150 200 Roundtrip 1. 2. 3. 4. 199 85 28 0 114 57 28 14 SSL
67. Prefetch
68. Analyse your workflow and prefetch stuff that you’ll need in the next step. <head> […] <%= if @conn.assigns[:prefetch] do %> <link rel="prefetch" title="a" href="a.jpg"> <% end %> </head>
70. Now I’d like to talk about Phoenix.
71. As a Rails developer it took me forever and many attempts to like the Phoenix Framework.
72. Phoenix does not offer a quick reward for newbies! By now everybody should understand why speed is important if you want somebody to use something.
73. Rails offers Quick Rewards Let’s create a mini blog application on macOS.
74. Rails Blog Example
75. rails new blog cd blog rails g scaffold post subject body rails db:migrate rails s 0:30 min
76. rails new blog cd blog rails g scaffold post subject body rails db:migrate rails s Same Commands on all Operating Systems
77. Let’s compare that with Phoenix The same mini blog application on macOS.
78. Phoenix Blog Example
79. mix phoenix.new blog Y cd blog vim config/dev.exs brew install postgres brew services start postgres createuser -W --createdb blog demo mix ecto.create mix phoenix.gen.html Post posts subject body vim web/router.ex resources "/posts", PostController mix ecto.migrate mix phoenix.server 3:30 min
80. mix phoenix.new blog Y cd blog vim config/dev.exs brew install postgres brew services start postgres createuser -W --createdb blog demo mix ecto.create mix phoenix.gen.html Post posts subject body vim web/router.ex resources "/posts", PostController mix ecto.migrate mix phoenix.server Different Operating System?
81. Rails uses SQLite to make it easy for a Newbie. Phoenix should do the same.
82. Rails sets the routes for a scaffold. Phoenix should do the same.
83. mix phoenix.new blog cd blog mix ecto.create mix phoenix.gen.html Post posts subject body mix ecto.migrate mix phoenix.server This should be all
84. Thank you! www.vutuv.de https://github.com/vutuv/vutuv @wintermeyer