Distributed Installations with Different URLs for Languages
Google and other search engines decide from the location of your server IP address how your site will rank in their search results.
This might become a problem, especially for e-commerce sites, if you want to target another market, as these kind of sites usually change their content incessantly, like the stock display etc.
Let’s start over with an example to state the case more clearly. Let’s say Hans is an online merchant who started with just a small budget, delivering only within his homeland of Germany. When he started, he decided a) for OXID eShop as his shopping cart software, b) for a German hosting provider (to make sure that he has somebody trustworthy within easy reach, and c) he registered hans-products.de as a domain for his e-business. Later he learned that this choice was on the button: he got a German IP address, and because he sells extraordinary products, his store ranked on one of the first places.
A couple of years later Hans on his holidays visits Madrid. He talks to some people and recognizes that the interest in his products in Spain seems to be immense. So he decides to expand his online business to Spain.
The first thing Hans has to do now is to translate his OXID eShop into Spanish, not only the language files but also all information in the database like product items etc. He activates his new language, sits back and waits for his Spanish customers. But nothing happens, and for good reason: he runs a German domain – why should a search engine display his information in Spain although his site is translated?
Hans comes across this nice little feature in OXID eShop: a language dependent base URL. “Brilliant!” he thinks – and off he goes talking to his hosting provider, additionally booking the domain name hans-productos.es. He enters his new domain name and look, it works perfectly: when he changes the language, the shop magically switches the URL – back and forth and vice versa. Now Hans sits back again waiting for his Spanish customers and this time he seems to be more successful! He gets some orders per week, but he is still far away from the point where he could talk about bringing home the bacon. What’s the reason for it?
Like I stated at the beginning, one criteria for the global search engines seems to be the location of the server, and this location can be determined by it’s IP address. Although Hans translated his entire website and registered a Spanish domain name, his site will still poorly rank against his competitors in Spain. If he wants to win the contest, he has to think about an additional hosting at least of the content of his e-commerce website in the country where he wants to be successful, doesn’t he?
And shall I tell you what? It is possible with OXID eShop in any edition 🙂
It doesn’t make sense to have two complete installations for both countries, Spain and Germany, because the databases would have to be synchronized. Instead, Hans sets up a copy of his online store at a Spanish hosting provider, moves his Spanish domain name to it and links this installation to the German database via a VPN tunnel. This is what we’d call a “distributed shop installation”.
Hans is happy and it was so easy. Well, it works in general but it wouldn’t be IT if there were no pitfalls, would it?
There are a lot of criteria that could influence the performance of such a system. For example, the hosting providers’ connection to the Internet backbones and the setup of the VPN tunnel could be a crucial issue, as well as the distance between both instances. At a distributed server in Brazil or in China the little bits and byte creatures would have to take a much longer way to run to Germany, right? And this effect gets more and more critical the more simultaneous visitors you have on your websites. That’s why, for high load scenarios, OXID offers a special package with master/slave database configurations to intercept such effects even in multi stores.
Of course, distributed installations will not resolve the entire palette of issues if you are considering selling international. There are lots of other points one shall have in mind, just thinking of the legal stuff… Also, for this SEO related topic, I am not really sure if this will work in languages that do not use the Romanic based alphabet.
Finally I must admit that I only had the chance to check distributed installations under “ideal conditions” on servers based in Germany, simply because I don’t have web space in Brazil or elsewhere. Would be glad if you’d let me know about your experience with this.
While I basicly like your idea, I would add a layer of caching between the spanish provider and the german database.
It is quite easy to modify Oxid in a fashion that most queries (i.e. *reading* db access) go throu a local redis instance, sending db queries only for cache misses.
With a high-enough expiration you can avoid most of the lags. In a second step – and now comes the nice stuff – you can even increase timeouts and actively push changes from germany to the remote systems.
The concept is that saving a category description is not as performance critical than retrieving it.
By the way: if you´d open your db to the foreign ip, you would eliminate the need for vpn and could use some low-cost server to start your foreign business – or did I miss something?
Zsolt
Thanks for your reply, Zsolt – really appreciate it.
Of course, an entire on-site page cache would be optimal but I doubt if it’ll be able to intercept all possible DB bottlenecks, of course – depending on the server timeout configuration, the distance etc…
And yes, you’re right, simply opening your DB to a foreign IP would work but I’d go clearly for VPN: as an online merchant, you’re 100% responsible for your customer’s data. And a non-tunneled connection could open options for a man-in-the-middle-attacks, couldn’t it?
Marco, I fully agree with your strong demand for security.
I assume that you trust VPN since it provides encryption. Same goes for MySql, althou it requires you to grant the SSL right and block non-SSL-connections. http://dev.mysql.com/doc/refman/5.0/en/ssl-connections.html
Additionally, you can limit remote IP to the one of your foreign server. Both together would be as secure as a VPN, I assume. Or did I miss your point?
About the db bottlenecks – of course you cannot handle all of them, and stuff like oxcontent is already cached in the /tmp – dir. Yet running a (k)Cachegrind session shows at least enough potential to give it a try.
Zsolt