Lonestar ElixirConf 2017 talk about vutuv and Phoenix

Lonestar ElixirConf 2017 talk about vutuv and Phoenix

Ad005fac83baa60843ddf2bc3bc8fe93?s=128

Stefan Wintermeyer

February 11, 2017
Tweet

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