3 ms·
I would start with building the app to test the throughput. Once you have a repeatable routine to A/B benchmark each change then you are off to a great start.
by mrits 12y ago
I would start with building the app to test the throughput. Once you have a repeatable routine to A/B benchmark each change then you are off to a great start.
One you mentioned is not a crazy idea. A lot of high traffic websites are loading data from a cache so processing might not be a big deal. If there is a significant amount of work to do than getting a queue involved is a great idea. Especially when you are sending a message to be processed and don't actually care about the response.
However, keep in mind that traditionally one of the hardest things to scale on a web site is the concurrency. If you are queueing messages to different systems and leaving sockets open on your single web server you might run into some concurrency problems.
This would lead you to do some research in non-blocking IO.
- brudgers 12y agoHow is this better than serving static content from a separate domain distributed across a CDN? By which I mean that if the problem is latency for mobile users in Tunisia, putting a cache in front a server in Oklahoma doesn't improve the speed of light. If `n + 1` joins contribute to the problem it doesn't necessarily solve that either...though it might depending on the read/write ratio. And of course the read/write ratio might make performance with a cache in front worse if there are lots of cache misses and consequently flushes. Without measurement and analysis, there's no way to tell what does and doesn't constitute a bad idea. The only crazy architectural idea is changing the system around without having measurements and analysis.