Closed Mossaka closed 2 years ago
It does reuse the module.
Most of the limits we have seen on performance tests are due to file handles open or max network sockets reached.
If module does not have volume mounts, then any given hit should only consume something like 3-4 file descriptors: STDIN, STDOUT, and STDERR, plus a disk hit when the module isn't already loaded.
In some cases, I have seen us hit network limits because requests are in CLOSE_WAIT (and hence consume a socket). So on Linux it might be worthwhile to actually try out some network tuning and see if bumping up max open sockets (or shortening socket wait time) can actually improve this.
Keep in mind that if you are running the benchmark locally, you are consuming both client and server socket instances. So you might need to bump up the max sockets to double what you think you are using.
@Mossaka does the above response answer your question? If so, can we close this ticket?
Thanks for your interest!
@Mossaka does the above response answer your question? If so, can we close this ticket?
Thanks for your interest!
Oh yes you may close it
I was conducting a simple throughput test for WAGI server on local, and here is my module redirect file:
When receving a GET request, WAGI server simply returns "hello world!" to the client.
I did a 10000 repeated hit with 50 threads. However, I found that the performance isn't amazing - about 1000 requests/second. I am thinking the performance was severed by loading the wasm module to memory and copy the result to the socket in the host. Does WAGI do anything particularly for repeated requests, like caching the wasm module in memory?
I was also conjectuing that the number of file descriptors is a bottleneck for WAGI server since each process only allow about 1024 file descriptors.