Tag: Flex

Categories
Web Technology

Brand New Adobe

Adobe is changing. The once-great giant of web and web tools has fallen, and is poised to rise again — albeit in a much different form. What does this mean for us web developers?

For starters, let’s go over some recent news. Adobe made three major announcements in the past six weeks that will have sweeping implications on their image. See if you can spot a trend in these headlines:

What do these press releases have in common? If you caught that all three are about open technology, give yourself a pat on the back. Let’s dig into the facts before discussing the ramifications.

Adobe has seen the light, and open source is sparkling.

Closed formats are dying across the web. The days are numbered for plugins like Silverlight and Flash; they’re simply not necessary anymore for the vast majority of sites and applications. HTML5, on the other hand, is thriving. We’re starting to see open fonts pick up, and even longtime-stalwarts MP3 and MPEG-4 are starting to lose their grasp of the online audio/video markets.

Adobe isn’t blind. They know they need to transition away from closed platforms. Picking up PhoneGap shows their commitment to this cause.

Re-aligning their mobile efforts towards HTML5 is another positive step towards open technology. Adobe still makes some of the web’s best tools, and Javascript development could seriously use an outstanding IDE. This seems like a great match-up.

Finally, releasing Flex to the community is a smart move. There is a very vibrant community around Flex, and there are still niches where RIA will matter for a little while longer. If Adobe can’t support Flex on its own, enabling the community to take control of it’s own future simply makes sense.

Adobe’s intentions are clear. Proprietary formats are out, the open web is in.

What does this mean for web developers?

Three things:

First and foremost: Learn your shit. If you’re a web developer, learn everything you can about Javascript, HTML5, CSS3, and the myriad of related frameworks. These will only become more important following the fall of Flash.

Second: If you’re a Flash/Flex dev, start looking at Sencha. At SenchaCon last month, the number-one answer I got back when I asked people what they worked in before switching to Sencha was Adobe Flex. And I believe it. I’m a Flex guy too, but that market’s shrinking quickly. Sencha is going to be a major player on the web for a while to come, and it’s a relatively smooth transition.

Third: Get into mobile. Adobe didn’t pick up PhoneGap just to gain FOSS-cred. Mobile is huge. Huge! This is where you want to be right now, and you can join in using Javascript and Sencha and many other web technologies.

This is an exciting time to be in web development. Let’s keep on top of the constantly-changing platforms and tools. Let’s keep building wonderful things. Let’s make this an age to be proud of when they talk about the day Adobe changed their ways.

Who’s with me?

Categories
Software Development Web Technology

Improving Performance in Flex and Scaling BlazeDS

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.

Categories
Uncategorized

And the Clocks Keep Unwinding

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?