Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
aiken
Aged Yak Warrior
525 Posts |
 Posted - 2002-08-09 : 15:37:30
|
| Ok, on to another question. My application is web based, and virtually every page has a navigation bar which is customized for the user. The app is pretty smart, and implements caching for data which is shared across users.However, it occurs to me that the navbar always entails one round trip to the SQL server before the page is even started.Many of the pages in the app use a single stored procedure, which may itself run 5-10 other SP's, to gather their data. From a performance standpoint, it seems that incorporating the navbar SP into the beginning of each page's SP would eliminate one round trip (helpful in general, but especially nice for our backup web server location, which is cross-country from the database).Anyone have any thoughts on the app design issues there? It's certainly uglier to have one SP hardcoded into the beginning of 50-75 other SP's, but it would eliminate that round trip...I'm not looking for word-of-God advice here; I realize the answer is almost certainly "it depends." What I'm looking for is opinions about the correctness of implementing this performance hack.Thanks-b |
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2002-08-09 : 15:45:31
|
| Unless the navbar's contents change drastically when used, why not put the data into a cookie? You could then persist it for at least the duration of the session, if not longer, and if need be add a feature to refresh the navbar on demand. You could even utilize client-side code to build the navbar if the browser(s) you support have decent DHTML capabilities, but that's only if you really want to get fancy.For storage, you could use a CSV to separate menus and menu elements and split them into an array, or put the entire HTML of the menu system in the cookie if it's not too big. |
 |
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2002-08-09 : 15:47:36
|
| I think maintaining and implimenting such a solution would be a bear.I'm not sure how easy it is to return multiple "recordsets" from a single stored proc, but I'm sure it's a bit more complicated than normal.You also have to keep in mind your INSERT/UPDATE stuff. Those don't need your Navbar probably. Keeping track of which SP's need the NavBar stored proc would also give you a few headaches.Do you call your stored procs inside of your ASP pages, or do you use a COM object to call them? Are the COM objects in COM+?If you are able to take advantage of connection pooling, I really don't see where you will get very much of a performance boost. Very little gain for a TON more work and maintenance headaches. I'd keep it separate.Michael<Yoda>Use the Search page you must. Find the answer you will.</Yoda> |
|
|
|
|
|
|
|
|
Best practices: combining SP's?