RE: Barracuda Performance Questions

Hi Xue-Feng,

> Normally, I use my own small data structure. It is
> much easier and more flexible, but not standard.

So one possibility is to consider writing
a) a custom DOM Loader - to create a DOM from your structure
b) a DOM Wrapper - to make your structure look/act like a DOM

If you were to do that then the Barracuda components could work with your
"custom" DOM, which you could in turn use to significantly reduce the number
of DOM nodes. I've thought of doing this very thing for flat text documents,
thereby making it possible for Barracuda to manipulate a text file or .rtf
format. The key is making the document in question look like a DOM so that
Barracuda can work with it.

Of course, I know nothing about your data structure...maybe you can tell us
more?

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

Well, the Barracuda event model is fairly complex, but folks who take the
time to learn it generally tend to think that its actually one of the most
powerful portions of the Barracuda framework. In a nutshell, the event model
is resonsible for converting HTTP requests into first class even objects,
and then dispatching them to interested listeners (kind of like events in
Swing or other stated UI models). There are some key differences, however -
the Barracuda event model actually uses a 2 phased dispatching cycle. In
effect, events that come in as requests are "control" events - you write
handler code to process the event, react to user commands, load/manipulate
data structures, etc. You can have multiple handlers respond to a single
control event. At least one of those handlers must fire a "render" event,
which basically controls who renders the response to the client request. So,
in this sense, Barracuda is "Model-2"-ish in the sense that many other
webapps are.

Note that Barracuda events are defined with a hierarchy...events can extend
from parent events. One of the most powerful features of the Barracuda event
model has to do with 2 interfaces: Polymorphic and Exceptional. Control
events are Polymorphic, that is, every event is an "instance of" its parent
event. Here's an example of this:

Let's say your control event heirarchy looks something like this:

HttpControlEvent
    PublicEvent
        GetLoginScreen
    AuthorizedEvent
        GetAcctBalanceScreen
        GetPayrollScreen
        ...etc...

Ok, in a traditional web application, you don't want just anyone accessing
the acct balance or payroll screens, so you have to build logic to make sure
that a user requesting those pages is actually logged in and authorized. And
you have to embed that logic in every page that needs to be secured. This
becomes a maintenance nightmare, especially in the case of complex logic.
With Barracuda, you simply:

a) write an AuthorizedEvent handlers - if they are not authorized/valid,
fire a GetLoginScreen event

b) write separate handlers for GetAcctBalanceScreen, GetPayrollScreen, etc.

Now these separate handlers don't need to know ANYTHING about the
AuthorizedEvent handler. Here's why: when the user fires a GetPayrollScreen
event, every parent event is fired and dispatched first, because the
original event _is an instance of_ those parent events. So let's say some
programmer adds a new event called FireEmployee at the same level as
GetPayrollScreen...it automatically inherits all the event handling logic
associate with any events above it because it _is an instance of_ those
events.

Likewise, the View events implement an interface called Exceptional. What
happens here is that when you fire a View event, if there is no handler for
that event, then its parent event fires - this continues up the chain, just
like Exceptions, until someone handles it. THat's because HTTP requires that
we MUST send a response back for the given request. The Exceptional
guarantees that will happen.

This is quite useful when you have multiple screens that may all be backed
by the same model(s) but just use a different template. For instance, you
may have a view event hierarchy like this:

HttpViewEvent
   RenderPayrollScreen
       RenderAdminPayrollScreen
       RenderEmployeePayrollScreen

What something like this does is allow my control handler code to fire
different view events (depending on what type of user I'm dealing with, for
instance), but still only have one view handler (for GetPayrollScreen)...in
this handler, I have common models, etc; in the portion where I pass back
the template to be used, I check the "orig" event (RenderAdminPayrollScreen
vs. RenderEmployeePayrollScreen) and load a different template accordingly.

In the future, the event model will be expanded so that in addition to
simple extension, events will be able to "implement" other kinds of
events...effectively allowing logic for specific behaviors to be separately
coded and maintained in one place, and then to allow for other events to
automatically inherit that functionality simply by "implementing" the event
they handle.

A good place to go for more information on teh Event model is here:
http://barracudamvc.org/Barracuda/docs/events/high_level_overview.html

The Form model is also a bit complicated, but what it does is greatly
simplified once you understand its role. Basically, when someone submits a
request, all the parameters associated with that request come through as
String data. The Form model's job is to make it easy to automatically
convert those String objects into first class Java objects that your handler
code can easily work with - things like Dates, INtegers, Booleans, etc.
That's the main purpose of the Form model.

You can learn more about it by starting here:
http://barracudamvc.org/Barracuda/docs/forms/high_level_overview.html

Hope that helps!
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 1:06 PM
> To: [email protected]
> Subject: Re: [Barracuda] 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
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda