Archive for March, 2010

Improving Performance in Flex and Scaling BlazeDS

Monday, March 29th, 2010

I gave a talk today at work about Flex and BlazeDS, and in particular how to scale both to perform well during high-volume, real-time communication with a Java-based server (in the area of thousands of messages per second). Here are the most helpful bits from my presentation and the ensuing discussion:

Stick to StreamingAMF.

When it comes to real-time data transfer, StreamingAMF is really your only choice for a high-performance endpoint. It offers two simple advantages:

  • Streaming connections allow for true push, rather than less-effective fast-polling.
  • AMF is a binary protocol, so less data is transferred across the wire.

If you need a more thorough round-up of endpoints, I highly recommend DevGirl’s excellent endpoint explanation.

Batch messages going through BlazeDS to save bandwidth.

BlazeDS adds significant overhead to each message sent across the wire. With thousands of messages per second, this adds up to a very significant amount of bandwidth usage, to the point that performance will be adversely affected.

To compensate for this, buffer consecutive messages together and send several at once. Even a simple timeout that buffers message content for 10ms before sending it all as a single message will save an incredible amount of bandwidth, and a smart buffer that adjusts its timeout based on message activity will do even better.

This is easy to implement, and likely the biggest performance optimization available in a high-volume situation. Definitely worth doing if bandwidth and performance are a concern.

Override default BlazeDS connection settings.

BlazeDS sets two interesting connection limits too low:

First, the <max-streaming-clients> property is used to limit the number of clients that can simultaneously stream from the same server. BlazeDS limits this to 10 by default, so if 11 users connect to your application at the same time, that 11th one won’t get through. This is a serious fault, but we can raise the limit as long as we’re smart about how high we set it.

The reason there is a limit at all is that all connections in BlazeDS use blocking IO. This means that the maximum number of connections Blaze will support is limited by the maximum number of threads in the application container, since it will always require one thread per connection. Fortunately, modern containers support much more than 10 concurrent threads; Tomcat 6, for example, reserves 150 by default and even that can be boosted.

So the rule of thumb here is that you don’t want your connections in BlazeDS to outnumber the threads in your container, and that’s what you should base this limit on. If you require more than a few hundred concurrent connections, you’re out of luck and you’ll have to either wait until Blaze implements non-blocking IO connections, or upgrade to LiveCycle.

The second, much-less-serious configuration is the <max-streaming-connections-per-session> property, which is used to limit the number of concurrent streaming connections a specified browser can support. If this number is exceeded, new connections will not open on the same client. BlazeDS defaults this value to 1 for all browsers, so if a user opens two instances of your streaming app at the same time, on the same machine with the same browser, the second instance will not open.

This limit is dependent on the browser, and many do actually have a hard limit of one single streaming connection at a time. However, newer versions of Internet Explorer/Firefox/Safari, most versions of Opera, and all versions of Chrome support multiple concurrent streaming sessions. To take advantage of this, override the limit in your services config; I’d suggest looking at Patrick Heinzelmann’s awesome RemoteServices example to grab the specific browser numbers and a nifty code sample.

Get low-level with Flash Player.

There are probably a lot of neat Flash Player performance hacks that I’m not aware of, but here are two I’ve figured out so far:

The default frame rate in Flash Player is not very high. I’m not entirely clear on what it is; I’ve seen some sources say 24fps, some say 12fps, and some say it’s completely dynamic. Depending on what you’re doing, you may consider boosting it to draw more often. In particular, this can lower the worst-case latency between a message being triggered, processed and displayed. The flip-side here is that a high frame rate will raise your CPU usage, so that’s a trade-off to keep in mind.

Secondly, for the longest time I was updating the screen whenever I had new data to display. In retrospect, this was ridiculous. How do I know if I’m updating more often than the screen is being refreshed? How do I know how long it will be until this update is actually blitten* to the screen?

A much less naive approach is to make screen updates on the ENTER_FRAME event. This is dispatched right before Flash Player refreshes the display, so it ensures that whatever you do here will be instantly reflected on-screen. As long as this is the only place you’re doing screen updates, you know that you are doing exactly one update per screen refresh, which is ideal provided you’ve calibrated your refresh rate to match how often you receive updates.

The Profiler is your friend.

After all the above tricks have been exhausted, if you still need a performance boost, there’s always code-level optimization. Things like unrolling loops and minimizing allocation using the “new” keyword will add up eventually. A good way to find out which areas will benefit most from such refactoring is to use the profiler that comes with Flex Builder.

The profiler will allow you to view object allocation stacks and method performance. The former is a great way to find memory leaks and the latter is fantastic for finding out which methods are the slowest and thus most qualified for optimization. If you have any curiosity at all about this sort of thing (and you should!) I heartily encourage you to open up the profiler and fiddle around with it a bit; it takes a bit of ramp-up but once you have it figured out it’s a totally indispensable tool.

Hopefully this will be helpful to someone out there. Flex and BlazeDS are both very well documented by Adobe, but these were the handful of cases where I had to go well out of my way to find workable solutions.

