Thanks Rickard for the prompt reply. >Very interesting and challenging post. Way to go! :-) Glad you liked it... :-) >Yes and no. In some cases EB's are faster if you use caching (*no* DB >hits if read-only.. it's all in the details..). There are some >interesting issues with clustered solutions (clustered caching), but I >believe that at least WLS and GemStone/J solves these in a good manner. >MSFT.. ah, never mind). Have you looked at ObjectStore's Javlin product? >If not, then maybe you should... Ok, we heard enough good things about Gemstone, theyre fedexing us the package right now. Javlin we have looked into, maybe we will use it in conjunction with the complete ObjectStore package which we might use to read data by hand. The caching architecture of object store appears quite sohisticated, it would apparently cache on the middle tier, which would be similar in performance to what you described up there. >Ok, breath deeply now, 'cause I've got a nasty one for you... >Does the data change "seldom"? >Is it vital for users to always have the latest view of data? The content almost never changes . But how it is presented and which content gests displayed and how, changes with >every< request. Sorry to say.... >If the answers are "yes" and "no" respectively I suggest the following: >There is an interesting getLastModified callback in servlets which can >be used by the webserver, browser and HTTP-proxies to determine whether >the content has changed or not. Usually one would check the timestamp of >a file, but it could be anything really. >One "interesting" way to use it is to always take the current time and >round off to the last, for example, 15 minutes. This means that if >serverside caching is used the page will only be generated once every >fifteen minutes, *dramatically* reducing the load on the server. I like >to call this mode of caching "semi-dynamic pages": they're not static, >but not fully dynamic either. Rather they are a good compromise which >can achieve any performance desired (depending on how often you >re-create the page). Once a minute is probably a good all-round setting. >This trick might be what you needed. errrrr.... id sleep better if this were our way to go. i know this technique and its great stuff for quite a bit of the sites out there. but our application goes beyond this. it basically never serves the same page twice. it would take too long to go into detail but it really takes some business logic to determine the components and then actually create the page that is then served. >Disclaimer: this requires that the servlet engine actually uses this >information to do something clever with. I don't know which ones that do >this. >Try it out and let me know how this works out for you. we will do it the hard way im afraid actually do all the logic required every time and just try and find the best tool performancewise, good caching, fast code etc. i will keep you informed how we will try and implement this, hopefully we can get some performance tests done this millenium and then i will post our findings..... >Question reality ok, will. thanks again for hints :-) Martin [EMAIL PROTECTED] Hamburg/Germany =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
