4 ms·
> I don't understand how you can make queueing high-performance. Queueing things is literally the opposite of making things fast. You likely need to read about
by masom 3y ago
> I don't understand how you can make queueing high-performance. Queueing things is literally the opposite of making things fast.
You likely need to read about message queues, why they are used, and why they have performance constraints. Message queues are a system, and the system to maintain those queues and content has an overhead. The project is building a solution that is higher performing than comparable systems.
Queuing things often makes things faster (!) as you are usually dealing with limited resources (ex: web and job workers) and need to operate on other systems (ex: payments) that have their own distinct capacity.
If you have 1000 web workers, and your upstream payment provider supports 10 payments per minute, you'll quickly have timeouts and other issues with 1000 web workers trying to process payments. Your site won't process anything else while waiting for the payment provider if all web workers are doing this task.
A queue will let you process 1000 web requests, and trickle 10 requests to your payment provider. At some point that queue will fill, but that's a separate issue.
Meanwhile, your 1000 web workers are free to process the next requests (ex: your homepage news feed).
- gdy 3y ago"At some point that queue will fill, but that's a separate issue" Would you recommend something to read about that?
- masom 3y agoIt's a bit difficult to cover as it is highly dependent on the queue system you use. You'd usually want your queue system to fail the enqueue if it is full, and you'd want monitoring to ensure the queue isn't growing at an unsustainable rate. It also forces you to think a bit about your message payload (rich data or foreign keys the worker loads). RabbitMQ, Redis-based queues (ex: ActiveJob or sidekiq), Gearman, and others will all offer different mechanisms to tackle full queues.
- kiitos 3y agohttps://apenwarr.ca/log/20170814 https://apenwarr.ca/log/20170814
- gdy 3y ago[dead]
- mgaunard 3y agoA queue is a thing to be managed carefully when designing systems: - you need to ensure that your producers don't produce at a faster rate than your consumers can keep up - if the consumer is unable to handle the request now, queueing it and handling it later is often not the right thing to do. Most likely by the time the resource is available the nature of the request will change. TCP itself is already a queue. All these message queue systems also make the silly decision of layering their own queueing on top of TCP, leading to all sorts of problems. Basically those things only sort of work if you have few messages and are happy with millisecond latency.
- masom 3y agoIt really depends what you design your system to handle. A sudden burst of traffic that can be spread for minutes is fine (ex: Elasticsearch indexing requests can usually be delayed through background jobs). > Basically those things only sort of work if you have few messages and are happy with millisecond latency. Not really... queues are great to defer processing or have longer running job than your HTTP and TCP timeouts will allow. Building large data export won't happen within a single HTTP request. ex: https://shopify.engineering/high-availability-background-jobs https://shopify.engineering/high-availability-background-job...