[IIS7][.NET] Website overschakelen naar CDN

[NLAnaconda]

Beste Tweakers,

Voor mijn website wil ik gebruik maken van een Content Delivery Netword (CDN77.com).
Nu moet ik de locatie van elk statisch object wat ik gebruik wil laten maken van het CDN wijzigen van bijvoorbeeld:

code:

http://www.[domeinnaam].nl/image/image.jpg

naar:

code:

http://cdn.[domeinnaam].nl/image/image.jpg

Nu refereer ik op mijn pagina's naar "/image/image.jpg" en het is dus niet te doen om elke afbeelding op te sporen en te wijzigen naar "http://cdn.[domeinnaam].nl/image/image.jpg"

Dus ik dacht, ik maak in IIS7/web.config een redirect rule:

code:

       <rule name="CDN" stopProcessing="true">
          <match url=".*" />
          <conditions trackAllCaptures="false">
            <add input="{URL}" pattern="(\.js|\.css|\.jpg|\.png|\.gif)$" />
            <add input="{CACHE_URL}" pattern="^(https?)://" />
            <add input="##{C:1}##{HTTP_HOST}" pattern="##(.+)##(www)\.(.+)" />
          </conditions>
          <action type="Redirect" url="{C:1}://cdn.[domeinnaam].nl/{R:0}" redirectType="Found" />
        </rule>

Dit werkt prima, elke object gedefinieerd in de regex wordt geladen vanaf het CDN. Maar toch vraag ik mij af hoe effectief dit is. In de broncode wordt namelijk nog steeds gerefereerd naar mijn "www" domein.

Pas als de client de afbeelding op wil vragen wordt deze doorgestuurd naar het CDN.
Er is dus nog steeds een route af te leggen naar mijn eigen server voordat de client weet dat het de content moet halen bij het CDN.

Klopt het dat dit niet effectief is of is de request van de redirect zo klein dat het niet uitmaakt?
Zijn er andere betrouwbare mogelijkheden om dit te bewerkstelligen?

[Verwijderd]

Dat ligt geheel aan je volume, maar aangezien je gebruik gaat maken van een CDN zal dit meer dan gemiddeld zijn.

Het voordeel van een CDN is niet alleen dat je content wordt geleverd vanaf de kortste route naar de visitor, maar ook dat je browser parallel connecties kan openen doordat je content vanaf meerdere lokaties serveert. Met je rewrite rule doe je dat in beginsel al teniet want je rewrite niet de geserveerde content maar de request.

De spec gaat nog uit van 2 connecties, maar in de praktijk volgen de browsers deze niet.
http://www.w3.org/Protoco...fc2616-sec8.html#sec8.1.4

Niet geheel recente lijst maar voor de beeldvorming:
IE 6 and 7: 2
IE 8: 6
IE 9: 6
IE 10: 8
Firefox 2: 2
Firefox 3: 6
Firefox 4 to 17: 6
Opera 9.63: 4
Opera 10: 8
Opera 11 and 12: 6
Chrome 1 and 2: 6
Chrome 3: 4
Chrome 4 to 23: 6
Safari 3 and 4: 4

[ Voor 6% gewijzigd door Verwijderd op 28-02-2014 13:18 ]

[MrTinux]

NLAnaconda schreef op vrijdag 28 februari 2014 @ 12:48:
Klopt het dat dit niet effectief is of is de request van de redirect zo klein dat het niet uitmaakt?
Zijn er andere betrouwbare mogelijkheden om dit te bewerkstelligen?

In zekere zin klopt dat. Een redirect-response is weliswaar kleiner dan (de meeste) content, maar je zegt wel tegen de browser dat-ie elders moet gaan kijken. Vervolgens moet de browser dus een nieuw request sturen, naar je CDN. Het versturen van een request (incl opbouwen verbinding, wachten op response, etc.) kost relatief veel tijd.

