Thursday, January 20, 2011

64Bit Firefox Deployment Complete

There is always an unknown when you deploy new software to hundreds of people. All of your testing never simulates their techniques and a full load. But yesterday the cutover to 64bit Firefox 4 on the new server went beautifully. We announced the upgrade and at noon I just killall'd their processes on the old 32bit server and moved the binary out of the way to halt it from running. I then tar'd up all of their .mozilla directories, and extracted them on the new 64bit replacement server. I changed the global launch scripts and was done. The total process took about 15 minutes.

The shots below are the 'top' windows with about 65 users with Firefox sessions running. Watching the load split on the threads is a thing of beauty and scrolling is as crisp as it was with just our beta testers. There are a few spikes in the 5-8% busy area, but the bulk of the time it sits under 1-3%. I believe this server could easily get 300-400 users on it concurrently. Very nice. Another item off my list. :)

Here is the link to the server.







6 comments:

Unknown said...

Dave, another excellent post to an excellent blog. A quick question, do you speak at open source conferences? If so, we'd love to have you speak at POSSCON 2011 about what you're doing for the City of Largo. Please contact me at todd@posscon.org if you're interested. Again, great blog - and keep up the good work.

Anonymous said...

Dave, my apologies this question is off-topic to 64-bit Firefox, but it is on topic with regard to Linux thin clients, and this is the only way I know how to contact you with this question.

The question is does your Intel integrated graphics handle 3D desktop effects without issues?

Three years ago with g33 integrated graphics, and the Intel X stack of that era (from a pre-release version of Debian Lenny) I found I could ssh to another machine on my LAN (0.1 gigabit at that time) and run the likes of foobillard and tuxracer with acceptable framerates. Yesterday, I tried that same experiment (this time with a 1 gigabit LAN but still using the same g33), and foobillard frame rates had slowed to about 1 frame per second. This result was with the Intel X stack you currently get with Debian testing. A local run of foobillard had completely acceptable framerates so it appears 3D and openGL display are working fine on the g33 for local apps.

I assume you have had success with similar experiments because 3D desktop effects are important these days. So the question may evolve to what special configuration of ssh is required to get acceptable framerates on 3D apps that are run remotely?

Alan W. Irwin

bestouff said...

Profit before X11 is replaced by Wayland!

Dave Richards said...

@todd: Got the email you sent. I'll talk to our Director and get back to you. We will discuss resources and funding. Thanks for the offer, let's see what we can do.

@alan: If you read my older blogs you can see my 3D testing. The HP 5745 thin clients we are buying now are Intel based. What we found in the past is that Compiz and effects work great over remote display, but only in 16 bit color. 24 bit color works 1024x768, but higher than that and it's sluggish. Based on some recent trends, we are moving away from 3D effects on the new desktop. There is a big push for tablets. more remote options and resumable sessions. We just got our first iPad for testing as a thin client with NX 4. So we are going to focus on a consistent desktop interface that runs well over lower bandwidth 3G and 4G type cards; which makes 3D effects less important. The other issue is that there are only so many hours in the day to work on technology, and moving to tablets will take some of my time and QA work, so we needed to pull back on certain non-critical technologies.

@bestouff: I'm not sure that any technology that loses the network features of X are an 'upgrade'. If X really goes away, we will have to look at running most host based sessions with NX.

Anonymous said...

Thanks, Dave, for your reply on 3D effects. I was aware of your older 3D tests, but those were with some non-Intel video card, IIRC with the old efficent X stack. Although you are apparently moving away from 3D effects on the desktop now, if you have any of that functionality left, I suggest it would be worth your while to do some efficiency tests with your new Intel-based graphics and the new X stack you get with say Debian testing. For example, if HP updates to Debian testing for their thin clients, you may suddenly find the rug pulled out from underneath you by impossibly slow 3D effects. Anyhow, that is my current experience with Debian testing and Intel graphics chips. I believe I am already using 16-bit color, but I will double check. Of course, your good experience with that for the old X stack may have been due to some quirk of the non-Intel driver you were using at that time.

Anonymous said...

Just to finish off this topic, somebody on the Intel-gfx list finally clued me in that you have to set

export LIBGL_ALWAYS_INDIRECT=1

on the remote box running the 3D X client (such as foobillard). It's frightening that the experienced 3D Linux users that hang out here (including me) didn't have a clue about LIBGL_ALWAYS_INDIRECT. In addition there seems to be no fundamental documentation of this important environment variable (say in a man page).

Setting LIBGL_ALWAYS_INDIRECT as above made foobillard smoothly playable from my X-terminal. However, etracer (extreme tux racer, the successor to tuxracer) is still not playable (using the mouse to select menu items was almost impossible) even when LIBGL_ALWAYS_INDIRECT is set to 1. Thus, there still seems to be a real regression in how efficient the Intel X stack is for displaying remote 3D applications compared to when I last tried a tuxracer test of this capability three years ago.

Alan W. Irwin