Re: Caching rendered page - reducing hits to the backend?
Have you already measured the performance of your application and determined that caching the rendered pages is the appropriate thing to do - ie how have you determined that database access is the bottleneck? If not, caching page content may just hide a multitude of performance related sins. JPA's built-in caching may already provide enough in the way of performance improvements to make an additional caching layer pointless. Is the database on a different machine or the same one and are you clustering Tomcat? You're probably worrying unnecessarily. p Markus Stauffer wrote: like this: http://www.opensymphony.com/oscache/ ? Am 30.05.2009 um 21:51 schrieb Andre-John Mas: 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. André-John - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Caching rendered page - reducing hits to the backend?
On 2-Jun-2009, at 04:37, Pid wrote: Have you already measured the performance of your application and determined that caching the rendered pages is the appropriate thing to do - ie how have you determined that database access is the bottleneck? If not, caching page content may just hide a multitude of performance related sins. JPA's built-in caching may already provide enough in the way of performance improvements to make an additional caching layer pointless. Is the database on a different machine or the same one and are you clustering Tomcat? You're probably worrying unnecessarily. I think I may end up simply ensuring that the database has enough memory and slowly evaluate where the bottle necks are. What I will do at the same time is have a number of points to watch out for, with possible solutions. I will also make sure that the last results for the search are cached in the user session. André-John - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Caching rendered page - reducing hits to the backend?
From: Andre-John Mas [mailto:aj...@sympatico.ca] I think I may end up simply ensuring that the database has enough memory and slowly evaluate where the bottle necks are. It's often the best approach. You can spend a lot of time optimising places that turn out not to be the bottleneck. You can also spend a lot of time testing a new app, only to find out that the real usage patterns aren't like that at all and you suddenly need to optimise one operation that you never thought would be used heavily! - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Caching rendered page - reducing hits to the backend?
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
Re: Caching rendered page - reducing hits to the backend?
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
Re: Caching rendered page - reducing hits to the backend?
On Mon, Jun 1, 2009 at 1:37 PM, Robert Koberg r...@koberg.com wrote: On Jun 1, 2009, at 7:12 AM, Tim Funk wrote: 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. Funny :-) I remember removing xml/xsl generation from the chain and replacing it with jsps a while ago. Brought about factor 10 performance (from 50 ms rendering time to 5). So I second TIm's statement: measure first and measure after. And compare :-) Leon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Caching rendered page - reducing hits to the backend?
On Jun 1, 2009, at 8:08 AM, Leon Rosenberg wrote: On Mon, Jun 1, 2009 at 1:37 PM, Robert Koberg r...@koberg.com wrote: On Jun 1, 2009, at 7:12 AM, Tim Funk wrote: 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. Funny :-) I remember removing xml/xsl generation from the chain and replacing it with jsps a while ago. Brought about factor 10 performance (from 50 ms rendering time to 5). So I second TIm's statement: measure first and measure after. And compare :-) No. It is not in the chain, well, not in the runtime chain/pipeline. It is generated before you even put it on the live server. -Rob Leon - 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
RE: Caching rendered page - reducing hits to the backend?
MGhopefully brief comments From: r...@koberg.com To: users@tomcat.apache.org Subject: Re: Caching rendered page - reducing hits to the backend? Date: Mon, 1 Jun 2009 07:37:56 -0400 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 MGconnection pools can handle multiple connections with little or no startup load - parts of a rendered page MGtiles/div tags/frames whats your preference? - the entire page MGi assume you're referring to caching jsp's at the server? - 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. MGcorrect the less I/O the better MGthis is a good design for static reporting MGbut may cause bottlenecks for highly interactive websites 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) MGdefine 'them' Otherwise you are flying blind. I think you can generally say that the less you have to do on the server, the better. MGoptimising server code and algorithms is always a good idea MGdumping proprietary algorithms, validation and or lookup code to client not good If you can generate out a page *as much as possible* MGXSLT? so that only the really necessary dynamic components are created at runtime, then it is better. MGyou want to characterise startup load vs resolve runtime classes,entities MGcarefully We use XSL/XML to pregenerate a JSP bringing all known page content/ components. MGas do most templating engines e.g. Velocity and freemarker I don't see why you would be flying blind. Seems like a no-brainer. MGdepends on who is piloting the craft? best, -Rob MGbest, MG -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 _ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_BR_life_in_synch_052009
Re: Caching rendered page - reducing hits to the backend?
On Mon, Jun 1, 2009 at 2:12 PM, Robert Koberg r...@koberg.com wrote: No. It is not in the chain, well, not in the runtime chain/pipeline. It is generated before you even put it on the live server. -Rob I am not judging your solution, just saying that there are not general rules except for one: measure what you do, measure what you've done :-) :-) regards Leon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Caching rendered page - reducing hits to the backend?
like this: http://www.opensymphony.com/oscache/ ? Am 30.05.2009 um 21:51 schrieb Andre-John Mas: 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. André-John - 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
RE: Caching rendered page - reducing hits to the backend?
From: Andre-John Mas [mailto:aj...@sympatico.ca] Subject: Caching rendered page - reducing hits to the backend? I want to be able to cache the rendered pages to reduce database hits. Wouldn't that be the function of a Java bean? Am I worrying unecessarily? Hard to tell without taking measurements of your environment with your expected load. The only generality is that there are no generalities (well, very few). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