Daarmee ontlast je je www-server wellicht van datatransfer, maar je blijft met veel inkomende connecties zitten en de client heeft extra tijd nodig wegens het verwerken van de redirects.

Nog een tip: als je cookies gebruikt die ook meegaan op subdomeinen, host je CDN dan onder een apart domein (dus niet www.mijndomein.nl en cdn.mijndomein.nl maar bijv www.mijndomein.nl en www.mijndomeincdn.nl). Zo voorkom je dat de cookies ook naar het CDN worden gestuurd, waardoor de requests weer kleiner worden (scheelt data voor de client en minder inkomende data op je CDN-server). Kleine beetjes, maar alles helpt

[AtleX]

In plaats van één request voor een plaatje heb je er nu twee, wat op mobiel zomaar een paar honderd miliseconden per plaatje extra kan duren. Ook heb je nu geen potentieel voordeel meer van parallel loading, al was dat voordeel toch al klein omdat je geen apart domein gebruikt voor je CDN.

[NLAnaconda]

Verwijderd schreef op vrijdag 28 februari 2014 @ 13:17:
Dat ligt geheel aan je volume, maar aangezien je gebruik gaat maken van een CDN zal dit meer dan gemiddeld zijn.

Nee ik heb niet zozeer een extreem groot volume, ik heb een website voor reizigers die door de wereld verspreid zitten. Het gaat niet zozeer om mijn eigen server minder te belasten. Die kan alles wel aan, maar het is meer dat ik mensen in Nieuw Zeeland afbeeldingen wil laten laden uit Sydney ipv Amserdam.

Voor de rest, bedankt voor de tips. Ik ben er veel wijzer van geworden.

MrTinux schreef op vrijdag 28 februari 2014 @ 13:26:
Nog een tip: als je cookies gebruikt die ook meegaan op subdomeinen, host je CDN dan onder een apart domein (dus niet www.mijndomein.nl en cdn.mijndomein.nl maar bijv www.mijndomein.nl en www.mijndomeincdn.nl). Zo voorkom je dat de cookies ook naar het CDN worden gestuurd, waardoor de requests weer kleiner worden (scheelt data voor de client en minder inkomende data op je CDN-server). Kleine beetjes, maar alles helpt

Dit kan ik wel doen maar ziet Google mijn afbeeldingen dan niet als zijnde van een ander domein ipv mijn website domein?

Ik weet nu de problemen maar heeft iemand een oplossing hoe ik dit het beste kan implementeren?
Heeft IIS hier geen andere oplossing voor?

[HuHu]

Wellicht is het ook handig om, langzaam maar zeker, je code aan te gaan passen om alles naar het specifieke domein te laten verwijzen. Met een simpele search in je broncode moet je alles waar "/image/" in staat eenvoudig kunnen vinden.

In PHP heb ik het ooit zo gedaan:

PHP:

<a href="<?php echo $this->baseURL(); ?>/link.html">linkje</a>
<img src="<?php echo $this->imageURL(); ?>/plaatje.jpg" />
<script src="<?php echo $this->scriptURL(); ?>/script.js" />

Dan kun je daarna eenvoudig verschillende dingen van verschillende domeinen serveren.

[NLAnaconda]

HuHu schreef op vrijdag 28 februari 2014 @ 14:35:
Wellicht is het ook handig om, langzaam maar zeker, je code aan te gaan passen om alles naar het specifieke domein te laten verwijzen. Met een simpele search in je broncode moet je alles waar "/image/" in staat eenvoudig kunnen vinden.

In PHP heb ik het ooit zo gedaan:

PHP:

<a href="<?php echo $this->baseURL(); ?>/link.html">linkje</a>
<img src="<?php echo $this->imageURL(); ?>/plaatje.jpg" />
<script src="<?php echo $this->scriptURL(); ?>/script.js" />

Dan kun je daarna eenvoudig verschillende dingen van verschillende domeinen serveren.

