I’m doing some benchmark of a Solid-based application (not just a regular Solid App, if that matters), and created dummy data on solidcommunity.net. The dummy data consists of hundres of files/resources. Each file is very small, usually tens of bytes.
To be clear: the benchmark is not aimed to benchmark solidcommunity.net, but my application (it’s computation intensive). That’s why the dummy data is small.
The application will do request to my Pod on solidcommunity.net , to fetch the data (through JS, authenticated using solid-node-client). Because it’s a benchmark, there will be lots of requests in a short time-span; after that, it will do processing, generally for minutes; it will then restart the process for a few rounds.
After increasing the number of files to a few hundreds, I’m experiencing some errors of socket being closed due to server connection reset. I guess this is because solidcommunity.net has some restrictions – either by the server admin or the implementation (NSS). May I get an rough idea on what the restriction possibly is?
I guess this is mainly due to NSS? Because the request is not really as fast as I would expect. In the preparation part of my application, I usually only get ~4 files per second, using Comunica to query.
Currently I’m limiting my simultaneous requests, and this seem to be resolved. But I’d prefer to stay on the safe side in case being classified as malicious
If the simultaneous request is not really a problem, I’d prefer to return to original plan (though if the error is still there, I can’t…).
Thanks. Just to clarify: the benchmark is to benchmark my application (which is computation intensive), not the Solid server. I’m storing data in the Pod as the data (and configuration) source, but nothing more.
If it is tens of thousands or even millions, indeed that’s possible. But hundreds doesn’t sounds like very large to my mind… Though, I don’t have that much public-facing server maintenance experience, so my intuition may be totally wrong.
Thanks. I do have a CSS instance, but I got some issues (related to CSS) previously, so I reverted to using the public NSS service. But maybe I need to look into that if situation is not resolvable…
Me neither. My idea was that if the errors are related to too much traffic (which sounds like it as it happened because of increasing the traffic), then it’s likely too much for the server. But I don’t know what the server limits are and where the origin of this is, that’s up to the maintainers.
If the problem is CSS related you could still try to run NSS locally. From my experience it was more effort to setup NSS compared to CSS, but still doable within a reasonable amount of time.