I can see that all big sites store the images on a complete different server. What are the benefits of this practice?
Load balancing.
Separation of dynamic and static content.
Static content is served from servers which are geographically (or in network "length") close to the client.
(Update) forgot to mention that browsers used to limit the number of concurrent requests to the same server or domain (don't know if it's still used) and using different domain names allowed the server to bypass this limitation.
This way each kind of server serves resources it's tuned up for so clients get pages faster.
This way, the browser won't send cookies when requesting images.
It also enables the use of location-aware CDNs for images only.
Related
I have a hosted webserver with http/2 (medium fast) and additionally I have a space on a fast CDN-Server with only http/1.1.
Is it recommended to load some ressources from the CDN or should I use only the webserver because of http/2?
Loading too many recources from the CDN could be a bottleneck due to http/1.1?
Would be kind to get some hints...
You need to test. It really depends on your app, your users and your servers.
Under HTTP/1.1 you are limited to 6 connections to a domain. So hosting content on a separate domain (e.g. static.example.com) or loading from a CDN was a way to increase that limit beyond 6. These separate domains are also often cookie-less as they are on separate domains which is good for performance and security. And finally if loading jQuery from code.jquery.com then you might benefit from the user already having downloaded it for another site so save that download completely (though with the number of versions of libraries and CDNs the chance of having a commonly used library already downloaded and in the browser cache is questionable in my opinion).
However separate domains requires setting up a separate connection. Which means a DNS lookup, a TCP connection and usually an HTTPS handshake too. This all takes time and especially if downloading just one asset (e.g. jQuery) then those can often eat up any benefits from having the assets hosted on a separate site! This is in fact why browsers limit the connections to 6 - there was a diminishing rate of return in increasing it beyond that. I've questioned the value of sharded domains for a while because of this and people shouldn't just assume that they will be faster.
HTTP/2 aims to solve the need for separate domains (aka sharded domains) by removing the need for separate connections by allowing multiplexing, thereby effectively removing the limit of 6 "connections", but without the downsides of separate connections. They also allow HTTP header compression, reducing the performance downside to sending large cookies back and forth.
So in that sense I would recommended just serving everything from your local server. Not everyone will be on HTTP/2 of course but the support is incredible strong so most users should.
However, the other benefit of a CDN is that they are usually globally distributed. So a user on the other side of the world can connect to a local CDN server, rather than come all the way back to your server. This helps with connection time (as TCP handshake and HTTPS handshake is based on shorter distances) and content can also be cached there. Though if the CDN has to refer back to the origin server for a lot of content then there is still a lag (though the benefits for the TCP and HTTPS setup are still there).
So in that sense I would advise to use a CDN. However I would say put all the content through this CDN rather than just some of it as you are suggesting, but you are right HTTP/1.1 could limit the usefulness of that. That's weird those as most commercial CDNs support HTTP/2, and you also say you have a "CDN server" (rather than a network of servers - plural) so maybe you mean a static domain, rather than a true CDN?
Either way it all comes down to testing as, as stated at the beginning of this answer it really depends on your app, your users and your servers and there is no one true, definite answer here.
Hopefully that gives you some idea of the things to consider. If you want to know more, because Stack Overflow really isn't the place for some of this and this answer is already long enough, then I've just written a book which spends large parts discussing all this: https://www.manning.com/books/http2-in-action
Sorry for such a question, but I can not find any article on the web with cons on that, I guess it is about async uploading and downloading, but it's just a guess, is there somewhere a detailed info?
It's mostly about specialization, data locality, and concurrency.
Servers that are specialized at serving static content typically do so much faster than dynamic web servers (the web servers are optimized for the specific use-case).
You also have the advantage of storing your content in many zones to achieve better performance (the content is physically closer to the person requesting it), where-as web applications typically should be near its other dependencies, such as databases.
Lastly browsers (for http/1 at least) only allow a fixed number of connections per server, so if your images and api calls are on separate servers, one cannot influence the other in terms of request scheduling.
There are a lot of other reasons I'm sure, but these are just off the top of my head.
What is the preferred way of serving static files for an application that is deployed in a microservices architecture (in production)?
Let's say for simplicity that I have 3 application servers and one load-balancer that forwards requests to these servers.
Should the load-balancer store the files and serve them imminently upon request? OR..
Should the load-balancer forward static files requests to the different application instances (each request to a different instance)?
Is there a best practice for this?
As stated in other comments/answers, there are a lot of ways to handle this. This largely depends on what you actually need (version control, access control, http headers, CDN).
Specifically to your question, if it was me, I wouldn't deploy these files on the load balancers, because a newer version of the static files would require a downtime on the load balancers. Instead, I would build very simple Nginx/Caddy containers that their sole purpose is to serve these files, and have the LB route the traffic to those containers.
Best practice would be to store it in a service meant for static content like blob storage (in the cloud this would be Azure Storage, S3, etc.). If necessary, leverage a CDN to improvement latency and throughput to end users.
But as someone else commented, there are many ways to handle this depending on your particular requirements.
I've made a website for an arts organisation. The website allows people to browse a database of artists' work. The database is large and the image files for the artists' work come to about 150Gb. I have my own server that is currently just being used to keep the images on its hard-drive.
I'm going to purchase hosting so I don't have to worry about bandwidth etc... but would it be better to purchase hosting that allows me to upload my entire image database or should I use the website to get the images from my server? If so how would I do that?
Sorry I am very new to this
I think it could be better to have the data on the same server so you avoid calls to another server for images which are quite big as you say and this can slow you down overall.
I assume you will need to set up some API on your server to deliver the images or at least URLs for them but then you must make sure they are accessible.
You'll want the image files on the same server as your website, as requests elsewhere to pull in images will definitely hinder your site's performance - especially if you have large files.
Looking at large size of database and consideration of bandwidth, dedicated server will be suitable as they includes large disk spaces and bandwidth. You can install webserver as well as database server on same server inspite of managing them separately. Managing database backups and service monitoring becomes much more easier.
For an instance, you can review dedicated server configuration and resources here :- https://www.accuwebhosting.com/dedicated-servers
What is the benefits of seperating css,js and media folders under subdomains like
css.domain-name.com
js.domain-name.com
media.domain-name.com
I know that scalibilty begin from static/media files but does serving them from subdomain has any advantage ?
If so, in which degree should I do that ? For example, if I allowed to photo uploads, should I put my "uploads" folder under media subdomain ?
Thanks
I'd separate uploads from static files used in the generic layout (e.g. logos, icons, etc.) so its a lot easier to clear the existing files to upload a new design without having to care for the uploads to not be deleted/overwritten.
As for the domain names, I wouldn't split the files that way. One sub domain for static files, one for uploads - fine. But I wouldn't go as far as adding one for scripts or stylesheets.
Using sub domains can have advantages though, depending on the web server you can configure the whole virtual host to adhere to specific rules, e.g. not providing directory listings or not allowing access to any files other than images - or refusing to deliver hotlinked files (without having to worry about specific sub directories). It can as well make it easier to move the files to another host later on, e.g. for media files or downloads to a cloud hosting service.
Considering your example I'd use the following sub domains:
www.domain-name.com (basic web presence)
static.domain-name.com or media.domain-name.com (serving support files like js, css, images, etc. - stuff that doesn't change and can be cached for a long time)
uploads.domani-name.com (serving uploaded files)
Don't overcomplicate it as you're not gaining any additional performance that way (unless utilizing different servers and you're expecting heavy load). In fact page load might be slower (due to additional DNS lookups) and you might encounter security limitations, e.g. regarding cookie validity/accessibility or cross domain scripting.
There are mainly two reasons for doing this
Scaling - static content and dynamic content has other scaling parameters. The more you may differ between webservers serving dynamic and static contents. Based on this you may scale different based on your websites requirements. E.g if you host a photo site you will end up having 10times more static servers than dynamic sites. Static servers are usually much more lightweight than full featured application servers.
Cookies - Cookies are always sent to the domain they are assigned to. So cookies will be sent to e.g. www.xyz.com and not to sub.xyz.com
Probably it makes no sense to go more into detail than static[1-n].xyz.com. But that really depends on what you want to do.
To you "upload" folder question. Preferable the images uploaded to your main domain will be served by a static server (serving contents on your subdomain).
For JS, this seems like a bad idea. There are security restrictions to what you can do using JS when dealing with a different domain, which would be the case here.
For media files and downloads, basically BLOB storage, the story is a bit different. For high-traffic sites, it may be required to separate this in order to create a good load-balancing structure and to avoid putting unnecessary load on the web application servers (the media subdomain can point to different servers, thus reducing the load on the app servers while allowing to create massive load balancing for just the binary data serving).