Re: WO Performance...
Re: WO Performance...
- Subject: Re: WO Performance...
- From: Bob McCormick <email@hidden>
- Date: Fri, 24 Oct 2003 13:40:30 -0700
Hi Colin,
On Friday, October 24, 2003, at 06:33 AM, Colin Clark wrote:
Hi Bob,
I've been following your threads on the WebObjects-dev list and notice
that you seem pretty concerned about your decision to use WebObjects.
Actually, I feel pretty good about WO in general - if I come across
with Buyers Remorse, it's not intentional. I just want to be sure that
I don't get into habits early on and then have to redo major portions
of my application. Been there, done that and decided this time to ask
knowledgeable developers when a question crosses my mind. The
incredibly long thread initially truly was about how to handle HTML vs.
WO in the same batch. I have to say, I'm still a bit fuzzy on it as
the thread took a tangent on performance.
In terns of performance, I think you'll find it more appropriate to
worry about performance later on in the development cycle of your
application. As with any project, it's problematic to try and tune
before you've implemented at least the basic functionality and are
able to profile the specific behavior of your application. Due to the
level of abstraction at which EOF developers generally work, it's much
more productive to define the functionality and then profile and fix
the fetching behavior afterwards. Small iterations work well for
performance tuning.
OK, that sounds reasonable. I just got to thinking about previous
projects and had good luck simply using straight HTML based pages for
everything that wasn't dynamic. Since we had to manually track the
session anyway, it wasn't such a big deal. If I'm understanding
correctly, with WO I don't have to worry very much about session at all
if I don't want to, (which saves a lot of development time) and things
just get handled. Way cool, and there's a major Pro for keeping all
things WO for fast development efforts, but then I made performance
question out of idle curiosity since if WO is pretty fast, then maybe
the HTML only pages become moot except in a very large system with
millions of hits a day.
In terms of database access, if you read the WebObjects EOF
documentation it should be clear that the naive out-of-the-box
fetching strategy that EOF uses is rarely appropriate for most
applications without further adjustments. A knowledge of how to
properly and quickly fetch your data objects comes with understanding
specific details about your domain, your database design, and the
kinds of problems you're trying to solve. EOF can't possible know how
intelligently fetch your data without you providing that extra
information. You do that by making decisions about batch faulting,
prefetching, and using raw row fetches where required. EOF is designed
around an object cache that if used correctly will make your
application significantly faster than if you used continuous
round-trips to the database. For example, I notice that once my
application has been primed--ie. a certain amount of data has been
fetched up front--pages the fetch large graphs of related data can be
blazingly fast when reading from the cache.
To be honest, I've skimmed quite a bit of these techniques and so will
need to dig in to see how this all works. It sounds good, but I still
tend to think that all things should be Stored Procedures, then you can
tune on the back end to your hearts content and it always be faster as
a stored procedure than any code you write up front. Only negative
there is that you lose the ability to easily swap out the database, but
I've decided that FrontBase looks pretty darn impressive in
performance, and also it will run on any OS that I'd wish to use. So
portability isn't such a big deal to me at this juncture.
As for WOF and the speed of the templating engine, I think it's quite
fast as it is. If you find as you develop your application that your
page rendering times are too slow, there are certainly options open to
you. Petite Abeille's point about the possibility of using WOF
templates to generate semi-static pages server by the Web server is a
good one. I have easily integrate static HTML pages into my WOApp
(that's what the WebServerResources folder and a split-install is for)
when creating content that never changes.
Yes, this does sound like something I'm going to investigate further,
AFTER I get a bit more of WO under my belt. heh. Feeling really dumb
these days in getting my head around this product. Inherently, I know
that this is good stuff - just getting it all lined out has been
extremely chewy. (Ever give a dog a peanut butter sandwich? That's
about how I feel - man this is good, but I JUST can't get this off the
roof of my mouth to REALLY enjoy it.) ;-)
WebObjects and EOF are very dense, complex, and flexible frameworks.
They take a _long_ time to learn. However, due to the framework
design, rapid application development can be a real joy. It's a breeze
to put together a working set of component and application code in a
few hours. The result, though, is that the framework inevitably
establishes a basic flow and behavior that won't always suit your
application's needs. There are a number of hooks in the framework in
order to change it's out-of-the-box behavior. The challenge is to know
when and how to do this.
I hope that helps explain some of your concerns,
Sure, every little bit helps believe me! I really appreciate what you
and everyone else has shared on this list. I'd be a lot LESS farther
down the road than if I didn't have the list to bounce things off of.
Best regards...Bob
Bob McCormick
XebraTech
(805) 302-3359
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.