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)
34. None

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

46. None
47. None
48. None
49. None
50. None
51. None

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.

64. None
65. None

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>
69. None

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