Screen widget caching
Locked
 
|
Hi all,
I'd like to discuss with you all about the idea of implementing screen widget output caching. Goal: minimize the db/service hits for rather static screens (for example a category or product detail screen in the ecommerce); this could be done by implementing screen widget output caching that prevents the screen widget actions (and possibly ftl) from running Draft/proposal for implementation: a) add new attributes in the screen definition for cache settings (e.g. cache="true|false" etc...) b) the cache key can be derived from the screen name and the "parameters" map (the output UtilHttp.getCombinedMap(...)) that represents the input context for screens c) associated to the cache key we will cache the final output of the screen (html code or xsl-fo code...) d) if the cache is enabled for a given screen, the input "parameters" map is used as a key for the cache system, if no value is found, then the screen (actions + froms + ftl templates) is run as usual and the output is rendered and stored in the cache (with key screen name + "parameters"); if the value is found, then the output is retrieved from memory and sent to the user (no actions and ftl are executed) A different option would be that of storing the output context in the cache and serve it to the ftl (instead of storing the output html/xsl-fo). I'd love to get your feedback about this, ideas/concerns, Jacopo |
|
|
I think caching the widgets themselves might offer an improvement. I have no opinion on the other items.
-Adrian Jacopo Cappellato wrote: > Hi all, > > I'd like to discuss with you all about the idea of implementing screen > widget output caching. > > Goal: minimize the db/service hits for rather static screens (for > example a category or product detail screen in the ecommerce); this > could be done by implementing screen widget output caching that prevents > the screen widget actions (and possibly ftl) from running > > Draft/proposal for implementation: > > a) add new attributes in the screen definition for cache settings (e.g. > cache="true|false" etc...) > b) the cache key can be derived from the screen name and the > "parameters" map (the output UtilHttp.getCombinedMap(...)) that > represents the input context for screens > c) associated to the cache key we will cache the final output of the > screen (html code or xsl-fo code...) > d) if the cache is enabled for a given screen, the input "parameters" > map is used as a key for the cache system, if no value is found, then > the screen (actions + froms + ftl templates) is run as usual and the > output is rendered and stored in the cache (with key screen name + > "parameters"); if the value is found, then the output is retrieved from > memory and sent to the user (no actions and ftl are executed) > > A different option would be that of storing the output context in the > cache and serve it to the ftl (instead of storing the output html/xsl-fo). > > I'd love to get your feedback about this, ideas/concerns, > > Jacopo > > |
|
|
Apply cache in services or entityes
2007/7/17, Adrian Crum <[hidden email]>: > I think caching the widgets themselves might offer an improvement. I have no opinion on the other items. > > -Adrian > > Jacopo Cappellato wrote: > > Hi all, > > > > I'd like to discuss with you all about the idea of implementing screen > > widget output caching. > > > > Goal: minimize the db/service hits for rather static screens (for > > example a category or product detail screen in the ecommerce); this > > could be done by implementing screen widget output caching that prevents > > the screen widget actions (and possibly ftl) from running > > > > Draft/proposal for implementation: > > > > a) add new attributes in the screen definition for cache settings (e.g. > > cache="true|false" etc...) > > b) the cache key can be derived from the screen name and the > > "parameters" map (the output UtilHttp.getCombinedMap(...)) that > > represents the input context for screens > > c) associated to the cache key we will cache the final output of the > > screen (html code or xsl-fo code...) > > d) if the cache is enabled for a given screen, the input "parameters" > > map is used as a key for the cache system, if no value is found, then > > the screen (actions + froms + ftl templates) is run as usual and the > > output is rendered and stored in the cache (with key screen name + > > "parameters"); if the value is found, then the output is retrieved from > > memory and sent to the user (no actions and ftl are executed) > > > > A different option would be that of storing the output context in the > > cache and serve it to the ftl (instead of storing the output html/xsl-fo). > > > > I'd love to get your feedback about this, ideas/concerns, > > > > Jacopo > > > > > |
|
|
In reply to this post by Jacopo Cappellato
seems that the processing of the key would take up a lot of memory and
time to process, assuming that 90% of the widgets were cached. Jacopo Cappellato sent the following on 7/17/2007 8:32 AM: > Hi all, > > I'd like to discuss with you all about the idea of implementing screen > widget output caching. > > Goal: minimize the db/service hits for rather static screens (for > example a category or product detail screen in the ecommerce); this > could be done by implementing screen widget output caching that prevents > the screen widget actions (and possibly ftl) from running > > Draft/proposal for implementation: > > a) add new attributes in the screen definition for cache settings (e.g. > cache="true|false" etc...) > b) the cache key can be derived from the screen name and the > "parameters" map (the output UtilHttp.getCombinedMap(...)) that > represents the input context for screens > c) associated to the cache key we will cache the final output of the > screen (html code or xsl-fo code...) > d) if the cache is enabled for a given screen, the input "parameters" > map is used as a key for the cache system, if no value is found, then > the screen (actions + froms + ftl templates) is run as usual and the > output is rendered and stored in the cache (with key screen name + > "parameters"); if the value is found, then the output is retrieved from > memory and sent to the user (no actions and ftl are executed) > > A different option would be that of storing the output context in the > cache and serve it to the ftl (instead of storing the output html/xsl-fo). > > I'd love to get your feedback about this, ideas/concerns, > > Jacopo > > > > |
|
|
Perhaps, instead of output caching to memory, output to a "temporary"
contentId and store the output to disk or to xml database? --- BJ Freeman <[hidden email]> wrote: > seems that the processing of the key would take up a lot of memory > and > time to process, assuming that 90% of the widgets were cached. > > > Jacopo Cappellato sent the following on 7/17/2007 8:32 AM: > > Hi all, > > > > I'd like to discuss with you all about the idea of implementing > screen > > widget output caching. > > > > Goal: minimize the db/service hits for rather static screens (for > > example a category or product detail screen in the ecommerce); this > > could be done by implementing screen widget output caching that > prevents > > the screen widget actions (and possibly ftl) from running > > > > Draft/proposal for implementation: > > > > a) add new attributes in the screen definition for cache settings > (e.g. > > cache="true|false" etc...) > > b) the cache key can be derived from the screen name and the > > "parameters" map (the output UtilHttp.getCombinedMap(...)) that > > represents the input context for screens > > c) associated to the cache key we will cache the final output of > the > > screen (html code or xsl-fo code...) > > d) if the cache is enabled for a given screen, the input > "parameters" > > map is used as a key for the cache system, if no value is found, > then > > the screen (actions + froms + ftl templates) is run as usual and > the > > output is rendered and stored in the cache (with key screen name + > > "parameters"); if the value is found, then the output is retrieved > from > > memory and sent to the user (no actions and ftl are executed) > > > > A different option would be that of storing the output context in > the > > cache and serve it to the ftl (instead of storing the output > html/xsl-fo). > > > > I'd love to get your feedback about this, ideas/concerns, > > > > Jacopo > > > > > > > > > |
|
|
Or, you could take the approach that the OS is responsible for caching things on a local storage
device - then go ahead and code as if you have unlimited memory. Chris Howe wrote: > Perhaps, instead of output caching to memory, output to a "temporary" > contentId and store the output to disk or to xml database? > > --- BJ Freeman <[hidden email]> wrote: > > >>seems that the processing of the key would take up a lot of memory >>and >>time to process, assuming that 90% of the widgets were cached. >> >> >>Jacopo Cappellato sent the following on 7/17/2007 8:32 AM: >> >>>Hi all, >>> >>>I'd like to discuss with you all about the idea of implementing >> >>screen >> >>>widget output caching. >>> >>>Goal: minimize the db/service hits for rather static screens (for >>>example a category or product detail screen in the ecommerce); this >>>could be done by implementing screen widget output caching that >> >>prevents >> >>>the screen widget actions (and possibly ftl) from running >>> >>>Draft/proposal for implementation: >>> >>>a) add new attributes in the screen definition for cache settings >> >>(e.g. >> >>>cache="true|false" etc...) >>>b) the cache key can be derived from the screen name and the >>>"parameters" map (the output UtilHttp.getCombinedMap(...)) that >>>represents the input context for screens >>>c) associated to the cache key we will cache the final output of >> >>the >> >>>screen (html code or xsl-fo code...) >>>d) if the cache is enabled for a given screen, the input >> >>"parameters" >> >>>map is used as a key for the cache system, if no value is found, >> >>then >> >>>the screen (actions + froms + ftl templates) is run as usual and >> >>the >> >>>output is rendered and stored in the cache (with key screen name + >>>"parameters"); if the value is found, then the output is retrieved >> >>from >> >>>memory and sent to the user (no actions and ftl are executed) >>> >>>A different option would be that of storing the output context in >> >>the >> >>>cache and serve it to the ftl (instead of storing the output >> >>html/xsl-fo). >> >>>I'd love to get your feedback about this, ideas/concerns, >>> >>>Jacopo >>> >>> >>> >>> >> > > |
|
|
In reply to this post by Jacopo Cappellato
I think this is a great idea. As with any other caching tool it needs to be used properly, and based on some of the responses there seems to be some misunderstanding about that. Just as with entity caches this would only be helpful for high volume screens that are not updated frequently, and in many cases we would want to cache only parts of high level screens, like the product information on the product detail page, but not the mini cart or other sub-screens on the sides that are user-specific. Also when used this would be more susceptible to stale information as the only easy mechanism for refreshing these is a time limit. We would probably want to make it possible to specify the cache name to cache the screen in, or I guess we could just have some convention (but it would result in long cache names to have the location and screen name put together to make it unique). With this and the caching infrastructure in OFBiz we could have size (number of elements) limits, timeouts, soft references, etc to help manage the caches. If we did something like this my vote would be on caching the entire output of the screen. If someone wanted to speed up the data preparation chances are the most effective way to do it would be to use the entity engine caches to help with database round trip delays and such, which often takes up BY FAR the majority of the data preparation time. This sort of tool could be really nice but very complex if it had an auto-clear mechanism like that of the entity engine, but for this sort of things it would be REALLY hard to have some sort of change notification mechanism that is used for as much of what goes into screen contexts as possible. Anyway, my point is that it's probably not feasible to do this and we shouldn't worry about it initially. The tool would have value with proper use even without that. One thing about this, BTW: for screens that use all cached data retrieval it would be interesting to time the difference in execution because as they are now, these things run pretty fast. There would certainly be a difference, but I'm wondering how much of an impact it might have. Still, for ecommerce and content sites that are going through a million pages an hour, this sort of feature could be the difference between using OFBiz and some other technology entirely. -David Jacopo Cappellato wrote: > Hi all, > > I'd like to discuss with you all about the idea of implementing screen > widget output caching. > > Goal: minimize the db/service hits for rather static screens (for > example a category or product detail screen in the ecommerce); this > could be done by implementing screen widget output caching that prevents > the screen widget actions (and possibly ftl) from running > > Draft/proposal for implementation: > > a) add new attributes in the screen definition for cache settings (e.g. > cache="true|false" etc...) > b) the cache key can be derived from the screen name and the > "parameters" map (the output UtilHttp.getCombinedMap(...)) that > represents the input context for screens > c) associated to the cache key we will cache the final output of the > screen (html code or xsl-fo code...) > d) if the cache is enabled for a given screen, the input "parameters" > map is used as a key for the cache system, if no value is found, then > the screen (actions + froms + ftl templates) is run as usual and the > output is rendered and stored in the cache (with key screen name + > "parameters"); if the value is found, then the output is retrieved from > memory and sent to the user (no actions and ftl are executed) > > A different option would be that of storing the output context in the > cache and serve it to the ftl (instead of storing the output html/xsl-fo). > > I'd love to get your feedback about this, ideas/concerns, > > Jacopo > |
|
|
David,
please see my comments inline: David E Jones wrote: > > I think this is a great idea. As with any other caching tool it needs to > be used properly, and based on some of the responses there seems to be > some misunderstanding about that. > > Just as with entity caches this would only be helpful for high volume > screens that are not updated frequently, and in many cases we would want > to cache only parts of high level screens, like the product information > on the product detail page, but not the mini cart or other sub-screens > on the sides that are user-specific. > That is exactly what we would like to implement. > Also when used this would be more susceptible to stale information as > the only easy mechanism for refreshing these is a time limit. We would > probably want to make it possible to specify the cache name to cache the > screen in, or I guess we could just have some convention (but it would > result in long cache names to have the location and screen name put > together to make it unique). With this and the caching infrastructure in > OFBiz we could have size (number of elements) limits, timeouts, soft > references, etc to help manage the caches. > I'd like to use a complex/specialized key (a custom class with a Comparator) composed by: * screen name and screen location * (a subset of) input parameters map (input context) Then I'd like to implement some utils method that allow to clear all the cache entries associated to a given screen name and screen location. > If we did something like this my vote would be on caching the entire > output of the screen. If someone wanted to speed up the data preparation > chances are the most effective way to do it would be to use the entity > engine caches to help with database round trip delays and such, which > often takes up BY FAR the majority of the data preparation time. > That is a good point. One doubt I have, if we cache html output, is how to handle links with session id information in them (for example when cookies are disabled)... this would make the cache useless. > This sort of tool could be really nice but very complex if it had an > auto-clear mechanism like that of the entity engine, but for this sort > of things it would be REALLY hard to have some sort of change > notification mechanism that is used for as much of what goes into screen > contexts as possible. Anyway, my point is that it's probably not > feasible to do this and we shouldn't worry about it initially. The tool > would have value with proper use even without that. > Yep, initially I would prefer to skip this part and just implement manual clearing of cache entries (by screen name) and expiring cache based on ttl set in the screen definition. > One thing about this, BTW: for screens that use all cached data > retrieval it would be interesting to time the difference in execution > because as they are now, these things run pretty fast. There would > certainly be a difference, but I'm wondering how much of an impact it > might have. Still, for ecommerce and content sites that are going > through a million pages an hour, this sort of feature could be the > difference between using OFBiz and some other technology entirely. > Yes, I would be curious to see the difference too, but I guess it is not so easy to test. Thanks for your valuable feedback, Jacopo > -David > > > Jacopo Cappellato wrote: >> Hi all, >> >> I'd like to discuss with you all about the idea of implementing screen >> widget output caching. >> >> Goal: minimize the db/service hits for rather static screens (for >> example a category or product detail screen in the ecommerce); this >> could be done by implementing screen widget output caching that >> prevents the screen widget actions (and possibly ftl) from running >> >> Draft/proposal for implementation: >> >> a) add new attributes in the screen definition for cache settings >> (e.g. cache="true|false" etc...) >> b) the cache key can be derived from the screen name and the >> "parameters" map (the output UtilHttp.getCombinedMap(...)) that >> represents the input context for screens >> c) associated to the cache key we will cache the final output of the >> screen (html code or xsl-fo code...) >> d) if the cache is enabled for a given screen, the input "parameters" >> map is used as a key for the cache system, if no value is found, then >> the screen (actions + froms + ftl templates) is run as usual and the >> output is rendered and stored in the cache (with key screen name + >> "parameters"); if the value is found, then the output is retrieved >> from memory and sent to the user (no actions and ftl are executed) >> >> A different option would be that of storing the output context in the >> cache and serve it to the ftl (instead of storing the output >> html/xsl-fo). >> >> I'd love to get your feedback about this, ideas/concerns, >> >> Jacopo >> |
|
|
Jacopo Cappellato wrote: >> Also when used this would be more susceptible to stale information as >> the only easy mechanism for refreshing these is a time limit. We would >> probably want to make it possible to specify the cache name to cache >> the screen in, or I guess we could just have some convention (but it >> would result in long cache names to have the location and screen name >> put together to make it unique). With this and the caching >> infrastructure in OFBiz we could have size (number of elements) >> limits, timeouts, soft references, etc to help manage the caches. >> > > I'd like to use a complex/specialized key (a custom class with a > Comparator) composed by: > * screen name and screen location > * (a subset of) input parameters map (input context) > > Then I'd like to implement some utils method that allow to clear all the > cache entries associated to a given screen name and screen location. This is interesting... but wouldn't it be more flexible and easier to implement if we had one cache per screen (just like we do with entities)? I don't think we'll ever have so many screens cached (ie into the hundreds) that this will become unwieldy, and if it does happen then we can enhance the cache management screens in webtools to better handle this. >> If we did something like this my vote would be on caching the entire >> output of the screen. If someone wanted to speed up the data >> preparation chances are the most effective way to do it would be to >> use the entity engine caches to help with database round trip delays >> and such, which often takes up BY FAR the majority of the data >> preparation time. >> > > That is a good point. > One doubt I have, if we cache html output, is how to handle links with > session id information in them (for example when cookies are > disabled)... this would make the cache useless. Ouch, that's a good one... Actually, in order for this to work the cached screen couldn't have anything request or session specific in it. This is a trick because the request and session objects will typically be in the context and may be used in the rendering of the screen. We'd probably have to remove those from the copy of the context that is used for the unique identifier creation. That could get a little messy. For this particular issue we can probably make sure the jsessionid is never added, though that may cause problems transitioning from/to HTTP to/from HTTPS in some browsers. Yeah, that's a rough one... no really good solution is hitting me for that. What is hitting me is that we're likely to run into other things like that... :( -David |
|
|
David,
David E Jones wrote: > > > Jacopo Cappellato wrote: >>> Also when used this would be more susceptible to stale information as >>> the only easy mechanism for refreshing these is a time limit. We >>> would probably want to make it possible to specify the cache name to >>> cache the screen in, or I guess we could just have some convention >>> (but it would result in long cache names to have the location and >>> screen name put together to make it unique). With this and the >>> caching infrastructure in OFBiz we could have size (number of >>> elements) limits, timeouts, soft references, etc to help manage the >>> caches. >>> >> >> I'd like to use a complex/specialized key (a custom class with a >> Comparator) composed by: >> * screen name and screen location >> * (a subset of) input parameters map (input context) >> >> Then I'd like to implement some utils method that allow to clear all >> the cache entries associated to a given screen name and screen location. > > This is interesting... but wouldn't it be more flexible and easier to > implement if we had one cache per screen (just like we do with > entities)? I don't think we'll ever have so many screens cached (ie into > the hundreds) that this will become unwieldy, and if it does happen then > we can enhance the cache management screens in webtools to better handle > this. > Are you saying that we should maintain *one* cache for each screen name/location and associated to it a set of input context/output pairs? For example, considering the productDetail screen: the cache would be associated to: some_location#productDetail and associated to this cache will have many pairs, one for each different input context: productDetailUri?productId=WG-1000 (key) --> html detail screen for WG-1000 productDetailUri?productId=WG-1111 (key) --> html detail screen for WG-1111 ... It would be fine for me: I still need to study how the OFBiz cache classes are organized, so I am probably missing your point, sorry. >>> If we did something like this my vote would be on caching the entire >>> output of the screen. If someone wanted to speed up the data >>> preparation chances are the most effective way to do it would be to >>> use the entity engine caches to help with database round trip delays >>> and such, which often takes up BY FAR the majority of the data >>> preparation time. >>> >> >> That is a good point. >> One doubt I have, if we cache html output, is how to handle links with >> session id information in them (for example when cookies are >> disabled)... this would make the cache useless. > > Ouch, that's a good one... > > Actually, in order for this to work the cached screen couldn't have > anything request or session specific in it. This is a trick because the > request and session objects will typically be in the context and may be > used in the rendering of the screen. We'd probably have to remove those > from the copy of the context that is used for the unique identifier > creation. Yes, we will have to remove some stuff (or just ignore it in the custom Comparator), for example the nowTimestamp, etc... But the decision will be difficult for some variables: for example, should we ignore the userLogin object? If we consider it then the screen cache will be only useful for anonymous users; if we ignore it then we could miss important information (prices specific for a customer etc...) > > That could get a little messy. For this particular issue we can probably > make sure the jsessionid is never added, though that may cause problems > transitioning from/to HTTP to/from HTTPS in some browsers. > > Yeah, that's a rough one... no really good solution is hitting me for > that. What is hitting me is that we're likely to run into other things > like that... :( > That is exactly what is worring me... Jacopo > -David |
|
|
Jacopo Cappellato wrote:
>>>> If we did something like this my vote would be on caching the entire >>>> output of the screen. If someone wanted to speed up the data >>>> preparation chances are the most effective way to do it would be to >>>> use the entity engine caches to help with database round trip delays >>>> and such, which often takes up BY FAR the majority of the data >>>> preparation time. >>>> >>> >>> That is a good point. >>> One doubt I have, if we cache html output, is how to handle links >>> with session id information in them (for example when cookies are >>> disabled)... this would make the cache useless. >> >> >> Ouch, that's a good one... >> >> Actually, in order for this to work the cached screen couldn't have >> anything request or session specific in it. This is a trick because >> the request and session objects will typically be in the context and >> may be used in the rendering of the screen. We'd probably have to >> remove those from the copy of the context that is used for the unique >> identifier creation. > > > Yes, we will have to remove some stuff (or just ignore it in the custom > Comparator), for example the nowTimestamp, etc... > But the decision will be difficult for some variables: for example, > should we ignore the userLogin object? If we consider it then the screen > cache will be only useful for anonymous users; if we ignore it then we > could miss important information (prices specific for a customer etc...) > >> >> That could get a little messy. For this particular issue we can >> probably make sure the jsessionid is never added, though that may >> cause problems transitioning from/to HTTP to/from HTTPS in some browsers. >> >> Yeah, that's a rough one... no really good solution is hitting me for >> that. What is hitting me is that we're likely to run into other things >> like that... :( >> > > That is exactly what is worring me... > > Jacopo That's why I suggested caching the widgets themselves. If the discussion is about a site that is getting a million hits per day, then caching the widgets should offer some level of improvement. Reading and parsing the widget xml file might seem to go fast, but the reality is that every page request requires an xml file read, element parsing, converting parsed elements into a collection of java classes, and some validation. With a hypothetical million-hit-per-day site, all of those steps are repeated millions of times per day. Why not do those steps once, and then cache the result? -Adrian |
|
|
Adrian,
> > That's why I suggested caching the widgets themselves. If the discussion > is about a site that is getting a million hits per day, then caching the > widgets should offer some level of improvement. > > Reading and parsing the widget xml file might seem to go fast, but the > reality is that every page request requires an xml file read, element > parsing, converting parsed elements into a collection of java classes, > and some validation. With a hypothetical million-hit-per-day site, all > of those steps are repeated millions of times per day. Why not do those > steps once, and then cache the result? > > -Adrian aren't widget definitions already cached? Jacopo |
|
|
Jacopo Cappellato wrote:
> Adrian, > >> >> That's why I suggested caching the widgets themselves. If the >> discussion is about a site that is getting a million hits per day, >> then caching the widgets should offer some level of improvement. >> >> Reading and parsing the widget xml file might seem to go fast, but the >> reality is that every page request requires an xml file read, element >> parsing, converting parsed elements into a collection of java classes, >> and some validation. With a hypothetical million-hit-per-day site, all >> of those steps are repeated millions of times per day. Why not do >> those steps once, and then cache the result? >> >> -Adrian > > > aren't widget definitions already cached? > > Jacopo I don't know for sure. I see on the console log things like this: 2007-07-17 16:39:03,015 (http-0.0.0.0-8443-Processor2) [ ScreenFactory.java:118:INFO ] Got 28 screens in 0.094s from: file:/C:/ofbiz/applications/workeffort/widget/WorkEffortScreens.xml It appears to me the screens are being read from a file. |
|
|
Adrian,
that is correct, in development mode (the default) screen widget caching is disabled. Jacopo Adrian Crum wrote: > Jacopo Cappellato wrote: > >> Adrian, >> >>> >>> That's why I suggested caching the widgets themselves. If the >>> discussion is about a site that is getting a million hits per day, >>> then caching the widgets should offer some level of improvement. >>> >>> Reading and parsing the widget xml file might seem to go fast, but >>> the reality is that every page request requires an xml file read, >>> element parsing, converting parsed elements into a collection of java >>> classes, and some validation. With a hypothetical million-hit-per-day >>> site, all of those steps are repeated millions of times per day. Why >>> not do those steps once, and then cache the result? >>> >>> -Adrian >> >> >> aren't widget definitions already cached? >> >> Jacopo > > I don't know for sure. I see on the console log things like this: > > 2007-07-17 16:39:03,015 (http-0.0.0.0-8443-Processor2) [ > ScreenFactory.java:118:INFO ] Got 28 screens in 0.094s from: > file:/C:/ofbiz/applications/workeffort/widget/WorkEffortScreens.xml > > It appears to me the screens are being read from a file. |
|
|
Thanks for the clarification. I learned something today. :)
Jacopo Cappellato wrote: > Adrian, > > that is correct, in development mode (the default) screen widget caching > is disabled. > > Jacopo > > Adrian Crum wrote: > >> Jacopo Cappellato wrote: >> >>> Adrian, >>> >>>> >>>> That's why I suggested caching the widgets themselves. If the >>>> discussion is about a site that is getting a million hits per day, >>>> then caching the widgets should offer some level of improvement. >>>> >>>> Reading and parsing the widget xml file might seem to go fast, but >>>> the reality is that every page request requires an xml file read, >>>> element parsing, converting parsed elements into a collection of >>>> java classes, and some validation. With a hypothetical >>>> million-hit-per-day site, all of those steps are repeated millions >>>> of times per day. Why not do those steps once, and then cache the >>>> result? >>>> >>>> -Adrian >>> >>> >>> >>> aren't widget definitions already cached? >>> >>> Jacopo >> >> >> I don't know for sure. I see on the console log things like this: >> >> 2007-07-17 16:39:03,015 (http-0.0.0.0-8443-Processor2) [ >> ScreenFactory.java:118:INFO ] Got 28 screens in 0.094s from: >> file:/C:/ofbiz/applications/workeffort/widget/WorkEffortScreens.xml >> >> It appears to me the screens are being read from a file. > > > |
|
|
In reply to this post by Jacopo Cappellato
In rev. 559384 I've committed the first version of my work.
I'd like to get your feedback (see the commit logs for details). David, I've implemented it following your great suggestions (I've used the enity cache as a reference); the first tests are good even if I have already noticed some weird things happening only the *first* time a screen/key is cached (but not when it is retrieved from cache) in some complex screens (probably due to the recursive way screens are rendered). Let me know what you all think, Jacopo Jacopo Cappellato wrote: > David, > > David E Jones wrote: >> >> >> Jacopo Cappellato wrote: >>>> Also when used this would be more susceptible to stale information >>>> as the only easy mechanism for refreshing these is a time limit. We >>>> would probably want to make it possible to specify the cache name to >>>> cache the screen in, or I guess we could just have some convention >>>> (but it would result in long cache names to have the location and >>>> screen name put together to make it unique). With this and the >>>> caching infrastructure in OFBiz we could have size (number of >>>> elements) limits, timeouts, soft references, etc to help manage the >>>> caches. >>>> >>> >>> I'd like to use a complex/specialized key (a custom class with a >>> Comparator) composed by: >>> * screen name and screen location >>> * (a subset of) input parameters map (input context) >>> >>> Then I'd like to implement some utils method that allow to clear all >>> the cache entries associated to a given screen name and screen location. >> >> This is interesting... but wouldn't it be more flexible and easier to >> implement if we had one cache per screen (just like we do with >> entities)? I don't think we'll ever have so many screens cached (ie >> into the hundreds) that this will become unwieldy, and if it does >> happen then we can enhance the cache management screens in webtools to >> better handle this. >> > > Are you saying that we should maintain *one* cache for each screen > name/location and associated to it a set of input context/output pairs? > For example, considering the productDetail screen: > the cache would be associated to: > > some_location#productDetail > > and associated to this cache will have many pairs, one for each > different input context: > > productDetailUri?productId=WG-1000 (key) --> html detail screen for WG-1000 > productDetailUri?productId=WG-1111 (key) --> html detail screen for WG-1111 > ... > > It would be fine for me: I still need to study how the OFBiz cache > classes are organized, so I am probably missing your point, sorry. > > >>>> If we did something like this my vote would be on caching the entire >>>> output of the screen. If someone wanted to speed up the data >>>> preparation chances are the most effective way to do it would be to >>>> use the entity engine caches to help with database round trip delays >>>> and such, which often takes up BY FAR the majority of the data >>>> preparation time. >>>> >>> >>> That is a good point. >>> One doubt I have, if we cache html output, is how to handle links >>> with session id information in them (for example when cookies are >>> disabled)... this would make the cache useless. >> >> Ouch, that's a good one... >> >> Actually, in order for this to work the cached screen couldn't have >> anything request or session specific in it. This is a trick because >> the request and session objects will typically be in the context and >> may be used in the rendering of the screen. We'd probably have to >> remove those from the copy of the context that is used for the unique >> identifier creation. > > Yes, we will have to remove some stuff (or just ignore it in the custom > Comparator), for example the nowTimestamp, etc... > But the decision will be difficult for some variables: for example, > should we ignore the userLogin object? If we consider it then the screen > cache will be only useful for anonymous users; if we ignore it then we > could miss important information (prices specific for a customer etc...) > >> >> That could get a little messy. For this particular issue we can >> probably make sure the jsessionid is never added, though that may >> cause problems transitioning from/to HTTP to/from HTTPS in some browsers. >> >> Yeah, that's a rough one... no really good solution is hitting me for >> that. What is hitting me is that we're likely to run into other things >> like that... :( >> > > That is exactly what is worring me... > > Jacopo > >> -David |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |