Server can not take 10 request /second when upload 1.3GB ifc file

[RyugaRyuzaki]

First time i upload a 1.3gb ifc file(i used Postman), it's ok ("conversion start") then after that i continue upload a same size file, and server takes a long time to response, after (5minutes) here

[RyugaRyuzaki]

Update I try test 3 times

autocannon -c 10 -d 10 -m POST  http://localhost:3000/api/models --form '{"file":{"type":"file","path":"E:/Ryuga/IFCModel/BowerBI.ifc"}}'

I try to use autocannon for test.

┌─────────┬─────────┬─────────┬─────────┬─────────┬────────────┬───────────┬─────────┐
│ Stat    │ 2.5%    │ 50%     │ 97.5%   │ 99%     │ Avg        │ Stdev     │ Max     │
├─────────┼─────────┼─────────┼─────────┼─────────┼────────────┼───────────┼─────────┤
│ Latency │ 1091 ms │ 1160 ms │ 1442 ms │ 1519 ms │ 1190.94 ms │ 134.26 ms │ 1519 ms │
└─────────┴─────────┴─────────┴─────────┴─────────┴────────────┴───────────┴─────────┘
┌───────────┬───────┬───────┬─────────┬─────────┬─────────┬─────────┬───────┐
│ Stat      │ 1%    │ 2.5%  │ 50%     │ 97.5%   │ Avg     │ Stdev   │ Min   
│
├───────────┼───────┼───────┼─────────┼─────────┼─────────┼─────────┼───────┤
│ Req/Sec   │ 1     │ 1     │ 10      │ 10      │ 8.1     │ 2.95    │ 1     
│
├───────────┼───────┼───────┼─────────┼─────────┼─────────┼─────────┼───────┤
│ Bytes/Sec │ 353 B │ 353 B │ 3.53 kB │ 3.53 kB │ 2.86 kB │ 1.04 kB │ 353 B 
│
└───────────┴───────┴───────┴─────────┴─────────┴─────────┴─────────┴───────┘

Req/Bytes counts sampled once per second.
# of samples: 10

91 requests in 10.3s, 28.6 kB read

It seems server will down

[RyugaRyuzaki]

I suggest we can use worker_threads . We throw this to 2 worker_threads , 1 for geometry, property for another (or child_process). If we 're in dev we don't need to check clustter, but in production (containerized) we have to check if cluster is mainthread or not then we can set the cluster of 2 threads

[kitsunekyo]

yeah this is not at all production ready yet and just an example. for perf optimization and handling multiple concurrent requests there's a lot of work to be done.

first response on my 1.7gb ifc model is 15s LOCALLY, which would be completely unusable for production. in that case you might even need to stream the model to the server first.

since the node process for the tiler takes a massive amount of cpu load, I'm unsure whether concurrent conversion is even possible at all, in the libraries current form.

[kitsunekyo]

@RyugaRyuzaki your worker threads idea is great. feel free to submit a PR.

[RyugaRyuzaki]

@RyugaRyuzaki your worker threads idea is great. feel free to submit a PR.

Well, if in a development environment, implementing worker_threads will not be difficult because we can monitor the RAM of our machine. But in terms of staging and production, it will be extremely complicated. I will take one example. Suppose in 1 second there will be 100 requests, each request will upload 1GB, so that means our server's RAM will have to have at least 120-150GB. This is a waste of resources. Another solution is that we will use kubenetes(k8s) to do this. We run the first instance (each instance will have about 32gb of RAM), check to see if that instance exceeds the allowed RAM, immediately use k8s to launch the next instance, and so on, if any instance It's hard not to worry so we will destroy it.