Wednesday, August 31, 2005

Eclipse website redesign (Phoenix)

According to the Project Phoenix plan, today is the day we pick a brand new look for the Eclipse website. What a grandiose affair! After having the same look since August 2001, we'll start fitting new content to a new look. We only have three templates to choose from, but they are great designs. Big thanks to Roger, Stavros, Andrew and Linda for the effort they put in to their templates.

I receive mail on a regular basis claiming numerous problems with our site (sometimes even insults!), and I read about the Eclipse website horrors that our community posts on various blogs, so I was litterally expecting dozens of design templates to pour in. Perhaps we didn't do a good job of advertising the fact we were looking for templates.

Well it's not over yet, because I don't think we'll be picking a template until early next week.

Cast your vote on the template you like best, or better yet, submit your own! (Bugzilla account required - free - while supplies last.)

Wednesday, August 24, 2005

Why does bugzilla lag?

Although I haven't seen this since putting in the new servers, the complaint I've received the most often is that Bugzilla is slow. Although I don't use Bugzilla as much as our Committers do, I do use it on a daily basis and I got to wondering why Bugzilla occasionally lags - even with powerful hardware, server load-balancing and priority rules for bandwidth.

When I got a lag some time ago, I ran show processlist on MySQL, and it yielded what I feared: some large SELECTs are locking some tables, preventing other queries from being executed. If these SELECTs take 5 seconds, everyone using Bugzilla at that time will feel the lag.

"Don't use MySQL, use (insert your DB here)!" "Convert the tables to InnoDB!" "RTFM!" I hear you already. Bear in mind that Bugzilla does take a beating. Looking at the logs, I see some folks do some pretty interesting stuf. The heaviest user of Bugzilla? crawl-66-249-65-17.googlebot.com, by a long shot. Wow, can that user ever request a lot of stuff in one minute. ;)

A less intrusive solution, and certainly one that scales much better, is for applications to provide two database connection paths: one for SELECTS and another for write queries, such as INSERT, UPDATE and DELETE. Eclipse.org has two database servers: the main server and a replicated server. Whis this type of setup, the replicated server can be used for read-only queries, such as SELECTS, reducing the load on the master server. For instance, queries from the Eclipse.org search engine or live download stats go to the replica, therefore not affecting the master database server in any way. By contrast, the search engine's indexer sends its INSERTs and UPDATEs to the main server.

However, not all software allows me to plit READ and WRITE queries to two different servers. If bugzilla had this, we wouldn't have this occasional lag. Furthermore, Bugzilla would be much more scalable: add replicated servers and split the reads across replicas. Knowing that most database applications perform many more reads than writes, it makes for a fast and fault-tolerant solution.

If/when I get the time, I'll hack this functionality into the Bugzilla code. Replication is a fault-tolerant way of storing data, so the application might as well use it for a performance advantage as well. The next time you write a database application, bear this in mind.

Saturday, August 13, 2005

Feels good to give

This weekend I went to the local SPCA to do good on my pledge for the Million Download challenge. $10/day X 20 days made for a nice donation of $200 - enough to buy some food, vaccines and perhaps a bit of veterinarian TLC for a few pets.

I hope the community gets together again for another challenge. Not only did I walk out of there with a nifty tax credit receipt, but also with a good feeling knowing I gave some money to a good cause.

Tuesday, August 09, 2005

planeteclipse planeteclipse hiccupps hiccupps

As per bug 105770 planeteclipse.org has been behaving real nasty lately. I've installed Gunnar's verion and it's running in parallel. Try it out and let me know what you think. I figure it can't be worse than what's here now.

http://planeteclipse.org/planet-new/

Friday, August 05, 2005

bittorrent blues

When Eclipse 3.1 was released, the eclipse.org website slowed to a crawl within hours. One key cause of the saturation was that we failed to allow our mirror sites time to sync up before publishing the links. It hurt and we learned.

During the 3.1 chaos, I must have received about 10 e-mails from (understandably) disgruntled downloaders all wondering why I didn't post torrents. Commens ranged from "P2P - it seems so obvious" to "who's the idiot". So why didn't we?

I tried to use BitTorrent in the past with little success. Slow downloads, no peers and no seeds left me dangling with a fast cable connection and nothing coming in. So when Eclipse 3.1 was released, I couldn't imagine why one would want to use BitTorrent to download it. But these e-mails made me question myself. Has it changed? All ten of them can't be wrong? Has the power of P2P outclassed dozens of server-class computers with big disks connected to large Internet pipes throughout the world, managed by skilled SysAdmins?

Shortly after 3.1, I set out to download Fedora Core 4. It weighs in at about 2.5 GB. I spotted the FC4 torrent links and I figured, "it's a sign, let's give this another try". With a new attitude, I go to download Azureus, arguably the best BitTorrent client out there. Clicking on the Linux X86_64 link, I am presented with a list of mirror sites. Hrm. "Mirrors, how passé" I think to myself. With Azureus installed, I then click on the shiny Fedora Core 4 torrent links and voilà - I'm downloading FC4 at the blazing speed of -- 90kB/sec.

What is this? I can easily get just shy of 600 kB/sec from eclipse.org and here I am, with the power of the P2P world at my feet, yawning at 90k with only 30 peers. "Maybe I need to give it some time to get to like me" I think so I go out for a while.

Several hours later, I return to my Azureus screen, only to see 18 kB/sec - 4%. Ouch, only 12 peers. Granted, I'm giving a bit back, uploading at - hang on - 5kB/sec, but at this rate, it would be faster to drive to Raleigh and ask someone at Red Hat for the CDs (Ottawa-Raleigh is about a 28-hour round-trip, for about 2.5GB - grossing 26 kB/sec. I did the math).

Just for fun, I return to the Fedora page, hit the download link and click, *shudder*, mirrors. I browse to my favorite mirror site and click the CD1 ISO. Boom. 490 kB/sec. Within a few hours I had all 5 ISO's, ready to burn, having picked 5 different mirrors for each CD. I quietly shut down Azureus, now at 12%, and went to bed.

So what have I learned from all this? Mirror sites still rock - many thanks are due to the mirror maintainers worldwide. For the next big Eclipse Release, we'll allow time for our mirrors to sync up before publishing links, and we'll publish links to mirror sites that host torrents. Will we make torrents available on eclipse.org? I don't think it's necessary.

So here it is...

I finally did it. A blog. Imagine that.

In the Eclipse community, I'd say I'm a listener. Wether through the hundred or so daily e-mails sent to webmaster@eclipse.org, the issues opened on Bugzilla, posts on the newsgroup or Ian blaring about in the office, my ears are wide open. But I have stuff to say too, and I figured I'd use this medium to, um, speak.

What prompted me to create this blog was what you'll read about in my first real post shortly. It'll be entitled "bittorrent blues" and it'll be related to the issues we had when Eclipse 3.1 was released. Let the fun begin.