« Okay, I'll Bite: If I were GM | Main| Signing Off »

Busting an Xpages Myth: Performance (includes video)


If you think that Xpages are big and cumbersome and would be slow because they're all in Java, think again.  Watch this video for proof.

(continued...)






The Camtasia Studio video content presented here requires JavaScript to be enabled and the  latest version of the Macromedia Flash Player. If you are you using a browser with JavaScript disabled please enable it now. Otherwise, please update your version of the free Flash Player by downloading here.






MASSIVE PROPS to the Domino development team, who have clearly done a great job at getting some efficient code in 8.5.

Comments

1 - Who ever said XPages were slow?

2 - @1 - Lots of people who looked at architectural diagrams instead of actual results. But then, how could they do otherwise? It was only within the last couple of months that looking at results became possible!

Hell, I was one 'em, Bruce. I expected to have to throw a lot of hardware at them. But I'm delighted to say that I was wrong.

3 - Cool stuff my friend. I will be demoing the XPages version of IdeaJam on Thursday at the Northeast Ohio Lotus Group meeting.


4 - LOL nice optimistic tag cloud in the discussion db Emoticon

XPages are true badness. They're not lightning compared with, say, opening a straight view, but for all of their dynamic capabilities they really are very quick.

This is a real good blog topic, for sure - I bet many Domino developers' experience of Java is through applets, which definitely adds a feeling of chunk. Persistent Java, servlets, etc. can be lightning quick.

Now if IBM can just run a proper custom build on the appropriate Dojo components so that putting one on an XPage doesn't result in 60+ web server hits, they'll really have something special. I haven't checked Beta 2 for that yet though - maybe they've already addressed that.

More info here for the curious: { Link }

5 - @4 - Read the subjects more closely. Emoticon I'll give you a hint: Tim names all his servers after characters from Hamlet.

And I'm not so sure about the comparison to opening a straight view via the native HTML rendering. It'll be hard to without side-by-side stress-tested metrics, but the view rendering in the second application certainly felt faster than a standard HTML table from a view. It might be slower than a ?ReadViewEntries call, but I'm not certain about that.

6 - Manual trackback: { Link }

7 - @5 - Glad you mentioned that... I was hoping I was just missing something akin to a Shakespearean reference. Either that or Tim's got some serious goth angst. Emoticon I honestly haven't read/seen Hamlet. Leon english FTW.

I've done some side-by-side tests of an HTML view versus an XPage. The view is a bit faster but loading the icons in the HTML view tends to make things "feel" slower in a browser.

So yeah, the HTML view is slightly easier on the server and therefore faster. But, consider the pager in the XPage: To implement that with a legacy HTML view you're now talking about embedding the view on a form (more overhead), and/or using an agent (even more overhead), a subform, etc. The XPage performance catches up fast.

Nothing beats ?ReadViewEntries, though. But of course it doesn't do much other than spit out data.

8 - @7 - Lingering loyalty wins over all... maybe just 'cause you mentioned our alma mater.

"Rosencrantz and Gildenstern Are Dead". Run to Netflix or Blockbuster immediately. You will not be disappointed.

And, did you try output=JSON? I didn't even bother with that metric. Perhaps there's an output that trumps them all. Though at the margin, who cares? It's all about user experience vs. bandwidth workload in the end. Everything in between is just currency.

9 - I was wondering why no one had commented on your "Signing off" posting until I tried to add a comment myself so I'll add an off-topic comment to this posting instead.

Sorry to hear that you won't be blogging for some time (at least) as I've been checking your site continually as one of the (many, I suspect) silent ones who read on a regular basis but don't chip in. I have to say that you have contributed in no small part to strenghtening my resolve to stick with Notes development and to defend it in the face of some hostility. Knowing that Notes has people of your calibre and intelligence pushing it validates the platform for me.

Best of luck with the project in Orlando and with the next in line of T. Freemans

Eoin

10 - I would LOVE to see the xpage code for this guys! Is there ANY way that you can post it?

11 - uh guys, hate to throw cold water on this but seeing if something runs on really crap hardware is not a measure of performance. You won't find systemic bottle necks by counting "1 1000 2 1000" and staring at the screen :P Performance / stress testing is tough (really i've tried) because you really need to be hitting the box with reads / updates / deletes rapidly and from 10's or 100's of users in a big database to really know how the whole thing hangs together.


12 - Hi guys,

this sounds interesting...im tryin to research more abt this. If anyone can upload a demo database.. it wld have been gre8 help. Thanks in advance.

13 - Performance is nothing when the implementation and development tools are absolutely abhorently sub-standard.

What else would you expect from IBM? Domino Designer has not advanced even slightly with the introduction of XPages.

Not a day of XPages development passes without causing me a great number of headaches.

Post A Comment

:-D:-o:-p:-x:-(:-):-\:angry::cool::cry::emb::grin::huh::laugh::lips::rolleyes:;-)

11 Aug 

Hire Me 

Lotus-911-Logo.jpg

Search 

Disclaimer 

Welcome to Escape Velocity!

Opinions expressed here by Nathan T. Freeman are not necessarily those of his employer. However, there's a decent chance they are, so check with them if you really want to know.

But really... do you need that kind of validation? Are the opinions expressed here in doubt?

MiscLinks