Is there any issue with > 1 job running simultaneously when the server is deployed on one machine?
I'm running a few jobs on invervals that might overlap. If I'm deployed on one machine, could that cause any issues?
6 Replies
Hi @CamBlackwood. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Based on the knowledge sources provided, there are some potential considerations when running multiple jobs simultaneously on a single deployed machine in Wasp:
1. CPU sharing: Wasp starts pg-boss (the job scheduler) alongside your web server application on the same machine. This means that jobs running via pg-boss and the rest of the server logic share the CPU. As noted in the Wasp documentation (https://wasp-lang.dev/docs/advanced/jobs#pg-boss-considerations), you should avoid running CPU-intensive tasks via jobs, as they could impact the performance of your web server.
2. Scaling limitations: Currently, Wasp does not support independent, horizontal scaling of pg-boss-only applications or starting them as separate workers/processes/threads. This means that all jobs will be competing for resources on the same machine.
3. Potential conflicts: If you have multiple jobs running on intervals that overlap, they will all be executed on the same machine. While pg-boss should handle job scheduling, there's a possibility of resource contention if the jobs are resource-intensive.
However, it's worth noting that pg-boss (the job scheduler used by Wasp) is designed to handle multiple concurrent jobs. It provides features like persistence and multi-server support, which should help mitigate some potential issues.
To minimize problems, you should:
1. Avoid CPU-intensive tasks in your jobs.
2. Be mindful of resource usage in overlapping jobs.
3. Consider staggering job schedules if possible to reduce simultaneous execution.
If you encounter performance issues or need more scalability, you might need to consider alternative deployment strategies or wait for future Wasp updates that may provide better support for scaling job processing independently of the web server.
Keep in mind that the current implementation is a trade-off between simplicity and advanced features. As mentioned in a GitHub issue comment (https://github.com/wasp-lang/wasp/issues/1255), the Wasp team is considering potential improvements to the architecture, which may address some of these limitations in the future.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @CamBlackwood, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
thanks @kapa.ai . As the jobs are just simple CRUD operations, I think I am safe 🙂
Let me check the knowledge base for you again. One moment! :books:
----------------------
You're welcome! I'm glad I could help clarify the situation for you.
You're correct in your assessment. If your jobs are primarily simple CRUD (Create, Read, Update, Delete) operations, you should indeed be safe from most of the potential issues we discussed earlier. CRUD operations are typically not CPU-intensive and are well-suited for Wasp's current job implementation.
In fact, Wasp provides built-in support for CRUD operations, which are designed to be efficient and straightforward. As mentioned in the Wasp documentation on Automatic CRUD (https://wasp-lang.dev/docs/data-model/crud#overview), you can easily define CRUD operations for your entities, and Wasp will handle much of the implementation details for you.
Just keep in mind that while basic CRUD operations should work fine, if you start adding more complex logic or data processing within these operations, you might want to reassess their impact on your system's performance.
Remember, Wasp is continually evolving, and the team is working on improving various aspects of the framework, including CRUD operations. They have plans to enhance CRUD functionality in the future, as outlined in their documentation on the future of CRUD operations (https://wasp-lang.dev/docs/data-model/crud#future-of-crud-operations-in-wasp).
If you encounter any unexpected behavior or performance issues as you develop your application, don't hesitate to reach out to the Wasp community for support.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @CamBlackwood, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
Hey @CamBlackwood, nice to see you again!
I'll just add one extra thing worth mentioning.
Your Wasp server is a single Node process, and Node is notoriously single-threaded. This can be both good and bad.
Let's say you have two jobs scheduled to start at the same time:
job1 and job2.
Node is always executing at most one line of code at a time. So, even if you have two or more jobs scheduled at the same exact moment, no two lines of code from those jobs will ever execute concurrently.
Instead, the jobs will be scheduled for execution and do their thing:
- Either sequentially (job1, then job2)
- Or intermittently (part of job1, then part of job2, then job1 again) -This happens when the jobs use async constructs.
- But never concurrently (a job1 line-of-code executing at the same time as a job2 line-of-code).
In practice, this means that your app will never experience moment with computational work peaks larger than the peak of any of its code run in isolation.
In specific terms, if there's 10 seconds of work to do across 2 jobs (5 seconds each):
- You won't see 5 seconds of 2 concurrent threads each working at 100%
- You will see 10 seconds of a single thread working at 100%
So, depending on what you want, this can be either good or bad
I'm here if you have any follow up questions 🙂thanks @Filip ! Yeah that behaviour works totally fine for me, I don't have any need for them to run concurrently as it is not time sensitive
Perfect! Glad to hear it 😄