Depends on your server's hardware, it wouldn't collapse. It is not a wormhole, but a machine. It will simply get slow, think of it like having a water pipe with capacity to allow 5 litres of water and you try to get 20 litres of it? Will it collapse? No, it will provide you with 20 litres of water but will take 4 times the actual time required.
Again, the problem you are referring to is a widely ignored problem. 20 images are 20 requests, and that will cause the server to slow down. Ever wondered why? The "why" is the overhead data such as headers and response generation etc. If you create a single connection, establish it and stream the data over it (like sockets), then it won't be a bigger problem. Got the idea?
Now, let me dissect it down into pieces. The only solution here is to cut short the requests, one method I have already told you. You are using a Web Service, create a client and download all images in a single request.
1. Either perform a bulk download.
- In this method, you can create a huge byte array of the data of images, like a JSON notation then convert it to images.
2. ZIP the images, download the archive, open the archive and use them. ZIP would also decrease the size of the images. 1 MB may be 0.95 MB (
save each and every second you can!)
These are just a few of the tips that I can give. Among others, there are many with a great use:
1. Cut short the number of images being streamed down. User is never going to see all 20 images in a snap. He would be watching at most 5, so download 5. Then allow user to click on a button to download next and so on and so forth.
2. Increase the RAM and CPU cores. So that no matter how many requests come, your server
always has a new thread available to handle the request.
- Servers get slow because there are no more processes or threads available to handle the request. Thus slowing down the response time.
- Make sure there are threads available! Either by adding more hardware resources.
3. Consider using
asynchronous programming model[
^]. In this model, most of the work will be done in a background normal thread, so your request handling thread will be left free for other new requests. Asynchronous programming model would be my choice, it doesn't need more hardware, but just a complex model.
HTTP/2[
^] is active nowadays (I am not sure whether as a standard or not but) IIS 10 supports it and most browsers also support HTTP/2. Which provides you with ability to compress headers, perform other features.
But it is not yet implemented, so do not count on this.
Submit an article or tip