rejetto / hfs2

web based file server
https://rejetto.com/hfs
GNU General Public License v3.0
601 stars 131 forks source link

Unable to process a large number of requests #5

Open cocos56 opened 3 years ago

cocos56 commented 3 years ago

We can test this on Linux using the following command:

ab -n 20000 -c 20 http://1.coco56.top/%E5%A4%A7%E5%9E%8B%E8%BD%AF%E4%BB%B6/

image

image

image

cocos56 commented 3 years ago

This does not happen on IIS image

rejetto commented 3 years ago

if you are concerned about that "busy" message, it will appear after just 1 request from the same IP, because you are requesting folders (not files) and that's by design with 2.4. HFS is not a high-performance server but if you are interested in benchmarks you can try requesting a file. Cosnider that if you generate more log like i see in your screenshot you will also use more cpu.

cocos56 commented 3 years ago

I use ab -n 20000 -c 64 http://1.coco56.top/robots.txt in Ununtu to request robots.txt file.

But HFS use a lot of ports, I think one port is enough. Too many ports also make it impossible to handle a large number of requests. image

image

image

cocos56 commented 3 years ago

The port changes every time I make a request.

rejetto commented 3 years ago

You misunderstood what that specific port is: it is the client's port. This is how TCP works, and it is true for every TCP server, even if most programs won't show you, because you normally don't need to know. The server port is only one, and HFS is not even able at the moment to have more than one.

cocos56 commented 3 years ago

When HFS sends 409, what's the time of Retry-After ? And why the client sends a large number of requests consecutively in a very short period of time ? image image

mrp8ge8 commented 3 years ago

When HFS sends 409, what's the time of Retry-After ? And why the client sends a large number of requests consecutively in a very short period of time ? image image

静态文件,用Nginx更牛B。打算做文件床的话,用Nginx,Apache Http都行啊,非得来折腾这个

rejetto commented 3 years ago

The time communicated is random in the range 1-3 seconds. The http header used is not retry-after but "refresh", but I guess retry-after could even be better, and we may have both just to be sure that more clients will understand. Thanks for pointing it out. About the "why the client..." question, you should probably ask to whoever made the client, i have no idea.