You are making some wild assumptions. My only performance problem is waiting for some potentially latent web services to return some data in real time and in performing some really huge db queries on an already overworked database server. None of those slow loading pages are spending any significant time in Tapestry. You are also making some assumptions about my own professional skillset without knowing the slightest thing about it. My database optimization skills (coupled with those of a DBA, at least), are more than sufficient in keeping the database running at peak efficiency. But it is simply the nature of the application that some of the queries (reports) being run require some time in the db. It happens sometimes. And the web service latency is out of my hands, other than to implement a caching strategy, but that isn't compatible with the business model or our partners. The problems aren't intractable, but nor are they trivial to solve in an architecturally clean manner.
Regardless, I have a requirement that is out of my hands which states that EVERY page should display a notification while the next page is loading, no matter how short or long that process may take. Pointing out the animated browser icon didn't satisfy the requirement from PM, so now I'm solving the requirement by implementing the feature. It's not as though every page in the app is so slow as to require the notice, but what PM wants, PM gets.
From your assumptions, it seems likely to me that you have no
experience with an application on the scale of the app I am building. This is a core enterprise application that is supporting a multinational corporation and handling the data from several hundred million hits per day in a system that is scaling up by several tens of millions of impressions per day every week. It is both internally and externally facing, is internationalized into multiple languages, handling reporting on data that is well into the billions of rows, and is functioning across a cluster of many tens of hosts, multiple db servers, caches, file servers, CDNs, and with webservices integration as both client and server. For you to make any assumptions about the structure or efficiency of my application based on a couple of emails to a mailing list is a hell of an imposition, quite frankly. I certainly don't have any idea where you get the impression that I am not using key expressions the way they are intended to be used in Tapestry, that my dbs are suboptimally configured or that I am using a suboptimal hibernate config. As it happens, the app is still fairly immature, so the hibernate config has been left intentionally simple in order to avoid premature optimization, but hibernate isn't the source of my performance problems, in any case. I've got maybe 10 pages in the entire app that take more than 300 ms to render, with maybe 3 of those over 500ms. The biggest problem, quite frankly, is merely dealing with transoceanic or (god forbid) satellite latency, something that I'm guessing isn't a problem you've had to deal with directly. When you combine that latency with an occasional lag populating a model for a component, you get a situation where PM has decided that they'd prefer to remove any doubt that the system is working while the user waits You seem to be under the impression that I'm some kind of novice programmer who is just learning how to build a webapp. Let me disabuse you of the notion. I've been neck deep in high performance web and network technologies for 11 years now. I was the architect on the team at Cisco systems that built the first high performance HTTP proxy appliance and invented the protocol that allows transparent caching on the network (whether you are fond of the idea or not, it is a useful performance enhancement). I then spent a number of years at Akamai, as the architect reponsible for building their dynamic content assembly service from scratch. I spent time at Software.com/Openwave building highly scalable email systems (these are the servers being run by tier 1 isps around the world) somewhere in there, too. I am very familiar with many of the methods needed to extract every once of efficiency out of a network application, and I certainly continue to pick up useful new information, but learning the necessity of optimizing a db config and schema isn't exactly news. --sam On 12/6/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
