Archive for June, 2009

Firefox.next (Namoroka) Is Coming

Minefield

Minefield

I’ve built a pre-Alpha 1 version of Firefox 3.6 also known as Namoroka (following the park theme). Namoroka is a national park in Madagascar.

As with previous Shiretoko builds I’ve done, I’m using the same .mozconfig file for optimization as well as fiddling with the application defaults for speed. I am no longer changing the User-Agent on these builds as some people are reporting problems when accessing sites such as Facebook that don’t recognize the UA. When are people going to stop browser sniffing?

In this version, the “parse HTML 5” was off by default. I’ve turned this on. One other thing is that the browser’s name is “Minefield” as this is a pre-Alpha and things are supposed to blow up (so be careful).

You can find the Namoroka build on my downloads page.

Twitter is Dying

Follow Like Crazy

Follow Like Crazy

Update: I have confirmed that Twitter is using MySQL (unless the mentioned upgrades are a move to a different DB).

With all due respect, Michael Jackson may have given Twitter the final knockout punch. I’m sure you guys are sick of hearing of Twitter’s problems, and frankly I’m sick of writing about them. This new failure is worse than any failwhale, this is a failure of concurrency. Here is a brief timeline of what has happened so far:

  1. June 3 – Twitter realizes there is a half-hour lag on follow/unfollow that should be resolved WITHIN THE NEXT HOUR OR SO.
  2. June 18 – Twitter states it is making infrastructure upgrades to fix the follow/unfollow delay OVER THE NEXT 24 HOURS.
  3. June 23 – Twitter again states there is a lag on follow/unfollow and offers additional info on areas affected – device notification changes and favoriting, BUT WE ALREADY KNEW THIS.
  4. June 23 – Twitter announces additional upgrades for the 24th to fix the problem and says the problem will persist UNTIL LATER IN THE DAY TOMORROW.
  5. June 24 – Twitter says the upgrades were successful and that the catch up period will last FOR AT LEAST ANOTHER 6-12 HOURS.
  6. June 25, 11:26 am – A Twitter employee states “We’re still working on the fix and this is currently the top priority of the services team. It’s a pretty extensive code deployment so it is taking some time.”
  7. June 26 – I’m following fewer people today than I was yesterday and my 1,000 FOLLOWING/DAY LIMIT HAS BEEN HIT.

I can’t talk about the Twitter infrastructure, but I’ve seen this problem before in one of my own companies. With MySQL replication across multiple servers and tons of activity going on, it is almost impossible for the slaves to catch up. In addition, each replicator is generating enormous log files in the event replication fails. These log files can quickly fill up a server especially if you don’t know what you’re doing and have MySQL in a tiny /var partition. Once the log file overruns the server, you cease to replicate until the situation is rectified. I suspect this is what the problem is and with each addition of servers (in the above-mentioned upgrades), those log files get nastier and nastier. There is a fix for this replication problem, but it involves taking all systems offline, rsynching from a master (if there is one) and clearing all logs.

Now MJ steps into the picture and blows the infrastructure away. The search sidebar was removed and later re-added, but this just keeps the failwhale at bay and does nothing but compound the follow/unfollow delays. Now we’re at critical mass with this problem as follow/unfollow basically does not work, or works inconsistently at best. This is going to turn people off in droves as the system is not working as expected. The “I just don’t get it” of Twitter has just been amplified. The image on the above-right show a single person that REALLY wants to follow me, each mail highlighted in blue says “This person has just followed you,” sad thing is, after all this effort they still aren’t following me.

With the failwhale, people got upset but realized that there is so much cool stuff going on here I can hang tight until the system is back. It is sort of like the logic behind the beta-invite. This is entirely different, Twitter isn’t acting as expected.

Also, I’m only taking about one aspect of Twitter in this post. There are the search problems which still aren’t fixed despite the update provided in that link. There was the “all posts coming from the web” problem which occurred over a weekend where, apparently, they take a holiday. This may not sound like a big deal, but it was for a lot of developers and even one business had to SHUT DOWN until the problem was fixed. There are many, many other issues that I’m just not going to bring up.

I’m not giving up on Twitter, but you can find me on FriendFeed.

To Twitter’s credit they have been fairly open on their status blog and their employees are pretty active on the mailing lists.

Mobile Safari Benchmarks

Update: Ran the benchmark on an iPhone 3GS 32Gb and saw yet another three-fold increase in speed.

Schiller was tossin’ around some pretty impressive benchmarks on the new version of Mobile Safari in iPhone OS 3. I’ve been using the OS 3 betas from the second they were available and definitely noticed speed improvements right off the bat.

These SunSpider tests were done on the same 2nd-gen 16Gb 2G iPhone on the same network. I’ve been saving these numbers for a bit, dang NDA, but now here they are:

mobile_safari

Mobile Safari SunSpider Benchmarks

Twitter, We Have A Problem

spitterSpatter, Speet, Spitter, Spam!

Looks like the reCAPTCHA got jacked (or more likely the Mechanical Turk got involved) and the floodgates have opened for the spitters (or whatever you wanna call them). The account shown on the right gained several hundred followers in the time I watched it. Page after page after page of these useless, non-profile-imaged, non-bio’d, non-locationed, never-status-updated freaks.

Back to watching Scotty Got An Office Job or earning another banjo on Hunch. No wait, I’m extremely busy with a crazy deadline. Scratch that.

Off topic: I updated the Intel-Optimized Firefox build. It seems there is an official RC2 that slipped out after the announcement of the RC availability. I’ve built the RC2 version and you can download on the download page.

Browser Battle Round Three, Fight!

Gort!

Gort!

Update: It seems that I’ve over-optimized a bit on the latest build. I’ve toned it down and made it Tiger-compatible. The new build is on the downloads page.

With a few new browsers released this past week, I thought I’d redo the SunSpider JavaScript Benchmark on a couple (sorry Opera), and report the results. As usual, I disabled all add-ons, extensions, InputManagers, etc. The benchmarks were run on the same machine as the previous tests.

I also created another Intel Optimized Build of Firefox 3.5 RC preview (Shiretoko) using an updated .mozconfig file based on several reader contributions (including Mozilla employees). This new config is heavily optimized (that’s your warning). You can download both of those files on the downloads page.

Safari and Shiretoko did better than their previous incarnations, while Chrome OS X suffered in it’s jump from Chromium. The breakdown looks something like this:

  • Safari: 20.9% faster
  • Shiretoko: 13.6% faster
  • Chrome: 16.7% slower

And the neat graph looks like this:

SunSpider JavaScript Benchmark Results

SunSpider JavaScript Benchmark Results

Oh, and to find out what Gort is all about, go to about:robots in Firefox.

Gort! Klaatu barada nikto!