I hope you don't mind me saying so - and I know you will - but it sounds to me like you have a lot more problems than what your current web framework does/does not supposedly support.
I was afraid of as much while writing my last response on this thread but held back to give you the benefit of a doubt. The fact that you think there is "one" solution to your overall performance problem is even more disturbing simply because of the amount of enterprise experience you have under your belt. There is no single solution for all problems. There just isn't. There are "good" solutions for a set of very specific problems, but I've yet to come across any single software development concept / framework / methodology / etc that has solved all of my problems. In your particular case I'd make the bold assumption / guess that your problem has to do with one (or all) of the following: -) You aren't using the keyExpression type parameters that almost all Tapestry components interacting with any sort of model provide. This is just going to be huge in terms of performance impact on your application. -) Your database (not even getting into hibernate here yet) isn't being optimized/utilized properly. There is soooooooooo much more that goes into a good database design than just normalizing tables and giving them good primary/foreign keys/ etc... Each specific database vendor has very specific - and crutial - things that you can do to dramatically increase the performance of your operations against a database. I've personally witnessed one such specific scenario where a report that used to take almost 4 hours to complete was reduced to about 30 seconds with about 1 minutes worth of work from someone who knew how to use the database they were working with. -) You're not declaring the right kinds of optimization strategies with your hibernate entities. Besides the multitude of options available for each specific entity/properties of that entitiy/relationships into and out of the entity / etc there are also all of the many ways you can utilize your secondary cache to really make your application scream. I think if given enough time I could probably make any application perform reasonably fast in almost any modern(stable) web framework given to me. It's all in how you attack each problem one at a time. my 2 cents anyways.... On 12/6/06, Sam Gendler <[EMAIL PROTECTED]> wrote:
On 12/6/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > It's hard to tell which problem you are trying to solve through your comments. Well, I've got a lot of pages that just plain take a while (1-2 secs, with a max at maybe 5 seconds for one particularly nasty page that will eventually get some custom schema to alleviate the mess of joins) to collect all of the data necessary to render them, even without a form submission. I've also got an enterprise app where the data center is in Munich, but half the users are in the US and other distant locations, so I've got two problems to solve - general transfer latency of rich pages and compute latency. I need to nail both with a single solution. In most cases, I don't have the ability to render an empty page and then fill it in with ajax because tap just doesn't appear to be flexible enough in that regard, unfortunately. Rewind cycle strikes again. Trying to load up an 'empty' page which can then be populated with ajax is difficult because any form component that uses a complex model (table, property selection, etc) must at least have enough data in the model to be successfully rewound during the ajax request unless I want to store all the submitted values via persistence to the client or session so that I can render the page without any form fields at all, initially. That probably means a special version of the model which contains only the values I know will be submitted during the ajax request. To me, that's just architecturally ugly, since every page that needs a please wait notice must have custom engineering to support it, and the engineering required is different for every instance. That'll be both bug prone and time consuming. What I am looking for is something that can be applied at the framework or base class level (or added as a component, but I know that isn't going to work), so I don't have to go back and re-engineer a couple hundred fairly sophisticated pages just to get processing notices added to them all. The only solution I see, and one which appears to work quite nicely, is to use a servlet filter to provide a fake request to render a progress notifier and then replace that with the original request via a javascript redirect after the "please wait" notice is displayed. It handles all non-ajax cases except file upload form submissions and it can be easily enabled and disabled on a per-page basis declaratively through a number of methods - custom params in the request, special headers, path identification, and probably others. The only thing I don't like is that it is 'outside the application' since it lives in a servlet filter, but I can live with that. Sure, it will suffer a little for users on high latency connections (especially the folks down under), but so long as the processing notice is very small, it shouldn't be too bad, since the bytes transferred should fit within a single packet, if I'm careful. And the notice will be visible and remain visible whether the lag is due to network or server i/o. I'm just posting this so others can use the idea. I've already determined that the concept is sound. --sam > > The mention of a File upload area being a good place to have a wait > indicator would be a perfect scenario for the suggestion of throwing > up some sort of shared "wait" dialog via javascript. (as was outlined > in more detail previously) > > For data intensive things with potentially many nodes there are other > options. For instance, you will notice that the tacos tree demo does > exactly this. It renders the page out initially and displays a wait > cursor after that is completed while it fetched all of the data to > display all of the tree nodes, > http://opencomponentry.com:8080/tacos/ajax/TreeExample.html . > > I don't think you are going to find a solution that fits all > scenarios. (at least not one that works well from a user/developer > perspective) You may have to just treat each page on a case by case > basis. Probably more work but definitely a better experience for your > users. > > On 12/6/06, Sam Gendler <[EMAIL PROTECTED]> wrote: > > I think that functions by loading the page entirely without data and > > then firing off an ajax request to get the data. I'm seriously > > considering reworkgin my pages in a manner that alows this. By > > default, the page renders a page that does no work, including > > populating models and such. The content area gets wrapped in a great > > big div that can be replaced by an ajax request. When the ajax > > request fires, I can then populate the models, knowing that a please > > wait dialog is visible. The trick will be in ensuring that all the > > models are instantiated with at least enough data to rewind correctly > > during the ajax request - I'm concerned that doing that will be very > > labour intensive and may well require lots of custom code on every > > page, to take into account that page's particular requirements. > > > > I'm thinking I need to get really sneaky and do something with a > > servlet filter, such as intercepting all incoming requests, > > instantiating a new Request object which tells tapestry to render a > > page that does nothing but display a please wait dialog before sending > > an ajax request with a particular identifier in it. When the filter > > sees that identifier, it can replace the incoming Request object with > > the original Request object, allowing the page to render correctly. I > > have no idea whether this is truly feasible, but I suspect it is the > > only truly viable solution that works in all cases (except file > > upload, I imagine, which is a shame, cause that'd be a real handy > > place to have a pleae wait dialog). > > > > --sam > > > > > <snipped> > > -- > Jesse Kuhnert > Tapestry/Dojo team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
