Yea, there are quite some pros and cons for this. My quick gut feeling is: * doing it *right* might become pretty much work * just doing it so-lala (aka half baken) might be worse than doing nothing at all
What are the other options? For a project where speed really matters and where there is also often a strict security setup, it's really easy to delegate all resource requests to an httpd node which caches + zips + + + all the static stuff in the load balancer. LieGrue, strub ----- Original Message ----- > From: Leonardo Uribe <[email protected]> > To: MyFaces Development <[email protected]> > Cc: > Sent: Sunday, July 29, 2012 7:08 PM > Subject: [core] Improvements on ResourceHandler (related to MYFACES-3586) > > Hi > > A patch has been provided to improve ResourceHandler performance in situations > when the required resource is inside a jar file. See: > > https://issues.apache.org/jira/browse/MYFACES-3586 > > This patch opens an old discussion about what should be done by > ResourceHandler > and what should be let to other external tools. > > In few words, the patch "suppose" that all resources handled by > ResourceHandler > are static, and it wants to put a cache, to prevent all necessary calculation > involved in extract the resource from the jar file (or war file when the > application is not extracted) and in that way improve application scalability, > because it exchanges "CPU consumption" with "Memory", which > is ok in this case > because files are relatively small and open a jar file over and over to > calculate the same stuff becomes expensive. > > In cases like this, usually it is possible to setup the server to deal with > this. For example, Tomcat has some configuration params > (cacheMaxSize/cachingAllowed) to configure this part. Also, it provides > other config params to set up gzip compression > (compression/compressionMinSize/noCompressionUserAgents/compressableMimeType). > > Long time ago, we discussed about create a module in MyFaces Commons, to > create a custom ResourceHandler implementation. Some experiments where done > to provide for example gzip compression, as well with other useful features. > But in that discussion, it was mentioned that things like gzip compression > should not be done there, because this is already done in other places, so > in practice we are duplicating work in this part, so we just removed that > code and let that discussion for later. > > But going back to the original problem, there are good reasons to do static > caching or gzip compression inside ResourceHandler: > > - ResourceHandler knows which resources are static and which ones are not, > so the necessary logic can be put there, and what is more important, can be > customized and be aligned with JSF spec. > - Since the cache is inside the server, it uses the memory used by the JVM. > With an external module like with an Apache 2.x server, the reserved memory > for caching is not shared with the JVM, so memory tuning becomes a little > bit complex. > - With a good design, it is possible to save some buffers in this part, or > do things like create temporal files and prevent the jar opening or compress > the same file with gzip algorithm over and over. > - Suffix mapping ( use .jsf as extension for resources ) does not play well > with external tools, which usually expect files ending with .js, .css, .png > and other extensions. > > In the other side, there are disadvantages: > > - There exists other solutions that are faster and better, because they are > well known and already tested, so why bother for this? > - More code to maintain. > - MYFACES-3586 needs more work to be included, because not all resources > handled by ResourceHandler are static (for example the image rendered by > a captcha component needs to be generated dynamically). > > In conclusion, we need to clarify the community position about if it is worth > to do it or not, before accept or not a modification like MYFACES-3586. For > now, and to be consistent with previous discussions, the patch will not be > included for now. > > Suggestions are welcome. > > regards, > > Leonardo Uribe >
