-
Notifications
You must be signed in to change notification settings - Fork 208
Re-institute async mode #644
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
@joshleblanc thanks for this amazing job! I installed the fork in an app hosted on Heroku that servers webhooks from a live application. I've run it as a separate process though (as a worker). My So far it looks very good:
I used to run the worker before without recurring jobs because it would consume all RAM. Now, even with recurring jobs it takes ~2x less RAM! Thanks for sharing this work! |
|
I'd like to help get this finished up, so that non-forking implementations like JRuby can use Solid Queue. Is it complete enough that I could try to run on JRuby now and see what's missing? Do you have an example I could try? |
|
See #679 for my recent request to have a non-forking implementation. |
|
Just give me a bit.more time on the JEP-380 socket PR. I can talk to Cruby, C, or any other language using jruby as the layer via Linux Sockets. Separation of concerns. Let both interpreters run as independent processes and communicate via unix sockets and message pack. I should having it ready by this evening/tomorrow morning. |

This is less of a "this is ready to be merged", and more of an effort to reinvigorate conversation around this feature. I cobbled this together as a proof of concept because I simply couldn't use the multi-process approach on the server I'm trying to deploy to. This is related to #343, and tries to naively reimplement this
I originally stumbled on this feature because I was testing Kamal on a 1GB VPS. The initial deploy would work, however there wasn't enough resource headroom for the second deploy. I narrowed this down to SQ using ~100MB per process, essentially taking up half the available memory on the system.
After implementing this change, I saw the application memory drop from ~700MB to ~270MB.
The usage is simply placing this in puma.rb
I currently have this deployed to a 1GB droplet - the application is running quickly, background jobs are running, and redeploys are succeeding