I am design a high volume system too and I suggest a "lighter/cheaper"
approach.
Each single http transaction in your system is to fetch a dozen records,
create a page and send it back, right?
Careful database design can make your queries work quite fast. If you
consider http is session-less why bother keeping a zillion record in the
application server?
I is generally faster to flood your database server with small querys
than read all the stuff at the same time. Each user will be requesting
different record sets, right? If your user will navigate for 2 hours to
request 200 pages and read 20000 records, is quite expensive to keep
those 20000 records in the middleware. Just keep them in the database.
Look carefully at each task your application perform. Each component in
your application shoud be designed to focus on the task and not
overburden the application and the database servers.
Have you ever worked programmed an Amiga or Apple II?
Different songs, same theme... Small is beutiful.
Karanjit Singh wrote:
>
> Craig R. McClanahan,
> Iam really thank ful to u for the time u devoted to answer my
> question.
> But my problem still remains I can have gibs of RAM but still I
> cant support the number of concurent users i want to support(in some cases
> can go upto 1000) and the some results can be million records.
> Regards,
> Karan
>
> >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >Reply-To: A mailing list about Java Server Pages specification and
> > reference <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: interesting one, 200 concurent users, large resultstes
> >Date: Wed, 2 Aug 2000 15:35:36 -0700
> >
> >Karanjit Singh wrote:
> >
> > > Yes i understand that i have to bring only 100 records to client ,
> >but
> > > when the client wants next 100 records from where will I get them on the
> > > server(i can find them only if i saved them somewhere on my server ),
> >only
> > > way is to requery the database and that is even more expensive in my
> >case
> > > becuse iam using 3 tier system, so everytime goin back to database
> >server is
> > > very expensive.
> > > regards
> > > karan
> > >
> >
> >I had a similar requirement on one application, and followed this sort of
> >an
> >approach:
> >
> >* Run the middle tier on a system with gobs of real memory (for me it was
> > a gigabyte, which was cheap relative to the value of the application).
> >Devote
> > lots of it to your JVM.
> >
> >* As records are accessed from the database, cache them in a Java
> >collection
> > of some sort that is stored as a servlet context attribute (i.e.
> >application
> >scope
> > bean for JSP). For me, we had already designed JavaBeans that mapped to
> > the underlying data so I cached the "bean" version rather than rows and
> >columns
> > from a ResultSet. This also avoided any need to keep database cursors
> >open
> > for longer than necessary.
> >
> >* To make sure that the cache is up-to-date, run a background thread that
> >is
> > checking for cached rows that have been changed or deleted, or that have
> >been
> > in the cache to long (the data I was dealing with was time-sensitive,
> >and has an
> > "interesting" lifetime measured in minutes to hours).
> >
> >* When doing a query, use the normal database facilities (some of my
> >"where"
> > clauses got quite intricate) to make sure that the results are always
> >accurate
> > no matter whether the actual data is cached or not). BUT, retrieve only
> >the
> > primary keys of the result records. Now, of that set of keys, some of
> >the
> >records
> > are already in the cache and some aren't. For the ones that are, just
> >add
> >references
> > to them to an ArrayList or Vector. For the ones that aren't, go read
> >them from
> >the
> > database (and cache them) as you add them to the list.
> >
> >* As you do update transactions, be sure that you update the cached version
> >of the
> > information as well as the underlying database.
> >
> >The net effect of all this was that the cache contained the data that has
> >been
> >retrieved or modified recently, which tended to be accessed frequently for
> >a while
> >and then not at all later. This works pretty well as long as you can
> >afford enough
> >memory to keep this "recently accessed working set" of data in the cache,
> >which was
> >true for me. It also let me scale to multiple middle tier servers that
> >accessed
> >the same back-end database -- primarily because I did not require
> >up-to-the-second
> >accuracy of the search results, so I could ignore the issue of
> >synchronizing the
> >various caches.
> >
> >I hope some of these ideas might be useful in your app design.
> >
> >Craig McClanahan
> >
> >===========================================================================
> >To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> >JSP-INTEREST".
> >Some relevant FAQs on JSP/Servlets can be found at:
> >
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
> ===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