* blitten: Past tense of blit.

And the Clocks Keep Unwinding

Monday, March 22nd, 2010

I haven’t prepared a “real” post for this week. Instead, I offer you an excuse, an idea and an interesting problem — unrelated, but in that order.

I’m awful at writing exams.

I wrote my Flex 3 with AIR ACE exam on Friday.

I passed :)

Unfortunately, this meant devoting every ounce of my being for about six days to memorizing the entire API studying intensely. I’m still catching up on all the stuff I was actively ignoring last week, which includes “writing awesome blog posts” and “hunting for bears“.

We need more double-clicking.

This is something we take for granted, but as an input mechanic it’s pure genius. How can we make one button do two completely different things? Have it react differently based on the frequency of its presses. It literally doubles the usefulness of the left mouse button. Why haven’t we made this optimization on other controls? The only other case I can think of is how my iPhone thoughtfully fills in a period if I double-tap the space bar.

In particular, I’d like to see more double-key presses. I would love for my computer to pull up a shutdown prompt if I double-press my escape key. This is a key I rarely use anyway*, and it would save me the trouble of remembering whether I’m in Win7, XP, OSX or Ubuntu, not to mention which sub-menu they tucked it under. What about tab? Two tab presses could bring up Apple’s exposé, the Windows visual window manager du jour, or some experimental cube animation in linux. Maybe double-backspace deletes an entire word; and don’t even get me started on the power we’ve yet to unlock in our function keys.

Our input devices hold so much more potential than we’re using, we just have to think like the guy that invented the double-click. (Wikipedia currently credits this to the original Apple Lisa).

An unsolvable problem.

A common practice among interviewers in the high-tech circle is to ask the candidate for a solution to an unsolvable problem. Such problems are intended to drill down to the problem-solving skills a good candidate will hopefully have, and present an excellent opportunity for the interviewee to explore creative solutions, show attention to detail, and often demonstrate a sense of humour. I’ve always found these very interesting to answer, and today I propose one of my own:

Wikipedia will reject new page submissions about people who are deemed not notable enough to warrant their own entry. How could we find the most notable person that is not yet listed in Wikipedia?

This is something I’ve thought about a bit on and off, but if you have any insightful answers (practical or not) I’d love to hear them.

* I have been known to mash escape in vii and its gang of dangerous-to-abbreviate ‘CLI text editors’, where a double-escape mechanism would obviously be annoying. Maybe this would drive me to learn how to use the damned things properly?

Bears, Skittles and Google Buzz

Monday, March 15th, 2010

Google Buzz is like a laser gun that turns bears into Skittles.

That’s what I tell people when they ask me about Google Buzz. Much to my surprise, even without any further explanation they’re often less confused than they were to begin with. That alone tells you something about Buzz (it’s purpose is murky at best) and something about me (I’m clearly great with similes). Once you get past that, though, there’s some truth to it (really!).

The basic idea is that you can think of specific instances where it would be really useful (such as: you’re about to get mauled by a bear), but in general it’s completely useless. You can go way out of your way to find a good use case for Buzz, much like you can drive out to a forest inhabited by bears and spend all afternoon tracking one down, but that’s not how I like to spend my afternoons or my time online.

The problem I see with Buzz right now, is that it’s not as powerful as Google Reader, Twitter, or any other social tool, and it doesn’t offer any compelling features to help early adopters attract the masses. I’d simply rather read status updates and find neat links through other web venues. That’s not to say that Google got everything wrong here, and it’s not to say it has no potential — there’s just not a whole lot to like about Buzz right now.

What I would do with Buzz.

I think Buzz should aggregate everything from all my existing web communities, and let me filter it per-person.

If I’m wondering what my friend davefp is up to today, I should be able to pop into Buzz and instantly see any content of his that I can access in any of our mutual online spaces. His Twitter, Tumblr, Google Reader, blog; anything he’s got going on that I could check in each of those tools individually, right in one place. That’s when I would start Buzzing like a bee (again with the similes — sorry).

Obviously, it’s not easy to set up that sort of scenario, and you could argue that this is what Buzz is trying to do and that it’s just a few (light)years away — but the APIs exist for this! It’s just a matter of stitching them together in a way that’s coherent and seamless, and doesn’t take very long to set up, even if I have a lot of contacts on a lot of networks.

So that’s my take on Buzz. Now if you’ll excuse me, I have 8 different networks to dip in to, and some Skittles to snack on…

Aside: have you seen skittles.com lately? You should check it out — we need more designs like this.

Why HTML5 Makes Sense for Mobile

Monday, March 8th, 2010

These days there are more and more mobile devices that support rich software applications. Since the iPhone, we’ve seen the Blackberry, the Palm Pre and Android all start their own app stores, and surely Windows Phone 7 won’t be far behind. With all of these options, how do you decide which ones to develop software for? Porting the same native application to five different platforms is expensive, but only supporting a few adds the risk of alienating users with non-supported devices. Fortunately, thanks to HTML5, it’s now possible to develop one version of your application that works across all these platforms.

