BitCoin seems to be latest rage with wild value fluctuations. The past few days have seen a very wild roller coaster for the online currency. Most of the world's BitCoins are exchanged at MtGox.com, which has had some issues either with a denial of service attack or the ability to scale. Either way the site has at times been unresponsive. This has lead to a panic, causing the value of a BitCoin to drop wildly.
I have heard and read they were adding around 20,000 users a day this week with around 60,000 daily users. While those numbers may seem large to many, they are still rather small. Mt. Gox announced they were going to add more servers to solve the problem, which is a standard answer most IT operations give when they are having performance issues.
I have a lot of experience with web performance, scaling, etc under my belt and I know that most single web servers should be able to handle that traffic volume with ease. I have managed more traffic than that on a Dual Pentium 500 Mhz machine back in the day running ASP.NET WebForms. Its not just Mt. Gox, I see the same response over and over, especially in the enterprise. When I evaluate an application I find many ways to fix the issue with some simple configuration or coding changes. Sometimes it does take a complete rewrite to overcome just poor architecture and development.
So what do they do wrong?
The biggest thing they could do is set a far future expires header. Currently they allow nothing to be cached by the browsers. This means each page request, basically anytime a user navigates to a new page in the site, they will redownload the scripts, styles and images. As I did a quick navigation around the site I see no 304 HTTP status codes. This is bad because they need to reserve this content over and over again to the same client. This consumes unnecessary bandwidth and taxes the server.
Since just about everything on their home page is static the site would load almost instantaneously after the first visit, as would just about every subsequent page. I do not have a Mt. Gox account and I own no bitcoins so I did not go into the actual trading experience. Looking at the source code they do use Web Sockets, so that tells me there is much static content that could be better served with a future expires header.
Next, they do not use a CDN. In the past this was something only the big dogs could afford. Today that is simply not true. Even I have a poor man's CDN for this blog. I setup an Amazon S3 domain a few years ago to serve my images. Today both Amazon and Azure have cheap CDN cloud services. Just doing some quick estimates for Mt. Gox I could see them spending around $5-10 a month on the Azure CDN to host their scripts, CSS and images.
This would also give them some additional benefits. It would remove that content from the main server, offloading that demand to a more scalable solution. But it would allow the static resources to be downloaded using an additional domain, meaning there are additional HTTP threads the browser will open, in this case adding speed to the site load.
Also they can be hosted on a cookieless domain. Cookies add weight to each and every resource being downloaded. This slows down the speed at which a resource can be downloaded. Since images, scripts and CSS files don't typically care if the user is being tracked it is unnecessary to host these resources on a domain needed cookies.
These are suggestions based on my many years of web development and performance tuning experience. These are all front-end observations, but that is where about 80% of a web site's performance and scaling issues reside. I did not got into, nor do I have access to Mt Gox's PHP driven back end. My hope is they are using a good NoSQL option for speed as well. They are using Web Sockets, which is a very good sign they are on their way to a great modern web application.
The changes I have highlighted are easy enough to configure and setup. They could all be done within a few hours. Applying these simple adjustments to their web site could save the company thousands of dollars each month and improve the site's performance. And we all know fast sites make a lot more money!