On Jun 1, 2009, at 7:12 AM, Tim Funk wrote:
Worrying is good. Making sure you have metrics is better. You can
cache lots of different items such as
- stuff from the database
- parts of a rendered page
- the entire page
- any combination of above
But it really depends on where the bottlenecks are as you scale.
Even if the DB has a few million entries, if there queries are
"simple" and the database has enough memory - the database might
never really be touching disk to return the results of your query
not be your bottleneck.
The key is making sure you have the ability to log how long differnt
things take. (And the ability to turn them on or off) Otherwise you
are flying blind.
I think you can generally say that the less you have to do on the
server, the better. If you can generate out a page *as much as
possible* so that only the really necessary dynamic components are
created at runtime, then it is better.
We use XSL/XML to pregenerate a JSP bringing all known page content/
components.
I don't see why you would be flying blind. Seems like a no-brainer.
best,
-Rob
-Tim
Andre-John Mas wrote:
Hi,
Much of the content on the site which I am in the process will be
semi-static, and I want to be able to cache the rendered pages to
reduce database hits. To explain:
A given page will depend on dynamic data that is stored in the
database, but that data is updated about once a month. The only
true dynamic information will be the header where the user login
state is shown. There will likely be a few million entries in this
database and we are planning to support high traffic. The pages can
be localised. The page is going to be queried as such:
http://myhost.com/myapp.action?id=12345678
Although I am using a direct JPA access, we might change to use web
services in the future.
Am I worrying unecessarily? At the same time are there recommended
approaches. I am currently using struts2 and JPA for the web site,
if it makes a difference.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
