Re: Barracuda Performance Questions

Hi Christian,

Thank you for your comments on the performance.

I am a newbie on Barracuda. I like lots of excellent
ideas it has. That is the reason I am posting
something here. At least, I learned a lot from just
reading some documentation on the site. I will learn
more for sure. 

I believe that Barracuda's performance on the
presentation layer is similar or better than those
commercial or opensource framework, such as
JSP/Struts/StrutsCX/.... For the most applications, it
is good enough just as you said. I may expect too
much. I chanllenged it because I hope it is better.

For example, for a web site has very large number of
visitors, the total number to parse Dom's nodes is
extremely large on server side. 

Although I don't like dom, I will study if I can make
a dom to do the thing I want. In that case, I can
maximize to reuse Barracuda's components. However, I
doubt I can do that since the specification don't fit.
Normally, I use my own small data structure. It is
much easier and more flexible, but not standard.

By the way, my toy example may mislead that I want to
parse a large dom file. I will care more about the
total number of visitors, so is the total number of
nodes to parse. In my experience, I only meet some
large data edi/xml files(more than 2MB) in supply
Chain Management applications. That is another type of
the problem.

I will look closely at Barracuda and ask more simple
quations on this list later. 

Could you please say something on Barracuda
events/forms? It looks a very complicated design.

Cheers,

Xue-Feng

 --- Christian Cryder <[email protected]>
wrote: > Hi Xue-Feng,
> 
> I've kind of come late to the discussion, so I'll
> just dive in and then let
> you ask followup questions as need be.
> 
> First a couple of generic comments on performance.
> 
> a) Barracuda's event model is highly optimized for
> performance, and should
> be thoroughly scalable (we tested it extensively
> when we first built it to
> ensure that)
> 
> b) Barracuda's component model should be
> _fundamentally_ scalable, although
> some of the things we currently do (ie.
> standard/default implications) still
> have plenty of room for optimizations.
> 
> In general, here are some areas in Barracuda that
> may impact
> performance/scalability.
> 
> 1. the Barracuda component bases everything on the
> DOM interfaces. As Jake
> pointed out, if you are fundamentally convinced that
> that is bad, well,
> there's not much we can do for you. Of course you
> could still use parts of
> Barracuda (events/forms) that are NOT related to the
> DOM, but the component
> model won't buy you much if you don't want to go te
> DOM route.
> 
> 2. that said, the Barracuda component model is NOT
> tied to a specific
> implementation of the DOM. SO...you could create
> your own DOM loader if you
> wanted to that had all the "static portions" of the
> DOM collapsed as a
> single node, and you could use Barracuda to
> manipulate just the dynamic
> portions of the DOM
> 
> 3. LazyDOM actually does this very thing, plus it
> gives you the added
> advantage of being able to expand those static nodes
> if you end up needing
> to. My understanding of LazyDOM is that unexpanded
> DOM nodes are rendered in
> one fell swoop - they are not expanded in order to
> be rendered.
> 
> 4. The reason Barracuda doesn't _typically_ benefit
> from the LazyDOM is
> twofold:
> 
> a) the default implementation of
> BTemplateViewHandler binds a single
> BTemplate component to the top of the page and
> simply parses everything
> underneath it. The advantage of this is that the
> developer doesn't have to
> know any specific tag names in the template (ie.
> separation of presentation
> vs. application logic). The downside is that this
> convenience means that
> everything in the page will get parsed and thuse
> expanded and thus LazyDOM
> is moot. The key here, however, is that this is NOT
> an architecural
> necessity of the Barracuda framework as a whole -
> its an implementation
> detail of a default case, which works very well for
> the majority of use
> cases. But you are totally free to implement a
> different strategy - the
> framework was designed to allow you to do this.
> 
> b) one of the other areas of slowness is the
> ElementFactory infterface -
> when you create a View on a node, it creates an
> ElementFactory for
> everything underneath that node, which means making
> copies of all the
> elements in the source template. SO...if you are
> using a BTemplate and you
> bind it to the top of the page, the whole thing is
> going to get cloned so
> that you have copies of everything hanging out in
> ElementFactory. This is an
> obvious performance penalty - the DOM will get
> expanded completely even
> before the components start rendering. Its my
> previously stated objective to
> remove this interface entirely, and this should
> result in significant
> improvements in performance. But right now, it _is_
> still an issue
> (tecnically). Interstingly, however, if you search
> the archives you will see
> that practically speaking there are very few people
> who are having problems
> with Barracuda performance. This is probably a
> result of the fact that the
> community is still relatively small (compared to
> something like Struts); but
> pragmatically, Barracuda performance hasn't been a
> problem yet. I will
> concede that it could be in certain situations (but
> that probably holds true
> for just about any framework). At least we're open
> and honest about it ;-)
> 
> 5. In the area of DOM size, my experience has found
> that browsers choke on
> really large DOMs before the server side processing
> does. So one of the very
> real implications of a DOM based approach (or rather
> an HTML based
> approach - the browsers convert the HTML to DOM
> internally), is that if you
> have hundreds of complex pages, HTML/DOM is going to
> be problematic on the
> client side - not because of the server technology,
> but because the browsers
> simply can't handle that big of a page. :-(
> 
> 6. On the server side, one of the things we have
> done to make it possible to
> _render_ really big DOMs is to create a
> BlockIterator, which basically
> renders the DOM out on the fly, creating/rendering
> BTemplates for individual
> blocks of markup, rather than trying to process the
> whole thing in memory.
> This allows for immediate streaming of content back
> to the browser. The
> _disadvantage_ of this is that Barracuda components
> cannot render into other
> portions of the DOM (to attach script components,
> etc). In other words, they
> are limited to the context of the block they are
> associated with in terms of
> what they can manipulate at render time. For
> reports, this is probably not a
> problem; for forms (ie. with submit buttons, etc) it
> wouldn't work.
> 
> Ok, so I've probably said enough. Feel free to
> comment as you see fit.
> 
> > Yes, of course. I am an expert on parsers and
> > compilers. I wrote some parsers on XML, EDI and
> Cobol.
> > I also a Senior Technical Architect on J2EE, and a
> > professor. I am very interested in to making some
> good
> > framework and its related
> (design/development/testing)
> > tools.
> 
> It'd be great to have you pitch in and contribute -
> I think you could
> benefit from Barracuda, and it sounds like Barracuda
> could benefit from you
> as well. I think as you spend time here you will see
> that we are _very_
> committed to performance and extensibility. We don't
> want to lock anybody in
> to any one particular way of doing things, because
> we realize that everybody
> has different needs. But we do want to make it easy
> for folks do do things
> with prebuilt pieces for commonly encountered
> situations. So you kind of
> have to distinguish between the architecture and the
> implementation as you
> evaluate Barracuda.
> 
> If you have any further question and comments,
> please don't hesitate to ask.
> 
> Cheers!
> Christian
> ----------------------------------------------
> Christian Cryder [[email protected]]
> Internet Architect, ATMReports.com
> Barracuda - http://barracudamvc.org
> ----------------------------------------------
> "Coffee? I could quit anytime, just not today"
> 
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf
> Of Xue-Feng Yang
> > Sent: Monday, March 17, 2003 12:31 AM
> > To: [email protected]
> > Subject: Re: [Barracuda] Why does Barracuda choose
> the way to parse the
> 
=== message truncated === 

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca