Brian/Bob: I would think the first step would be to file bugs or enhancement requests with the firefox, openoffice, etc. projects explaining our needs. We might find, in response, that there are already some configuration options that we could/should be tweaking to improve thin-client performance. If not, filing these bugs/ enhancement requests is the right first step to get such configuration options added.
Brian, are you aware if such bugs/enhancement requests exist? Could you provide pointers to them? I suspect several people in this thread would like to cc: themselves to any known reports. Brian >> The intended scope is "JDS" which does include firefox and >> staroffice. But the original optimization f27ch9hhconfiguation settings for >> JDS2 were focused on components of the base GNOME desktop. So more >> work will need to be done. Do you have any suggestions for firefox? >> Turn off flash animations? reduce the default cache size? >> Configuration settings don't exist for all of these and some that do >> exist aren't yet available to the Java Desktop Configuration Manager. > > I don't think config settings exist yet which would be interesting here > - the work has to happen in the firefox community first. My first vote > would be for firefox to do less aggressive retention of pixmaps for > non-visible pages (e.g. pages "Back" in the URL history several steps, > and possibly hidden tabs). This could have a profound effect on the > memory footprint of the X server, which is one of the biggest culprits > in desktop resource consumption. Perhaps we could have a multi-level > setting (e.g. 1-5) where one extreme is what we have today, maybe the > next level is to free up pixmaps which are at least 5 steps back in > history (I don't know where the limit is today, and am guessing its > higher than this), and finally maybe the other extreme might be > non-visible tabs and any history. Or maybe an idle timeout could be > applied (but beware of chewing up CPU in order to save resources ;-). > > I wouldn't recommend anything heavy-handed like disabling flash > animations unless it was simply influencing a default that the user > could override if they chose to do so (in a fairly obvious way). We > don't want to limit function (unless we have a very extreme > circumstance, and I'm not convinced flash is so bad that one or two > people can't use it now and then), we only want to reduce impact. > > Simple stuff could be done right off the bat. I think I still see > staroffice doing spin loops. That's bad citizenship. Everything should > be done off of timers or events of some sort so that the CPU can be shared. > > A bit OT: I'd love to see JDS pick up and refine xautolock > http://freshmeat.net/projects/xautolock/ so that it's a good multi-user > citizen (i.e. remove spin loops). We have many customers who would like > to have a desktop session terminate if it's been idle for a certain > period of time. That's about maximizing desktop resource utilization > also, but on an aggregate server basis vs an individual desktop basis. > > -Bob > > Disclaimer: Opinions expressed in this mail are my own, > and are not necessarily shared by my employer > >> I intend to gather Sun Ray performance enhancement requests which are >> not yet configurable into a proposal for the "Gnome lite" project. >> >> Bob Doolittle wrote: >>> Hi Brian, >>> >>> First off - kudos for dusting off the perf doc and making it current. >>> That'll be a big help to folks. >>> >>> Comment inline: >>> >>> Brian Nitz wrote: >>>>>> And even better if that configuration were visible and could be >>>>>> leveraged >>>>>> by higher-level apps :-) >>>>> I agree. It might be helpful if we talked through how we think this >>>>> should work. >>>> Most if not all of the performance related gconf keys are now >>>> exposed via Sun Java Desktop System Configuration manager (was >>>> APOC). This document >>>> (http://www.sun.com/bigadmin/content/submitted/jds_optimize.html) >>>> was written for JDS2 linux, but the changes necessary to make these >>>> policies work went into the codebase for JDS3 on Solaris 10. >>> >>> Since "JDS" encompasses some pretty pertinent higher-level apps, >>> as well as the desktop, I wonder what scope you're describing here? >>> When you say "changes necessary to make these policies work" >>> are you suggesting that firefox (for example) is now looking at >>> these keys and changing its behavior? >>> >>> That's the sort of thing I was imagining with my comment, but >>> I'd be (very pleasantly! :-) ) surprised to hear that such work has >>> already been done. >>> >>> -Bob >>> >> >
