Proper setup in project

[webdpro]

Hey everyone,

Have a question in regards to the proper setup and use.

Now, the docs have a basic setup when you create a 'new' instance of piscina with the 'worker' file you want to have executed.

My question is, in a production environment, say on a 'route' would you create a 'new' instance every time or is it more performant to have this in a module, then use that in the route?

For example, a module that contains the 'new instance' and exports that, then in the route just call the 'run' OR is it better to create the 'new' instance in the actual route itself, however I'm not sure if doing that would me a new 'thread' for each new item, that could get costly I would assume.

So the use-case we have is that we have routes that make DB calls, then run some code with the results to return those objects, while the DB execution is not blocking, the manipulation of data is, again its not slow, but if multiple people are hitting at once, those cycles can add up, hence the worker thread.

Really, the question revolves around how best to set this up though :D

Thanks for any help you can provide.

[metcoder95]

Hi @webdpro, nice question btw.

In this case we need to be conscious of what Piscina does under the hood. As the name states, an instance of Piscina creates a pool (with a customizable size) of Worker Threads that will distribute the load of tasks (high-level explanation).

Then, moving to back to your question, if you have an implementation where on every request you create a new Piscina instance, you’ll be creating N^T number of threads, where N is the number of incoming requests and T is the number of Threads that you told Piscina to instantiate. Which, just by looking at this we can perceive that its a huge overload to the service.

The best in this case is to create a single Piscina instance that is shared across the lifetime of the Service (of course assuming your server is stateless). You can prepare and instantiate the Piscina instance before starting to receive incoming requests so your Pool is ready to handle tasks beforehand.

From an architectural side, an even better approach is to totally offload this expensive tasks to a secondary service by using some sort of asynchronous communication protocol, so your front-end server can continue receive incoming requests as needed meanwhile processing async the expensive data task.

Hope it solves your question 🙂

[webdpro]

Thanks for that, that really does help understand it a bit more :D

Just a follow up question, so if I'm understanding correctly if I created a module for the 'worker' that would technically 'create' the pool for 'said' worker, then in my route, if I simply did the 'run' it should be working off the same pool for each right?

Now, with that said, I had tested that flow out but noticed a big performance hit. What I observed when doing that was

Request 1 took 7 seconds (this is purposful RN to simulate slowness)
Request 2 took 14 seconds
Request 3, 21 seconds etc.

The odd part was that this is just off one request, so I hit it once, took 7, then reloaded the page and it took 14, almost like it was running it multiple times?

Now, with that being said, I may have set that up incorrectly and that totally could have caused the problem there.

A secondary question too, is right now the pool uses a 'single' worker file, what if you had a scenario where you wanted to place many tasks onto a worker, you simply do it like

piscina.run({ a: 4, b: 6 }, { name: 'add' }), and have each 'function' broken out in one large file?

As it stands right now, each 'app' is running in a container, breaking all those calls out to another service would be a big task :D Realistically speaking though, they are not 'that' bad, most run under 100 MS, but if you get slammed with request, you can see how that will build up quickly.

Thank you for the response though, I really appreciate it.

[webdpro]

Just to follow up with this a bit more..

So I think my setup must have been off in some way because I was able to get things working on my end.

I will say though, the docs on using multiple functions in a single worker file probably could use some help :D I was having a bit of a hard time getting that to work as its not really clear that the functions need to be pass as one and not exported individually..

Further to this, I have found that, for my purposes anyhow it seems simpler to just have conditional code inside the WT.

For example, passing data to the worker like

wt.run({
type: "myCondition",
data: {
data: : "data1",
data1 : "data2"
}).then( item =>{

})

For me, this seems to work best as it allows my single file to be extended to do multiple things while using the same worker.