HTML5 is a new standard for developing web-based applications with rich interfaces similar to what can traditionally only be achieved in a desktop environment or by using browser plug-ins such as Adobe Flash. Support for HTML5 is being built right into all modern web browsers, with many features already available. While this is very good for the web community, it’s also very good for the mobile space; all modern smartphones come with a browser that is working to support HTML5. This means that instead of re-writing the same application for each mobile platform, one single version can be written in HTML5 that works across all of them.

The main motivation for choosing HTML5 is that the smartphone market is diverging, while support for HTML5 is converging. Each mobile platform in the expanding mobile space has its own API and distribution model, and any new platforms will likely follow suite. Contrast this with support for HTML5, where all these platforms are rushing to implement the same specification. How will this look in a few years? We will have even more platforms to develop separate clients for, but all of them will have increasingly better support for HTML5.

Another big reason for choosing HTM5 is that it has a strong, predictable future. In addition to picking up traction all over the web, the specification for HTML5 is mapped out to the year 2022, over ten years from now (but that doesn’t mean HTML5 is not ready to use right now). With the current smartphone market, it’s difficult to predict which clients will even be around in a few years, let alone which ones will still be popular. Using an HTML5 client removes much of the guesswork surrounding which platforms to support, and as it becomes the default standard for web browsers, any future platforms will support it as well.

There are other benefits to an HTML5 client, such as the control it grants you over your application. With the iPhone, for example, Apple must approve any change that is made to a native application, even after it is released. With an HTML5 application, there is no need for an approval process — in fact, it’s not even possible; device manufacturers and OS providers have no ability to regulate web content.

HTML5 is a great choice for mobile development in the current market. If you find yourself struggling to decide which platform(s) to develop for, or concerned about the future landscape of the mobile space, or unsure about having to seek approval from a manufacturer before your application can be deployed, consider the possible advantages of HTML5; it won’t be right for every scenario, but creating a native app isn’t either.

Note: This post is also available at http://www.macadamian.com/blog/post/why_html5_makes_sense_for_mobile/.

When not to Write a Post

Monday, March 1st, 2010

This is the fourth (!) post I’ve written for today. The reason you aren’t seeing the first three is because the past couple of days have taught me a few valuable lessons about when you shouldn’t follow through on a post idea (even if it’s a really good idea), and I thought I’d share that knowledge with all of you.

<tangent>This post was probably inspired in part by a recent similar post on Outspoken Media.</tangent>

Don’t bite off more than you can chew.

My first idea for this week’s post was massively ambitious. A popular site I follow posted an article last week about something I know a lot about, and didn’t do a very good job of it — and it was one of those dreaded list-posts where you can tell some of the items were just filler to boost the count up to a nice, rounded number. I was sure I could write a better post about the topic, so I got started! I was picking apart all the things the other article did wrong, doling out advice for how it could have been improved, coming up with my own, significantly better advice and conclusions, it was epic!

And then I read over what I had so far.

It was atrocious. My bold calling-out of a not-so-great post with examples of how to do it right was reading like a vicious tirade about why I’m better than they are. It was awful! Then I looked up the post’s author; he’s been blogging since I was in high school, has guest posts on some of my favourite blogs, and has made a hugely positive impact in his niche. What was I doing? This guy was a role model. So he had an off-post. It wasn’t all that bad, and even if I could find a few things wrong with it, that doesn’t translate to a better post — especially if I’m being a jerk about it.

So I trashed it. It was probably the longest post I’ve written for this blog to date, and I wholly regret wasting so much time on it before pulling the plug. On the plus side, I’ll think twice about it next time, and hopefully one of you will too.

Posts about current events can backfire.

My back-up idea for this week was based on a gem of a rant I went on over Skype when I found out that YouTube pulled the original RickRoll’d video for a Terms of Service violation. This was a solid post with some legitimately good content that I was all set to write — until I found out that YouTube restored the video.

This is the problem with such ephemeral topics. How long would that post have been relevant for? A few days? Then what? I update it to say “rejoice! the video is restored!” and the rest of my post is moot? Ridiculous. Next time I’ll remember to wait until the news is more official before assuming I’m set for next week’s post.

Are you really a good candidate to write this post?

My third idea was to write a post based on some story I found via Slashdot; one of those trendy posts about an ongoing saga of human rights dilution in a far-away land. This was obviously a good idea, because it was something I cared about! Not so.

What kind of insight would I have on such an issue? Sure I’m passionate about it, but so are millions of other people. Do I know more than the majority of them do? Probably not. Am I going to have some wacky angle that no one else has covered yet? I doubt it. Is there anything significant I can contribute in this space? Not really. So, no post. It was my fault for choosing a topic I was under-qualified to write about.

Please learn from my mistakes.

It’s been a long couple of days. It wasn’t easy throwing out idea after idea, especially after I’d invested time and energy into each one. But in the end I’m glad I did it; I didn’t publish something stupid that I’d probably regret later (or worse: completely forget about), and the silver lining turned out to be a handful of valuable lessons, ready for their own post.