Ja ik ben bang dat dat wel de oplossing moet gaan worden. Maar als je 20 afbeeldingen hebt op een pagina dan loop je toch ook tegen het parallel download probleem aan?

[Foamy]

Wat jij wilt is geen inbound rewrite rule, maar outbound:

code:

<rewrite>
    <outboundRules>
        <rule name="CDN" preCondition="CheckHTML" stopProcessing="false">
            <match filterByTags="Img" pattern="(https?:\/\/www.(.*)\.(jpg|png))" />
            <action type="Rewrite" value="http://cdn.{R:2}.{R:3}" />
        </rule>
        <preConditions>
            <preCondition name="CheckHTML">
                <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
            </preCondition>
        </preConditions>
    </outboundRules>
</rewrite>

Hiermee herschrijf je alles dat aan de client gestuurd word, inclusief de gebruikte url's.

[NLAnaconda]

Foamy schreef op vrijdag 28 februari 2014 @ 15:49:
Wat jij wilt is geen inbound rewrite rule, maar outbound:

code:

<rewrite>
    <outboundRules>
        <rule name="CDN" preCondition="CheckHTML" stopProcessing="false">
            <match filterByTags="Img" pattern="(https?:\/\/www.(.*)\.(jpg|png))" />
            <action type="Rewrite" value="http://cdn.{R:2}.{R:3}" />
        </rule>
        <preConditions>
            <preCondition name="CheckHTML">
                <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
            </preCondition>
        </preConditions>
    </outboundRules>
</rewrite>

Hiermee herschrijf je alles dat aan de client gestuurd word, inclusief de gebruikte url's.

Bedankt! Voor een fulltime prutser ben je een held als dit werkt Ik ga het proberen.

[Foamy]

Bij mij heeft het gewoon gewerkt. Het kan wel zijn dat je nog wat compressie moet uitschakelen, omdat ie anders je content niet goed kan lezen bedenk ik me nu

[HuHu]

NLAnaconda schreef op vrijdag 28 februari 2014 @ 14:42:
[...]


Ja ik ben bang dat dat wel de oplossing moet gaan worden. Maar als je 20 afbeeldingen hebt op een pagina dan loop je toch ook tegen het parallel download probleem aan?

Hoe dacht je dat anders op te lossen dan? Ook met een CDN heb je daar last van. Wat je nog wel kunt doen is html, images, scripts en css van verschillende domeinen serveren. Maar als je 20 dingen van één domein haalt (maakt niet uit welke), dan heb je daar altijd last van. Maar dat is toch ook niet erg? Het idee is dat een CDN veel sneller statische content kan serveren en onafhankelijk van de overige onderdelen van je pagina.

[NLAnaconda]

HuHu schreef op vrijdag 28 februari 2014 @ 16:54:
[...]

Hoe dacht je dat anders op te lossen dan? Ook met een CDN heb je daar last van. Wat je nog wel kunt doen is html, images, scripts en css van verschillende domeinen serveren. Maar als je 20 dingen van één domein haalt (maakt niet uit welke), dan heb je daar altijd last van. Maar dat is toch ook niet erg? Het idee is dat een CDN veel sneller statische content kan serveren en onafhankelijk van de overige onderdelen van je pagina.

Ik heb er zelf geen oplossing voor maar omdat Gordijnstok het aanhaalde dacht ik dat er ook een oplossing voor moest zijn.

Verwijderd schreef op vrijdag 28 februari 2014 @ 13:17:
Het voordeel van een CDN is [..] dat je browser parallel connecties kan openen doordat je content vanaf meerdere lokaties serveert.

[HuHu]

NLAnaconda schreef op vrijdag 28 februari 2014 @ 17:02:
[...]


Ik heb er zelf geen oplossing voor maar omdat Gordijnstok het aanhaalde dacht ik dat er ook een oplossing voor moest zijn.

[...]

