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.
-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
