As Mithun suggested, it's going to be slow regardless of which web server option you choose.
It depends on your application, but if it's a user-facing web application, one way would be to have your client application make an API call to your backend, the backend enqueues the job in the queue, the queue worker/consumer does the work and puts the result in a result store, and your application front-end either asynchronously polls (using Javascript) or has a refresh button that lets the user check for their predictions/recommendations. Or if you don't want to use the job queue, 100-500ms isn't too bad to just do an AJAX call from the front-end to your Mod_perl API backend. Have your web page load quickly, then do the slow work asynchronously (one way or another). That's how most modern user-facing web apps work, and it works pretty well. If your app isn't human-facing, then I don't see why a little delay would be a problem? David Cook -----Original Message----- From: Wesley Peng <m...@yonghua.org> Sent: Wednesday, 5 August 2020 11:46 AM To: modperl@perl.apache.org Subject: Re: Question about deployment of math computing Hi Mithun Bhattacharya wrote: > Do you really need a webserver which is providing a blocking service ? yes, this is a prediction server, which would be deployed in PROD environment, the client application would request the prediction server for results as scores. You can think it as online recommendation systems. regards.
signature.asc
Description: PGP signature
