Asynchronous Processing for Fun and Profit

Transcript

1. Async Processing for Fun and Profit Mike Perham @mperham

2. Me Director of Engineering, TheClymb.com

3. Agenda • Basics • Protips • Sidekiq

4. Why? • User-Perceived Performance • I/O is SLOOOOOOOOOOOW • I/O

   is unreliable

5. What? • Optional work • Anything not required to build

   the HTTP response

6. How? • Client puts message on a queue • Server

   pulls message off queue • Worker executes code based on message

7. How? async do # perform some work end

8. How? • Marshalling a Proc • Need to serialize closure

9. How? async(instance, :method, args)

10. How? • Marshal instance • Marshal args

11. How? async(Class, :method, args)

12. How? • Serialize just the class name • Marshal the

    arguments

13. Congratulations! This is exactly how Resque and Sidekiq work.

14. How?

15. How?

16. How?

17. Tip #1 Small, Stateless Messages

18. Stateless • Database holds objects (nouns) • Queue holds actions

    (verbs) • “Perform X on Object 123”

19. Avoid State • Bad • @user.delay.sync_images • Good • User.delay.sync_images(@user.id)

20. Simple Types • Small & Easy to read • Cross-platform

    • Sidekiq / Resque use JSON

21. Debugging

22. Tip #2 Idempotent, Transactional Units of Work

23. Idempotent • Fancy computer science term • “Work can be

    applied multiple times without changing the result beyond the initial application”

24. Idempotent • Canceling an order • Updating user’s email address

25. Not Idempotent! • Charging credit card • Sending email

26. Idempotent • Your code has bugs! • Sidekiq will retry

    jobs that raise • Design jobs to be retried • e.g. verify you need to perform action before performing it

27. Transactional • Infinite credit?

28. Tip #3 Embrace Concurrency

29. Concurrency • Resque/DJ = 4 workers • Sidekiq = 100

    workers • Mike, what is best in life?

30. “To crush their servers, see them smoking before you and

    hear the lamentations of their admins.”

31. Concurrency • Use connection_pool gem to limit client connections •

    Split work into small batches • 100 items => 10 jobs of 10 items

32. Concurrency • Thread safety rarely an issue • Most gem

    maintainers very responsive • Recently fixed: • cocaine, typheuos

33. Theory, meet Practice

34. Sidekiq • Simple, efficient message processing • Like Resque, but

    10x faster

35. MODERN RUBY IS NOT SLOW SINGLE THREADING IS SLOW

36. Concurrency • To scale single-threaded, create lots of processes. •

    HORRIBLY RAM INEFFICIENT

37. Threads vs Processes • Example: 400MB single-threaded process • 25

    processes = 10GB RAM = EC2 xlarge • 25 threads = 1GB RAM = EC2 small • $60/month vs $480/month • 160 dynos => 10 dynos • 150 dynos * $35/month =~ $5000/month

38. Quick Rant • GIL + poor GC • C extension

    API must DIE • What’s larger: 50% or 800%?

39. Client Your App Client Middleware Redis Sidekiq Client API Rails

    Process

40. Server Processor Server Middleware Redis Worker Sidekiq Process Processor Server

    Middleware Worker Processor Server Middleware Worker Processor Server Middleware Worker Fetcher Manager

41. Versions • Sidekiq - Free, LGPLv3 • Sidekiq Pro -

    more features, support, $ • motivation!

42. Features Sidekiq Resque DJ Concurrency Store Hooks Web UI Scheduler

    Retry Delay Batches Threads Processes Processes Redis Redis DB middleware callbacks callbacks ✓ ✓ ? ✓ ? ✓ ✓ ? ✓ ✓ ? ✓ Pro ? - ? - optional

43. Future • Nicer, more functional Web UI • APIs for

    managing queues / retries • Rails 4 Queue API

44. Pro Future • Enterprise-y features • Workflow • Notifications

45. Conclusion • small, stateless messages • idempotent / transactional •

    concurrency • sidekiq

46. Questions? @mperham mperham@gmail.com