Bekijk Volledige Versie : Eén webshop over twee werelddelen
Beste WHT-ers,
Wij zijn momenteel aan het brainstormen over 'het opzetten van' een (wereldwijde) webshop.
Er worden veel geïnteresseerde bezoekers uit Europa en Amerika verwacht.
We kunnen deze webshop op onze eigen servers (in Nederland) hosten, maar ik verwacht dat de laadtijd in Amerika erg hoog is.
En dat is in dit geval 'not done'.
Nu hebben wij de volgende situatie bedacht;
1. We hosten de Europese webshop op een .eu domein en hosten dit op onze servers in Nederland.
2. We schaffen een hosting pakket aan in Amerika en hosten hier het .com domein op.
Echter zitten we dan met het probleem dat de webshops onafhankelijk van elkaar fungeren en dat is niet de bedoeling.
Want de data moet voor beide 'live' hetzelfde zijn.
Omdat ik deze situatie nooit eerder ben tegengekomen, loop ik een beetje vast (ook met zoeken).
Wellicht zijn er hosting partijen die een soort van 'continent based cloud' dienst leveren? Ik weet het niet.
Ik hoop dat jullie mij hiermee verder kunnen helpen.
Met vriendelijke groet,
BReady
Indien je gebruikt maakt van mysql databases zou je eventueel kunnen kijken naar een master/master setup om de gegevens met elkaar live te laten synchroniseren. Images die op de webspace (hd) staan kan je eventueel met rsync of andere oplossing synchroniseren. Of je zou ook op zoek kunnen gaan naar een CDN leverancier die dit allemaal voor je regeld zoals akamai, bitgravity, level3, interoute, ...
dreamhost_nl
24/09/11, 18:02
Het is mede afhankelijk van de prognose van je bezoekers waarvoor je gaat kiezen. Zal 80% uit Europa komen en 20% uit de V.S dan zou je bijv. ook kunnen beginnen met de web site voor beide werelddelen op één locatie te hosten en geleidelijk aan uit kunnen breiden naar twee of meerdere locaties. Indien je in Nederland start zorg dan i.i.g. voor een netwerk met goede/meerdere connecties naar de V.S. en niet slechts een lijntje die richting uit.
Welke data wil je "live" hebben, de producten, of ook orders ed? Producten en layout ed kan je natuurlijk syncen, wil je echt alles live word het al een stukje lastiger
Yourwebhoster
25/09/11, 11:53
Ik zou het lekker bij 1 .com domeinnaam houden, is ook beter voor de naamsbekendsheid. Gebruik geografische DNS servers, een versleutelde VPN verbinding tussen de servers en synchroniseer de data met DRBD en databases met master-to-master replicatie. Ik roep het hier wel simpel, maar het is raadzaam om dit over te laten aan diegenen die hier al mee gewerkt hebben en je daarbij van een goede oplossing kan voorzien. Zo kan een master-to-master replicatie problemen opleveren als je met id's werkt die met auto_increment werken. Hier zijn oplossingen voor maar dit kan je beter bespreken met de persoon of het bedrijf die dit voor je gaat beheren.
Er zijn vele oplossingen mogelijk, CDN is vaak ook al een goede omdat hierbij de CDN leverencier de afbeeldingen css etc zelf van de dichtsbijzijnde server laat laden, het enige trage zou dan de webserver met dynamische content zijn en de vraag is dan welke snelheid is accepteerbaar. Met de webserver op één locatie zou ik wel op zoek gaan naar een netwerk met goede internationale verbindingen.
Indien je gebruikt maakt van mysql databases zou je eventueel kunnen kijken naar een master/master setup om de gegevens met elkaar live te laten synchroniseren. Images die op de webspace (hd) staan kan je eventueel met rsync of andere oplossing synchroniseren. Of je zou ook op zoek kunnen gaan naar een CDN leverancier die dit allemaal voor je regeld zoals akamai, bitgravity, level3, interoute, ...
Over een master/master setup heb ik al nagedacht. Dit wil ik liever voorkomen aangezien mijn ervaring hiermee niet erg goed is. En de data syncen met rsync is niet 'live'.
Ik zal eens kijken naar een CDN leverancier.
Het is mede afhankelijk van de prognose van je bezoekers waarvoor je gaat kiezen. Zal 80% uit Europa komen en 20% uit de V.S dan zou je bijv. ook kunnen beginnen met de web site voor beide werelddelen op één locatie te hosten en geleidelijk aan uit kunnen breiden naar twee of meerdere locaties. Indien je in Nederland start zorg dan i.i.g. voor een netwerk met goede/meerdere connecties naar de V.S. en niet slechts een lijntje die richting uit.
Dat is inderdaad waar, maar het 'probleem' in dit geval is dat de webshop beheert wordt vanuit Europa en Amerika. En indien ik de webshop in bijvoorbeeld Amerika host en de 'Europese' beheerder moet de webshop gaan vullen e.d. dan denk ik dat er veel irritaties gaan ontstaan (wachten, wachten, wachten).
Welke data wil je "live" hebben, de producten, of ook orders ed? Producten en layout ed kan je natuurlijk syncen, wil je echt alles live word het al een stukje lastiger
In principe moet _alles_ live staan inderdaad. Je kunt twee losse webshops gebruiken, maar dan zit je met twee 'boekhoudingen' aangezien beide webshops een eigen 'leven' leiden.
Ik zou het lekker bij 1 .com domeinnaam houden, is ook beter voor de naamsbekendsheid. Gebruik geografische DNS servers, een versleutelde VPN verbinding tussen de servers en synchroniseer de data met DRBD en databases met master-to-master replicatie. Ik roep het hier wel simpel, maar het is raadzaam om dit over te laten aan diegenen die hier al mee gewerkt hebben en je daarbij van een goede oplossing kan voorzien. Zo kan een master-to-master replicatie problemen opleveren als je met id's werkt die met auto_increment werken. Hier zijn oplossingen voor maar dit kan je beter bespreken met de persoon of het bedrijf die dit voor je gaat beheren.
Er zijn vele oplossingen mogelijk, CDN is vaak ook al een goede omdat hierbij de CDN leverencier de afbeeldingen css etc zelf van de dichtsbijzijnde server laat laden, het enige trage zou dan de webserver met dynamische content zijn en de vraag is dan welke snelheid is accepteerbaar. Met de webserver op één locatie zou ik wel op zoek gaan naar een netwerk met goede internationale verbindingen.
Ik heb reeds een DRBD oplossing gebouwd. Maar uit ervaring kan ik zeggen dat DRBD over twee locaties (en vooral met een hoge latency) niet lekker loopt. Ervaring met master/master oplossingen heb ik ook in huis. Dus dat zou het probleem niet zijn.
Ik zal eens meer opzoeken over geografische DNS servers.
Ik ga zeker even kijken naar het begrip 'CDN'.
Bedankt voor de reacties tot dusver. Thanks!
Over een master/master setup heb ik al nagedacht. Dit wil ik liever voorkomen aangezien mijn ervaring hiermee niet erg goed is. En de data syncen met rsync is niet 'live'.
Ik zal eens kijken naar een CDN leverancier.
Dat is inderdaad waar, maar het 'probleem' in dit geval is dat de webshop beheert wordt vanuit Europa en Amerika. En indien ik de webshop in bijvoorbeeld Amerika host en de 'Europese' beheerder moet de webshop gaan vullen e.d. dan denk ik dat er veel irritaties gaan ontstaan (wachten, wachten, wachten).
In principe moet _alles_ live staan inderdaad. Je kunt twee losse webshops gebruiken, maar dan zit je met twee 'boekhoudingen' aangezien beide webshops een eigen 'leven' leiden.
Ik heb reeds een DRBD oplossing gebouwd. Maar uit ervaring kan ik zeggen dat DRBD over twee locaties (en vooral met een hoge latency) niet lekker loopt. Ervaring met master/master oplossingen heb ik ook in huis. Dus dat zou het probleem niet zijn.
Ik zal eens meer opzoeken over geografische DNS servers.
Ik ga zeker even kijken naar het begrip 'CDN'.
Bedankt voor de reacties tot dusver. Thanks!
CDN staat voor Content Delivery Network . Akamai is een bekend voorbeeld.
Die kunnen bezoekers slim redirecten naar een 'dichtbije' server, en vanuit een (voor de bezoeker nabije) cache content leveren.
Maar die hebben ook geen magie om aan je eis van een wereldwijd consistente database te voldoen zonder zichtbare latency.
De hoge latency is een fundamenteel gegeven, en wat je moet doen is die zodanig verstoppen dat het niet erg opvalt.
Veel roundtrips kosten snel veel tijd, dus je moet niet voor elk veld een 'verre' database hoeven queryen.
Data die niet wijzigt met transacties moet je lokaal houden; Wellicht kun je werken met een los gesynchroniseerde databases, en alleen bij een definitieve checkout transacties doen met een database die wereldwijd consistent is.
Het is hetzelfde probleem wat veel 'enterprise' client server applicaties hebben, die zijn allemaal ontwikkeld door programmeurs die coden alsof alles op een <1msec lan staat. Over een wan is de performance dan bitter slecht.
Je weet dat er wan emulators zijn (wanem bijvoorbeeld), waarmee je een PC met twee netwerken een verbinding met hogere latency, beperkte bandbreedte, packetloss e.d. kunt laten simuleren ?
Daarmee kun je makkelijk een concept testen nog voordat je een 'verre' server hebt.
systemdeveloper
25/09/11, 21:46
Het verschil tussen de US en europa (afhankelijk van westen/oosten) ligt tussen de 200-600ms.
Daar kom je niet onderuit. DRBD is niet de beste oplossing om de boel synchroon te houden en tegelijkertijd live te kunnen gebruiken op beide servers.
Daarvoor kun je misschien eens naar gluster kijken. Werkt ideaal.
Geografisch gescheiden DNS maakt de sites voor je gebruikers maar marginaal sneller. We hebben het over een udp query die een client moet doen om het ip te resolven en wellicht vele 100kb's aan webpage content en 10 tallen mysql queries.
Maar 'live' is in de eye of de beholder natuurlijk. Als jij voor beide werelddelen gebruik maakt van 1 centrale db server dan is je data altijd live. Als je dat met product images ook doet via bv een nfs share, dan is ook 'dat' live.
Je focust je op snelheid vanwege geografisch gescheiden systemen, echter dat hoef je niet altijd te doen. Die 200-600 ms kun je vaak op vele andere manieren sneller behalen. (gebruik bv een paar relatief goedkope ssd's voor je databases, tempfiles en alles wat een beetje io nodig heeft en voor je het weet bespaar je een wellicht een flink stuk meer?).
Het verschil tussen de US en europa (afhankelijk van westen/oosten) ligt tussen de 200-600ms.
Dat is wat overdreven. Ca 60- 70 msec transatlantisch, en dan nog eens 30-40 msec erbij naar de westkust.
Mooie vuistregel is 1 msec rtt per 100 KM .
Daar kom je niet onderuit. DRBD is niet de beste oplossing om de boel synchroon te houden en tegelijkertijd live te kunnen gebruiken op beide servers.
Daarvoor kun je misschien eens naar gluster kijken. Werkt ideaal.
Geografisch gescheiden DNS maakt de sites voor je gebruikers maar marginaal sneller. We hebben het over een udp query die een client moet doen om het ip te resolven en wellicht vele 100kb's aan webpage content en 10 tallen mysql queries.
Dat is feitelijk de hint om te optimaliseren, je moet dus geen tientallen mysql queries moeten doen over een high-latency verbinding, niet wanneer het opvalt voor de gebruiker.
Die 100KBs content kunnen zo snel als de lijnen gaan, maar 20 query's @120 msec rtt duren al 2,4 seconde round trip, + 20x de executie tijd.
Als je binnen je site nog meer DNS queries moet doen gaat het wel merkbaar worden, en al helemaal als je blokkeert op trage banner sites of slome counters.
Maar 'live' is in de eye of de beholder natuurlijk. Als jij voor beide werelddelen gebruik maakt van 1 centrale db server dan is je data altijd live. Als je dat met product images ook doet via bv een nfs share, dan is ook 'dat' live.
Je focust je op snelheid vanwege geografisch gescheiden systemen, echter dat hoef je niet altijd te doen. Die 200-600 ms kun je vaak op vele andere manieren sneller behalen. (gebruik bv een paar relatief goedkope ssd's voor je databases, tempfiles en alles wat een beetje io nodig heeft en voor je het weet bespaar je een wellicht een flink stuk meer?).
Vaak op en neer moeten over een hoge latency verbinding wordt al heel snel dominant, zelfs als de acties zelf wel snel zijn.
Dat is precies waar TCP windows voor bedacht zijn, en waardoor SMB(v1) [windows shared drives] over WAN (of VPN) enorm traag zijn.
Ik vrees voor de OP dat veel webshop code geschreven zal zijn alsof de database altijd 'dichtbij' staat.
Yourwebhoster
25/09/11, 22:33
Geografisch gescheiden DNS maakt de sites voor je gebruikers maar marginaal sneller. We hebben het over een udp query die een client moet doen om het ip te resolven en wellicht vele 100kb's aan webpage content en 10 tallen mysql queries.
Ik heb het hier niet over geografische gescheiden DNS, maar DNS servers die bij een aanvraag gaat kijken vanuit welk land het IP komt en op basis daarvan de dichtsbij zijnde webserver als IP terug geeft.
Je focust je op snelheid vanwege geografisch gescheiden systemen, echter dat hoef je niet altijd te doen. Die 200-600 ms kun je vaak op vele andere manieren sneller behalen. (gebruik bv een paar relatief goedkope ssd's voor je databases, tempfiles en alles wat een beetje io nodig heeft en voor je het weet bespaar je een wellicht een flink stuk meer?).
200-600ms ga je echt niet inhalen met simpele SSD's tenzij je een brak script gaat gebruiken (maar dan zit je nog steeds met de 200-600 ms vertraging van het netwerk). Magento oke, maar dan zit je nog steeds met 200-600 ms (wel erg extreem trouwens, met goede transits heb je dit niet) die je moet gaan overbruggen. Deels valt dit in te halen met een CDN die dan veel sneller de plaatjes, stylesheets, etc kan aanleveren, enige request (als maar één dynamische request is) is dan de web pagina.
Wat je zou kunnen zeggen is ik pak het goedkoop aan; ik zet in een netwerk met goede internationale verbindingen een goede server opstelling neer. Neem een CDN en dan is het ergste al weg, optimaliseer je server (en als je Magento gebruikt zeker aan te raden, drama voor systeembeheerders) en je maakt een goede start. Je kan kijken wat de laadtijden dan zijn en mocht dit onacceptabel zijn dan kan je altijd nog een internationale setup doen.
Let overigens ook even op met het juridische gedeelte in the USA. Ik ken het fijne hier niet van maar het is handig om uit te zoeken hoe het juridisch gezien zit.
systemdeveloper
26/09/11, 00:26
Die 200-600 ms zijn op basis van de sitecheck op dit forum met een random site uit nl. Op dat moment was dat dus niet zo overdreven alhoewel het erg variabel was. De snelste us ping was ca. 200 ms langer dan die van a'dam.
Een CDN of althans een manier om je static content vanaf verschillende (sub)domeinen te leveren is altijd goed. Zeker voor bezoekers omdat de page dan snel geladen wordt.
Maar 'een hostingpakketje in de US' laat niet veel ruimte voor fantasie over en eigenlijk mag je al blij zijn als je met een master/master setup wegkomt.
Yourwebhoster
26/09/11, 07:46
Die 200-600 ms zijn op basis van de sitecheck op dit forum met een random site uit nl. Op dat moment was dat dus niet zo overdreven alhoewel het erg variabel was. De snelste us ping was ca. 200 ms langer dan die van a'dam.
Een CDN of althans een manier om je static content vanaf verschillende (sub)domeinen te leveren is altijd goed. Zeker voor bezoekers omdat de page dan snel geladen wordt.
Maar 'een hostingpakketje in de US' laat niet veel ruimte voor fantasie over en eigenlijk mag je al blij zijn als je met een master/master setup wegkomt.
http://network-tools.com/default.asp?prog=ping&host=178.21.20.99
Lijkt mij eerder dat je een goed netwerk moet kiezen en dan zit je met 125 ms goed. Ik zou uitgaan van 125-200 ms met een netwerk dat vooral ook goede connecties naar the usa heeft.
http://www.webhostingtalk.nl/quicktest.php?action=result&qtid=701759&r=9594
http://network-tools.com/default.asp?prog=ping&host=178.21.20.99
Lijkt mij eerder dat je een goed netwerk moet kiezen en dan zit je met 125 ms goed. Ik zou uitgaan van 125-200 ms met een netwerk dat vooral ook goede connecties naar the usa heeft.
http://www.webhostingtalk.nl/quicktest.php?action=result&qtid=701759&r=9594
Dat zijn ping testen, ik denk dat systemdeveloper het over http request had (http://www.webhostingtalk.nl/quicktest.php?action=result&qtid=701836&r=1073) en dan is er inderdaad wel een groot verschil merkbaar. Zeker als we dan te maken hebben met een webshop die zoals eerder vermeld niet geoptimaliseerd is of gemaakt is om op meerdere plaatsen gebruikt te worden.
systemdeveloper
26/09/11, 10:45
Dat zijn ping testen, ik denk dat systemdeveloper het over http request had (http://www.webhostingtalk.nl/quicktest.php?action=result&qtid=701836&r=1073) en dan is er inderdaad wel een groot verschil merkbaar. Zeker als we dan te maken hebben met een webshop die zoals eerder vermeld niet geoptimaliseerd is of gemaakt is om op meerdere plaatsen gebruikt te worden.
Ik bedoelde idd de http request :)