OK, here is the situation.

We have a website available world wide. Let's say it's a forum system, let's even assume we are using THIS asp.NET forum website.

 We have users around the world. Unfortunately, users in China feel it's too slow, even US users feel it's fast. Apparently the internet connection distance is different since our server is in US. But if we move our server in US, apparently, Us users will complain.

How to make sure users in China don't have a performance hit?

 

I was thinking to have another web server in China. But what about the SQL server? If we have a SQL server in China, man, I have to deal with the replication. But is this the only solution? Anybody has a better idea of ensuring performance for different geographic area around the world?

 Thanks,

 

Calvin 

 

 

 

Replication is very resource intensive and is the only feature in SQL Server that is work in progress I have not used it recently, but my last project was to run in at least 20 countries and the plan was to run a copy in every country.  Try the link below for the SQL Server 2005 features list you may just run the China SQL Server as subscriber of your US SQL Server. You could do some performance testing with 28k modem that was what my friend use to test a 32 languages site.  Hope this helps.

http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx

I thought this issue was long dead and buried. Havent heard this one in the last 3 years atleast. Well you have multiple options

1) Buy bandwidth from local ISPs of slow locations: So if the chinese users complain about speed, buy a dedicated IPLC link to that ISP ( Or some ISP you know is the internet backbone of that country), broadcast your servers IP address there, and the users will not have to come thru the national internet gateway or bottleneck.

2) Cache static content locally: Use services like Akamai.

 3) Read only DB replication: replicate the DB one way, the local instance is read only and central is  read write. The application needs to ensure that it looks at the local read only connection pool  for fetches ( which hopefully will be 90% usage) and use the central database for any updates/inserts. Once you use this approach,  you should be able to optimize it somewhat by doing the updates asynchronously, and in bulk, at end of flow only.

4) Minimise HTML size: review the html and optimize.

5) Maximize local cache: make as much part of the page an included .js file as possible. The .js will be cached at client browser.

6) Use HTTP compression - its just a setting on IIS server.

7) Minimize transfer size: Use Ajax to just get the specific portions of page.

8) Use tricle feed to make the users feel they are seeing content faster. In olden days, nested tables were not used as browsers dont render an entire table till they see the end of it.

In case you do replicate, there are intelligent DNS servers available which - based on the originating IP address, redirect users to their nearest servers.

I have replicated this reply in my blog here and might be adding more content to it soon.

 

I was just wondering that if auser in China post an article, what should I do? redirect the traffic to US so to write to US SQL server?

If you are not using 8 way boxes that is not a good idea because a DTS package can update your US servers every night and it is zero performance cost.  The reason we use the Agent and DTS/SSIS because it is more efficient Microsoft have noticed you must pay for a license to use both.    

Oh, you are talking to synchronize every night, it's not gonna work.

SQL server mirroring won't do me any good, as the mirrored server can not be used.

 

Looks like replication is the only way to go? 

Try the link below for snapshot replication but run some tests I have not used it a whileback.

 http://msdn2.microsoft.com/en-us/library/ms151734.aspx

on a corporate app we released on our intranet,  we also sufferred performance issues in shanghai and denmark
the quick fix was to use compression.  rather than use the "switch" built into iis, we used the Blowery compression module so we had finer control over whether compression would occur on a page by page basis.

reference: http://www.blowery.org/code/HttpCompressionModule.html
Note: .NET 2.0 has built in compression streams so creating your own compression module/filter is fairly straight forward

our pages achieved about a 75% reduction in size.
additionally, we off loaded viewstate to the users session.  this netted us about an additionat 5-10% reduction (at the expense of server memory...be carefull).

as a quick check on the size of this exact post, i used fiddler to capture the traffic

reference: http://www.fiddlertool.com/fiddler/

UnCompressed	Compressed (GZip)
Request Count:  51 Bytes Sent:  49,259 Bytes Received: 259,734 RESPONSE BYTES (by Content-Type) --------------                 text/css: 78,174 application/x-javascript: 95,450                text/html: 12,104                image/gif: 56,375               image/jpeg: 2,846                 ~headers: 14,785	Request Count:  49 Bytes Sent:  47,625 Bytes Received: 120,546 RESPONSE BYTES (by Content-Type) --------------                 text/css: 12,433 application/x-javascript: 22,827                text/html: 11,121                image/gif: 56,375               image/jpeg: 2,846                 ~headers: 14,944

looks like a little compression could go a long way for this site too.  compression does consume some additional cpu - so if your already pushing your cpu, be carefull.

Also be careful if you are running pages that require ntfs authentication.  the ntfs handshaking creates additional back and forth traffic which becomes noticeable on long distance network links.

(Also be careful if you are running pages that require ntfs authentication.  the ntfs handshaking creates additional back and forth traffic which becomes noticeable on long distance network links.)

NTFS authentication is usually used for intranet but not general web application because of Windows profile updates and other house keeping.

Caddre:

(Also be careful if you are running pages that require ntfs authentication.  the ntfs handshaking creates additional back and forth traffic which becomes noticeable on long distance network links.)

NTFS authentication is usually used for intranet but not general web application because of Windows profile updates and other house keeping.

True, but i've [unfortunately] seen it done...  :-(