static file performance "staircase" pattern

Mon May 11 10:45:54 UTC 2015

Content should be accessible from one (and one only) location at any single
time, so be careful to content overlap between subdomains.
Not even talking about SEO, it is just pragmatically logical: no single URI
should be served through different URL if you want your repository to be
seen as 'clean' IMHO.
I like octopuses, as long as the object of the study purely remains the
animal form.

>From SEO prospective, the usual main problem with subdomains is score
dilution: content served from subdomains do not benefit from ranking score
from other domains (including parent). That is however valid for pages, not
resources (I suppose?).

Anyhow, this 'problem' (optimization? constraint? decision?) lies
client-side, not server-side, so this thread on the nginx ML is maybe not
the best location to debate it.
---
*B. R.*

On Mon, May 11, 2015 at 10:58 AM, Nikolaj Schomacker <sjums07 at gmail.com>
wrote:

> 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
>
>
> _______________________________________________
> 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/765c7472/attachment-0001.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/765c7472/attachment-0003.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/765c7472/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/765c7472/attachment-0005.jpg>