High scale flavor(recipes for message      queueing)             Tomas (t0m) Doran                London Perl              ...
What is message       queueing.• In it’s simplest form, it’s just a list.• 1 (or more) ‘producers’ (writers)• 1 (or more) ...
Why do I want it?• Decouples producers and consumers  (probably across the network).• Lets you manage load, and spikes in ...
What is the problem  with web apps?• App servers take a lot of RAM• Context switching expensive• A lot of apps think like ...
One page request per CPU core   Even if extra context switching has zero overhead    you serve people sooner if you queue ...
What are the solutions• Use a PAL (Page Assembly Layer) - e.g.  Varnish• Defer doing work inside the web request  to a que...
Message queueing• Many many flavors. • Going to cover options available right     now in perl• First, a little theory
Messaging Topologies• I.e. how producers and consumers interact  together through the message broker• 3 common patterns - ...
1: Publish-Subscribe• ‘Topic’ in ActiveMQ• Anonymous queues in AMQP• One (or more) publishers• Zero (or more) consumers• E...
2: Queue(s)• One or more producers• One or more consumers• Each message delivered to exactly one  consumer• Messages ‘queu...
3: Request / Response• Create anonymous queue for replies• Publish to well known queue(s), include  return address• Wait f...
STOMP• Streamed Text Oriented Messageing  Protocol• Simple. Interoperable.• You probably want to use ActiveMQ• Net::STOMP•...
ActiveMQ - Topics• Publish / subscribe semantics.• Message goes to all the subscribers• Zero or more subscribers• Messages...
ActiveMQ - Queues• Load balancer semantics.• Each message - 1 consumer.• Messages queued.• Multiple consumers• Ack require...
AMQP• More complex than STOMP• Wiring of message routing is part of the  protocol.• All your clients know (at least half) ...
AMQP Concepts              RabbitMQ                vhost  Publisher   Exchange               Queue  Consumer
Concepts - Exchanges• Named• Messages are published (sent) to one  exchange• Can be durable (forces all queues attached  t...
Queues• Queues can be named.• Queues are bound to one (or more)  exchanges.• Queues can have 0 or more clients• Queues may...
Bindings• Binding is what joins a queue and an  exchange.• There can be more than one binding for  each queue, allowing a ...
Job queue• Named exchange• Bound to 1 named and persistent queue• 0 or more listeners get round-robin  messages• Messages ...
Publish/Subscribe• Named exchange• Each client creates an anonymous  ephemeral queue• Client binds the queue to that excha...
AMQP can be complex• Different exchange types - direct, topic,  fanout (and custom exchange types  possible)• Messages hav...
Implementations:• So - I want a queue• What do I use? • Naive approaches • Job queue only approaches • More sophisticated/...
(Shared) database table• Have a ‘jobs’ table, with some data, and a  ‘status’ column.• Waiting => Running => Done• Job wor...
(Shared) database table• Have a ‘jobs’ table, with some data, and a  ‘status’ column.• Waiting => Running => Done• Job wor...
(Shared) database table• Have a ‘jobs’ table, with some data, and a  ‘status’ column.• Waiting => Running => Done• MySQL w...
(Queue) database table• Have separate queued / running / done tables• Less bad for performance - at least the ‘find  someth...
Gearman• Around since 2006. Multi platform.• Not really a message queue - designed as a  job queuing system• Client, Job S...
TheSchwartz• Is Persistent• From the same place as Gearman• Not as well adopted• Relies on a MySQL database - SPOF• Still ...
Client libs: Net::Stomp• Apache ActiveMQ.• Dead simple producers and consumers.• Just a client - you need to manage / run ...
Client libs:      Net::RabbitFoot• AMQP / RabbitMQ• AnyEvent based - non blocking.• Documentation pretty poor (sorry).• Wo...
Catalyst::Engine::Stomp•   By chrisa @ Venda & yours truly; now    maintained by Paul Moony.•   Simple framework for writi...
Net::ActiveMQ• Builds on Catalyst::Engine::STOMP• Chisel talked about this at YAPC::EU (Friday  PM ‘Going Postal’)• NetAPo...
Web::Hippie• Persistent (potentially bidirectional) web  pipe to applications.• Cheap connection, no polling needed (on  r...
CatalystX::JobServer• My current baby.• Uses AMQP.• Provides Web::Hippie pipes for jobs - shiny  shiny ajax updates.• Bare...
Conclusions• Use JSON for your message payloads.• You probably want to use Gearman if you  can get away with it.• STOMP wo...
Upcoming SlideShare
Loading in …5
×

High scale flavour

1,680 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,680
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
22
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • High scale flavour

    1. 1. High scale flavor(recipes for message queueing) Tomas (t0m) Doran London Perl Workshop 2010
    2. 2. What is message queueing.• In it’s simplest form, it’s just a list.• 1 (or more) ‘producers’ (writers)• 1 (or more) ‘consumers’ (readers)• Queue if rate of production > rate of consumption
    3. 3. Why do I want it?• Decouples producers and consumers (probably across the network).• Lets you manage load, and spikes in load (only n consumers).• In a web environment - lets you serve more pages, quicker.
    4. 4. What is the problem with web apps?• App servers take a lot of RAM• Context switching expensive• A lot of apps think like a CGI.• Making the user wait IS HORRIBLE.• Anything but very fast pages is fail.
    5. 5. One page request per CPU core Even if extra context switching has zero overhead you serve people sooner if you queue requests. A B A B A B A B A B A finishes significantly before B in the lower diagram B finishes at the same time in bothN.B. This explicitly assumes you never wait on external IO (e.g. a database)
    6. 6. What are the solutions• Use a PAL (Page Assembly Layer) - e.g. Varnish• Defer doing work inside the web request to a queue• AJAX (heavy javascript) apps making many requests make this even more important.• If your requests are all small and fast then you can win by doing multiple small requests rather than one expensive one
    7. 7. Message queueing• Many many flavors. • Going to cover options available right now in perl• First, a little theory
    8. 8. Messaging Topologies• I.e. how producers and consumers interact together through the message broker• 3 common patterns - considerably more complex applications possible.• Even within these there is additional complexity to consider, e.g. message durability.
    9. 9. 1: Publish-Subscribe• ‘Topic’ in ActiveMQ• Anonymous queues in AMQP• One (or more) publishers• Zero (or more) consumers• Every consumer gets every message• Messages discarded if no consumers• E.g. log message listener(s)
    10. 10. 2: Queue(s)• One or more producers• One or more consumers• Each message delivered to exactly one consumer• Messages ‘queued’ (possibly to disk)• E.g. Job queue with worker pool allowing you to work efficiently through high load spikes
    11. 11. 3: Request / Response• Create anonymous queue for replies• Publish to well known queue(s), include return address• Wait for reply.• Arrange for messages to be discarded if you stop listening for the reply.
    12. 12. STOMP• Streamed Text Oriented Messageing Protocol• Simple. Interoperable.• You probably want to use ActiveMQ• Net::STOMP• Simple semantics: Queues and Topics• You can build the 3 simple patterns from these
    13. 13. ActiveMQ - Topics• Publish / subscribe semantics.• Message goes to all the subscribers• Zero or more subscribers• Messages thrown away if no subscribers• Safe (cannot fill up server with undelivered messages)
    14. 14. ActiveMQ - Queues• Load balancer semantics.• Each message - 1 consumer.• Messages queued.• Multiple consumers• Ack required (auto-ack possible)• Danger will robinson!
    15. 15. AMQP• More complex than STOMP• Wiring of message routing is part of the protocol.• All your clients know (at least half) of the wiring.• Different topologies depending on routing configuration.• Nice when your server dies - no ‘current config’
    16. 16. AMQP Concepts RabbitMQ vhost Publisher Exchange Queue Consumer
    17. 17. Concepts - Exchanges• Named• Messages are published (sent) to one exchange• Can be durable (forces all queues attached to be durable)
    18. 18. Queues• Queues can be named.• Queues are bound to one (or more) exchanges.• Queues can have 0 or more clients• Queues may persist or be deleted when they have no clients• FIFO (if you have 1 consumer)• Message never delivered to > 1 client
    19. 19. Bindings• Binding is what joins a queue and an exchange.• There can be more than one binding for each queue, allowing a single consumer to listen to multiple message sources• You can bind to topic exchanges selectively via the message ‘routing key’
    20. 20. Job queue• Named exchange• Bound to 1 named and persistent queue• 0 or more listeners get round-robin messages• Messages queue when nobody listens / if consumers are slow
    21. 21. Publish/Subscribe• Named exchange• Each client creates an anonymous ephemeral queue• Client binds the queue to that exchange• All clients get all messages• Messages go to /dev/null if no clients
    22. 22. AMQP can be complex• Different exchange types - direct, topic, fanout (and custom exchange types possible)• Messages have a routing key allowing selective binding.• You can do a lot using these and a mix of named and anonymous queues• Much more complex topologies possible
    23. 23. Implementations:• So - I want a queue• What do I use? • Naive approaches • Job queue only approaches • More sophisticated/custom approaches
    24. 24. (Shared) database table• Have a ‘jobs’ table, with some data, and a ‘status’ column.• Waiting => Running => Done• Job workers poll the table and change statuses.• NO NO NO NO NO NO NO NO• No, really, mst will come and break your legs if you do this (after he stops laughing)
    25. 25. (Shared) database table• Have a ‘jobs’ table, with some data, and a ‘status’ column.• Waiting => Running => Done• Job workers poll the table and change statuses.• NO NO NO NO NO NO NO NO• No, really, mst will come and break your legs if you do this.
    26. 26. (Shared) database table• Have a ‘jobs’ table, with some data, and a ‘status’ column.• Waiting => Running => Done• MySQL will get the query plan wrong if you try joining this table (hint: the cardinality on your status column is 3).• You will lose super-hard. HAND.
    27. 27. (Queue) database table• Have separate queued / running / done tables• Less bad for performance - at least the ‘find something to do’ query is very cheap.• Still pretty terrible.• You still re-invented a big old wheel here, probably badly.
    28. 28. Gearman• Around since 2006. Multi platform.• Not really a message queue - designed as a job queuing system• Client, Job Server, Worker• Failover (multiple job servers)• NOT persistent• Simple, works well (if that’s all you need)
    29. 29. TheSchwartz• Is Persistent• From the same place as Gearman• Not as well adopted• Relies on a MySQL database - SPOF• Still simple - maybe the easiest way to get started (if you need reliable)?
    30. 30. Client libs: Net::Stomp• Apache ActiveMQ.• Dead simple producers and consumers.• Just a client - you need to manage / run your own jobs.• Blocking.• Works perfectly well for sending messages from a web app.
    31. 31. Client libs: Net::RabbitFoot• AMQP / RabbitMQ• AnyEvent based - non blocking.• Documentation pretty poor (sorry).• Works well if you have an async app.• Can be used inside a web app for simple sending.
    32. 32. Catalyst::Engine::Stomp• By chrisa @ Venda & yours truly; now maintained by Paul Moony.• Simple framework for writing jobs / managing workers.• Allows you to fire and forget, or fire and wait for termination (and pass a message back)• Achieves many of the same things a Gearman• Used in anger by several companies. (http://miltonkeynes.pm.org/talks/2010/06/paul_mooney_stomp_moosex_workers.pdf)
    33. 33. Net::ActiveMQ• Builds on Catalyst::Engine::STOMP• Chisel talked about this at YAPC::EU (Friday PM ‘Going Postal’)• NetAPorter people - poke him to release it (or at least put it on github)!
    34. 34. Web::Hippie• Persistent (potentially bidirectional) web pipe to applications.• Cheap connection, no polling needed (on reasonably modern browsers). Great as the listener part for ‘replies’• Downsides - needs to be async - no DBI (kinda)!• Plays very nicely with RabbitMQ (hint MooseX::Storage & Joose.Storage <3)
    35. 35. CatalystX::JobServer• My current baby.• Uses AMQP.• Provides Web::Hippie pipes for jobs - shiny shiny ajax updates.• Barely production ready (but useable).• I’m talking about it later...
    36. 36. Conclusions• Use JSON for your message payloads.• You probably want to use Gearman if you can get away with it.• STOMP works well and is simple, tried and tested jobs solution.• AMQP is nicer and more flexible, but there are less proven solutions (in perl).

    ×