The problem with this is that the problem seems to be only with the connection to 1 ISP (Singtel) and which i have no problem with the others. based on my mrtg on the data center router, my network utilisation is only less than 5% at peak. These i think would quite effectively elimate the problem due to bandwidth and backend processing.
How effectively to reduce the RTT time by having servers in multiple data centre. Would its be of more trouble to sync them etc? what is normally the standard practice to reduce such problem? On Fri, Jan 2, 2009 at 4:47 AM, Chris Henry <[email protected]> wrote: > On Thu, Jan 1, 2009 at 12:00 PM, Yong Han <[email protected]> wrote: >> >> i have a few spaces on in a data center in singapore and i am having >> some problem of users having latency problem in telcos like singtel. >> >> i am thinking of ways to speed up the link or lower the network latency? > > Could you define the problem more specifically? Have you figured out > whether it is the RTT time that is very high, or the bandwidth is too > little, or the backend is slow in processing? > > RTT time (and packet loss rate) can't be decreased easily other than > having servers in multiple data centers (or using Akamai and the like) > and intelligent load balancing. > > Bandwidth problem can be easily profiled. If bandwidth is your > problem, the easy way around is to increase the bandwidth. The not so > easy solution would be to make sure you don't send redundant > responses. Reducing the number of whitespaces to zero and decreasing > the amount of line feed (or CR-LF) in your HTML can even help a lot > with this. > > If your backend is slow, that will more involved. This is usually a > problem with webapps (or CMS). My experience with improving backend > latency tells me that unless your application is written that poorly, > it'll be hard to improve this latency. The first thing you should be > looking would be the cache policy. Start with static data (images, > etc.), the should be cached for a long time. You can even use > versioning/hashing to introduce even stronger cache policy. Then take > a look whether you could cache dynamic responses. Also seek to reduce > the number of database requests (and reduce the number of > indiscriminate JOINs and ORDER BYs). Bottom line is improving backend > latency would be hard work. ): > > Frontend latency on the other hand is much easier to improve. Take a > look at Web Performance book by Steven Souders[1] or check out his > website. There are a lot of stuffs you can do to improve frontend > performance (some of them will also relieve stress on your backend > servers. Some of the ones I'd implement first would be caching of > static contents (previous para), placing CSS and Javascript at the > correct places, chunked transfer (HTTP 1.1 Transfer-Encoding: > chunked), and reducing the number of descendant CSS selectors. > > If you could redefine your problems to be more specific, maybe people > could help you even better. I think the first thing you should do is > find out which of the above latency problems were causing you trouble. > I won't consider myself an expert with latency problems, but I have > some experience improving frontend latency and backend latency (the > first two types of latency problems were often out of my scope) and > I'll be happy to share them if they are useful. > > Cheers, > > > -- > Chris > [email protected] > +65 9755 3292 (2 more weeks to Singapore!) > > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > _______________________________________________ Slugnet mailing list [email protected] http://wiki.lugs.org.sg/LugsMailingListFaq http://www.lugs.org.sg/mailman/listinfo/slugnet
