emily-humphreys
commented
4 years ago Yep lets do it
On Wed, Jun 17, 2020 at 7:31 PM Tom Tuddenham notifications@github.com wrote:
Problem
Wicked is currently running on a single app server. Long running process ( e.g. running reports, or importing data) have the potential to block operations, causing the application to "hang". It is relatively easy to block the application - two users running reports at the same time could cause the application to become unresponsive for all other users. Solution
Adding a worker server is a fairly conventional way to scale an application. Essentially, long running jobs are placed on a queue and executed in sequence. The main web server continues operating, taking requests and performing normal operations, while the worker server performs the long running jobs. As each job finishes the worker server communicates back to the web server, which in turn communicates the results of the job to the end user.
Under this model any number of users could run reports - or other long running jobs - without directly impacting any other user. The worker server could have hundreds of jobs sitting in its queue and would eventually process all of them, given enough time. The only perceived impact for a user interacting with the system while a number of jobs are being executed is that their own queued jobs would take a bit longer. Costs
Adding a worker server adds $20+GST to monthly operating costs.
Converting existing process to jobs that can be consumed by the worker process is a separate activity, with separate costs. A suggested schedule of work is as follows:
- Outgoing emails (e.g. sign up confirmation, password changes, invitations) $100+GST
- Generate reports (per Reports page) $500+GST
- Import Comments, Organisations $400+GST
NB there is no requirement to do any of these in any particular order - or at all for that matter. This proposal acts as a placeholder for work that may be done to manage the risk around potential performance issues.
In any case, it is recommended that any of this work occur after upgrading to Rails 6 as this version provides improved mechanisms for reporting job execution back to the user interface (via ActionCable).
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ferrisoxide/wicked_software/issues/450, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADFVZOSR4OIPAQLJ66ZSMKLRXCIAZANCNFSM4OAOAPEQ .
ferrisoxide
Problem
Wicked is currently running on a single app server. Long running process (e.g. running reports, or importing data) have the potential to block operations, causing the application to "hang". It is relatively easy to block the application - two users running reports at the same time could cause the application to become unresponsive for all other users.
Solution
Adding a worker server is a fairly conventional way to scale an application. Essentially, long running jobs are placed on a queue and executed in sequence. The main web server continues operating, taking requests and performing normal operations, while the worker server performs the long running jobs. As each job finishes the worker server communicates back to the web server, which in turn communicates the results of the job to the end user.
Under this model any number of users could run reports - or other long running jobs - without directly impacting any other user. The worker server could have hundreds of jobs sitting in its queue and would eventually process all of them, given enough time. The only perceived impact for a user interacting with the system while a number of jobs are being executed is that their own queued jobs would take a bit longer.
Costs
Adding a worker server adds $20+GST to monthly operating costs.
Converting existing process to jobs that can be consumed by the worker process is a separate activity, with separate costs. A suggested schedule of work is as follows:
NB there is no requirement to do any of these in any particular order - or at all for that matter. This proposal acts as a placeholder for work that may be done to manage the risk around potential performance issues.
In any case, it is recommended that any of this work occur after upgrading to Rails 6 as this version provides improved mechanisms for reporting job execution back to the user interface (via ActionCable).