Hi!
Very interesting and challenging post. Way to go! :-)
Martin Friedel wrote:
> We have HTTPServers that deliver the static content such as GIF/SWF etc. and
> that pass on the requests for (our current approach) JSP/Servlets to a bunch
> of AS. (Here we are currently thinking of Weblogic primarily and are also
> evaluating Websphere) Are there any others that we should definitely look
> into?
Check out the current issue of CDS:
http://www.cutter.com/cds/
It has a very good and long article which compares different servers.
> Here we have our logic that defines what content will be displayed and
> which template should be used for this, who the user is (session management)
> and some system relevant stuff. Practically all our DB access is read access
> so we will use stateless session beans to read data and not entity beans
> (correct?).
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.
> On to the backend. We have an Oracle Database at hand which we can always
> fall back on, but were currently evaluating ObjectStore and Versant as a
> more efficient means of storage, since we have quite a bit of data that
> pertains only to the current session we think an odbms would be a viable
> option here. If anyone has tried using either of these in this context and
> thinks it stinks - addEnragedComplaintsListener( me );
The old "You can't get fired for choosing Oracle" syndrome (or was that
MSFT.. ah, never mind). Have you looked at ObjectStore's Javlin product?
If not, then maybe you should...
> So >each< HTTP request means: we use some servlets in weblogic utilizing the
> httpsession mechanism, access a few stateless session beans which read data
> from, lets say, OStore , and occasionally we use an entity bean to write
> some data.
> Now the problem.
> The current site which is horrid gets about 50000 >USERS< a day without the
> company actually pointing anyone to it, so as this will change soon, this
> number can be expected to rise to something like well... say 300000? worst
> case half a million users a day on special events. I have no idea how many
> hits this translates into... Now we cant tell the company buy a hundred and
> fifty thousand sun servers, or something along the lines of "the site is so
> sensational that even a response time of 45 seconds ist ok." We need some
> cool response times. We will have quite a few servers to handle this but at
> the price of a sun server its a difference wether we need 8 or 32.
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?
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.
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.
regards,
Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
Question reality
===========================================================================
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".
