static file performance "staircase" pattern

Mon May 11 08:58:17 UTC 2015

It's not a requirement in any way and your SEO might turn out just fine
using different subdomains. My suggestion is not just made up from my
imagination, but advice from a Google employee since this have been a real
problem for us. By serving the same image from multiple subdomains, from
the same page the image can end up in a kind of "limbo" where google can't
decide which image to use.

Also, as I understand it, canonical headers are currently only supported
for web search and not image search from reading this doc
https://support.google.com/webmasters/answer/139066?hl=en .

Again, this might not even be relevant for your case, Dennis :)

~ Nikolaj

On Mon, May 11, 2015 at 9:40 AM Lucas Rolff <lucas at slcoding.com> wrote:

> It's not really required to serve it from the same sub-domain always.
> The most optimal solution would be to add the canonical link header when
> serving using domain sharding.
>
> But from a caching perspective, keeping the sharding consistent is indeed
> beneficial (you can use crc32 on the image name e.g. this will always
> return the same hash, and based on this do the domain sharding), but from a
> SEO perspective, it doesn't matter if you just do it right with canonical
> link.
>
>   Nikolaj Schomacker <sjums07 at gmail.com>
>  11 May 2015 08:49
>
> And a last thing you should be aware of if it applies to your case is SEO.
> Using multiple domains for images is perfectly fine in the eyes of Google,
> but be sure the same images is always served from the same subdomain. Also
> be sure to have all of the subdomains added to the same webmasters account
> as your main site.
>
> ~ Nikolaj
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
>   Lucas Rolff <lucas at slcoding.com>
>  9 May 2015 20:24
>
>  What you should do, to increase the concurrent amount of requests, is to
> use domain-sharding, since as Paul mentioned, browsers have between 4 and 8
> (actually) simultaneous connections per domain, meaning if you introduce
> static1,2,3.domain.com, you will increase your concurrency.
>
> But at same time you also need to be aware, that this can have a negative
> effect on your performance if you put too many domains, there's no golden
> rule on how many you need, it's all a site by site case, and it differs.
> Also take into account your end-users connection can be limiting things
> heavily as well if you put too much concurrency (thus negative effect) - if
> you have a high number of concurrent requests being processed it will slow
> down the download time of each, meaning the perceived performance that the
> user see might get worse because it feels like the page is slower.
>
> - Lucas
>
>   Paul Smith <paul.j.smith0 at gmail.com>
>  9 May 2015 20:03
> On Sat, May 9, 2015 at 11:37 AM, Dennis Jacobfeuerborn
>
> I am not an expert but I believe that most browsers only make between
> 4 to 6 simultaneous connections to a domain. So the first round of
> requests are sent and the response received and then the second round
> go out and are received back and so forth. Doing a search for
> something like "max downloads per domain" may bring you better
> information.
>
> Paul
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>   Dennis Jacobfeuerborn <dennisml at conversis.de>
>  9 May 2015 19:37
> Hi,
> I'm trying to find out how to effectively deliver pages with lots of
> images on a page. Attached you see opening a static html page that
> contains lots of img tags pointing to static images. Please also note
> that all images are cached in the browser (hence the 304 response) so no
> actual data needs to be downloaded.
> All of this is happening on a CentOS 7 system using nginx 1.6.
>
> The question I have is why is it that the responses get increasingly
> longer? There is nothing else happening on that server and I also tried
> various optimizations like keepalive, multi_accept, epoll,
> open_file_cache, etc. but nothing seems to get rid of that "staircase"
> pattern in the image.
>
> Does anybody have an idea what the cause is for this behavior and how to
> improve it?
>
> Regards,
> Dennis
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150511/7d76db65/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1405 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150511/7d76db65/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1295 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150511/7d76db65/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150511/7d76db65/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1295 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150511/7d76db65/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postbox-contact.jpg
Type: image/jpeg
Size: 1405 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150511/7d76db65/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150511/7d76db65/attachment-0005.jpg>