4 ms·
In my experience with web applications at non-Googley scale, most performance problems are occurring in places like SQL queries, rather than the raw speed of th
by kgilpin 8y ago
In my experience with web applications at non-Googley scale, most performance problems are occurring in places like SQL queries, rather than the raw speed of the web application stack itself.
Another really common mistake is tasks being performed inside the web request that should instead be offloaded to background job processing. If something is going to take more than milliseconds, it should be a job. If you see a PR where someone is bumping up the HTTP timeout in order to keep their slow processing request from being timed out by the webserver, they are doing something inline that should actually be a job.
- zerkten 8y agoAre there any good books or other resources on building out a system to do background processing? It seems that it's a common task, but there are different approaches.
- ryanbrunner 8y agoThe Ruby world at least seems to have settled on relatively simple Redis backed queues, where you directly request the job to be executed rather than use a more generic message broker. For sure there are more complex scenarios, but if you're just getting started you'll be well served by just reading the docs for sidekiq.
- matthewmacleod 8y agoNot a direct answer, but Rails now includes ActiveJob which abstracts over the various jobs are available and is nice and simple to set up.
- badosu 8y agoUnless you're building something with very specific requirements just use Sidekiq [0]. It's easy to install and performs very well. 0 - https://github.com/mperham/sidekiq https://github.com/mperham/sidekiq