Maar dat gaat alleen op als de content ook daadwerkelijk van verschillende domeinen komt. Bijvoorbeeld de html en scripts van je hoofddomein en afbeeldingen van het CDN. Als een browser 6 connecties per domein maakt, dan kan je er met een CDN erbij dus 12 gebruiken. Maar dan moet de content wel verspreid zijn over de domeinen.

Maar een CDN heeft natuurlijk meer voordelen dan alleen dat.

[Verwijderd]

NLAnaconda schreef op vrijdag 28 februari 2014 @ 12:48:

code:

http://www.[domeinnaam].nl/image/image.jpg

naar:

code:

http://cdn.[domeinnaam].nl/image/image.jpg

Nu refereer ik op mijn pagina's naar "/image/image.jpg" en het is dus niet te doen om elke afbeelding op te sporen en te wijzigen naar "http://cdn.[domeinnaam].nl/image/image.jpg"

NLAnaconda schreef op vrijdag 28 februari 2014 @ 12:48:
Klopt het dat dit niet effectief is of is de request van de redirect zo klein dat het niet uitmaakt?
Zijn er andere betrouwbare mogelijkheden om dit te bewerkstelligen?

Dit is inderdaad niet effectief. Maar dan om de volgende reden...
Al je hyperlinks (naar je eigen content) kunnen problemen opleveren indien de ASP.NET Cookieless feature (automatisch) geactiveerd wordt.

Understand How the ASP.NET Cookieless Feature Works

Je vermeld niet welk asp.net framework je gebruikt. (asp.net classic, mvc, mvc 4 razor, etc.)

Je gebruikt nu de volgende referentie "/image/image.jpg", "/pagina/pagina1.aspx"
Daar begint het probleem. Dit moet zijn. Url.Content("~/image/image.jpg"), Url.Content("~/pagina/pagina1.aspx")
Met de MVC4 razor engine is het zelfs niet nodig om expliciet Url.Content aan te roepen, dit gebeurt automatisch.

Het eerste advies is dus al je hyperlinks correct door de Url.Content laten gaan.
Daarna kun je de Url.Content vervangen door een helper functie die je links kan omvormen naar je cdn hyperlink.

Code voor een complete implementatie:
ASP.NET MVC CDN UrlHelper

[R4gnax]

Verwijderd schreef op zaterdag 01 maart 2014 @ 20:05:
Dit is inderdaad niet effectief. Maar dan om de volgende reden...
Al je hyperlinks (naar je eigen content) kunnen problemen opleveren indien de ASP.NET Cookieless feature (automatisch) geactiveerd wordt.

Understand How the ASP.NET Cookieless Feature Works

Cookieless sessions en authentication hoor je sowieso niet meer te gebruiken.

HuHu schreef op vrijdag 28 februari 2014 @ 16:54:
[...]

Hoe dacht je dat anders op te lossen dan? Ook met een CDN heb je daar last van. Wat je nog wel kunt doen is html, images, scripts en css van verschillende domeinen serveren. Maar als je 20 dingen van één domein haalt (maakt niet uit welke), dan heb je daar altijd last van. Maar dat is toch ook niet erg? Het idee is dat een CDN veel sneller statische content kan serveren en onafhankelijk van de overige onderdelen van je pagina.

Het is slimmer om je HTML en CSS op hetzelfde domein te houden. Eigenlijk alles wat blocking gedownload wordt. (Dus als je niet van een script loader gebruikt maakt die non-blocking downloads faciliteert, ook je JavaScript files.) Daarmee vermijdt je namelijk de extra DNS lookups die, als je CSS en JS toch al netjes gemerged en geminified neer zet, in de regel zwaarder gaan wegen dan de winst in parallelisatie.

(De grootste winst voor een CDN zit hem trouwens niet zo zeer in parallelisatie, hoewel dat wel helpt, maar in geo-distributie; zo kort mogelijke lijntjes.)