Vroom, Ruby Vroom

Transcript

1. vroom ruby, vroom @k0ws1k github.com/kowsik

2. about me former CTO @mudynamics now CTO @blitz_io rubyist since

   2006 led a team to build a 250K LoC commercial, non- web-app codebase

3. @mudynamics commercial fuzzer on steroids first version in C++ second

   version was ruby bindings over C++ VALUE pointers and rb_scan_args() rb_gc_mark() and rb_gc_start() third version was pure ruby with C ext profit!

4. fuzzing https:/ /github.com/rails/rails/issues/5228

5. fuzzing methodical fault injection into http, spdy, soap, json, xml,

   you name it automated -ve rspec hdd - hacker driven development broke/hacked a lot of things printers, browsers, web apps, voip gateways, video servers, IM servers speed of execution was super important

6. ruby clean and beautiful, outside and inside <3 principle of

   least surprise extensions in C almost like writing ruby rb_raise, rb_call, etc 1.8.7 interpreter “purer” than 1.9.2 the VM complexifies the code paths harder to do code walkthroughs

7. languages are neither slow or fast interpreter implementation trade-offs matter

   optimizations and gotchas comes down to “big oh”

8. big oh you prolly seen O(1), O(logn), O(n), O(n2) things

   that make you go doh when you get it majority of performance issues poor choice of data structures algorithms capped speed of light => don’t blame rails that it’s slow

9. big-oh in figs 0 10 20 30 40 1 3

   5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 O(1) O(logn) O(n) O(n^2)

10. little things

11. gem install t command line twitter - very cool, but...

    in --version 0.6.2 `time t` => 1.34s oh really, but why?

12. hacking t vi bin/t line #4 p $LOADED_FEATURES.size; exit 1

    `t` => 433 Hmm, lots of dependencies, but still ruby -e ‘p $LOADED_FEATURES.class’ => Array

13. load.c#rb_feature_p features = get_loaded_features(); for (i = 0; i <

    RARRAY_LEN(features); ++i) { v = RARRAY_PTR(features)[i]; f = StringValuePtr(v); if ((n = RSTRING_LEN(v)) < len) continue; if (strncmp(f, feature, len) != 0) {

14. $LOADED_FEATURES .0s 7.5s 15.0s 22.5s 30.0s 1 10 100 1000

    10000 100000 1000000 $LOADED_FEATURES

15. rails startup time gem install rails rails new foobar vi

    config/routes.rb p $LOADED_FEATURES.size => 784 watch this as you build a real app

16. medium things

17. @blitz_io polyglot distributed app that makes load testing a fun

    sport capacity planning, sizing, scalability questions sinatra, jQuery, backbone.js, couchdb, redis & C++ recently experimenting with dynamodb running on all 7 regions of AWS so you can say => send me 10K users from singapore integrations with new relic, copper egg & scoutapp

18. @blitz_io

19. early days no redis just yet before filter for cookie

    -> session before do @account = @db.get session[:id] end couchdb gets hammered for static assets doh!

20. self ddos first architecture filtered _changes with couchdb 10’s of

    engines worldwide huge self-ddos on each sprint/rush couchdb engines

21. ddos mitigation switch to redis for queuing, couchdb for persistence

    BRPOPLPUSH is atomic, O(1) and light-weight completed jobs move from redis to couchdb dropped UI response time from ~750ms to < 20ms

22. bigger things

23. ObjectSpace Number of objects and GC hiccups Big Oh remember?

    github.com/kowsik/vroom vroom-blitz.herokuapp.com /gc /gc_count Explicit GC every 10 seconds

24. GC hiccups Rails app from a @blitz_io customer

25. Concurrency vs Hit-rate hit-rate is number of requests/second not the

    same as average response time! concurrency is number of open sockets aka simultaneous users single threaded sinatra has a concurrency of one!

26. hit-rate vroom-ruby.herokuapp.com/sync?delay=1000 get '/sync' do delay = params[:delay].to_i rescue 0

    sleep(delay/1000.0) unless delay.zero? "#{delay} ms" end expect hit-rate of 1/second and average response time of 1 second blitz => -p 1-1:60

27. concurrency what happens if we increase concurrency? blitz => -p

    1-10:60

28. let’s make it async async behaves like a load-balanced cluster

    aget '/async' do delay = params[:delay].to_i rescue 0 EM.add_timer(delay/1000.0) do body "#{delay} ms" end end each request still takes 1 second but you gain concurrency because of multiplexing => hit-rate is no longer 1/second

29. connection pools vroom-ruby.herokuapp.com/pool?delay=1000 uses a thread pool size of 10

    8 lane highway becoming 1 lane leading to congestion only observable at concurrencies > pool size blitz => -p 1-10:10,10-10:10,10-50:10,50-50:60

30. redis in @blitz_io engine registration write-through cache job scheduling API

    throttling but redis is a data structure server big oh with all its might

31. redis doh’s Lists - LINDEX, LINSERT, LREM => O(n) Sets

    - SDIFF, SDIFFSTORE, SUNION, SUNIONSTORE => O(n) Sets - SINTER, SINTERSTORE => O(n*m)

32. wrapping up performance is a fun sport slowness usually has

    reasons check data-structures check algorithms just takes some experience to spot the problems and it’s not always rails

33. questions? @k0ws1k @blitz_io