[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [K12OSN] Client Ram



Couldn't Firefox and/or the Xserver be rewritten to behave like this:

1) use only a certain amount of memory for cache
2) when that memory is full, delete the oldest cache
3) when a request comes in for a cached image, deliver it if it's
available, but...
4) if the requested image has been deleted from cache, then re-request the
image from its original source (the internet)

I'm imagining steps 3 and 4 to behave similar to a caching dns server.

Of course I don't know anything about how the Xserver operates, so this
could be a big load of bull...

-Rob

On Fri, May 25, 2007 at 08:06:51AM -0400, Jim McQuillan wrote:
> 
> 
> Daniel Bodanske wrote:
> >So Firefox stores pixmaps uncompressed in the X server cache.
> >Unbelievable. Is it Firefox or Gecko? Does Seamonkey suffer the same
> >limitation. Could you move to Epiphany? Wow.
> 
> This is not unusual.  everybody seems to be implying that firefox is 
> being evil by doing this.
> 
> The Xserver caches pixmaps and fonts.  No big deal.  It's part of the 
> design of the X Window System.  The problem is, with tabs, the browser 
> can actually be viewing more than one page at a time, which means there 
> can be alot more pixmaps sent from the browser to the Xserver.  The 
> Xserver just happily caches them.
> 
> A flaw in this design is the fact that when the thin client gets low on 
> memory, the Xserver has no mechanism to deal with it.  It can't throw 
> away pixmaps from the cache, because it has no way of telling the client 
> application that it no longer has the image cached, so there's no way 
> for firefox to re-send the pixmap when the user comes back to that page.
> 
> So, sadly, the Xserver runs out of memory, and bad things happen.
> 
> I've brought this up to the X.org developers and everybody agrees that 
> it's a big problem, but unfortunately, there's not an easy fix.
> 
> It's not just firefox that is involved here. Any graphical application 
> will send images and fonts to the Xserver, and expect those things to 
> still be in the Xserver later on.  I suppose Firefox could be modified 
> to never expect those things to be cached, which means it would have to 
> send the images and fonts each time you switch from one tab to another, 
> or scroll the page up and down.  Imagine the screams you'd be hearing as 
> the performance goes down the tubes, and the network traffic goes 
> through the roof.
> 
> We tried fixing this a few years ago in LTSP by placing a limit on how 
> much ram the Xserver could allocate.  This managed to keep the Xserver 
> from crashing, but then the client application would crash because it 
> didn't expect the Xserver to fail to allocate the memory for it.  If the 
> client is the browser, the browser would crash, which is easily 
> recoverable.  But, what if the client application is something more 
> important, like the window manager?
> 
> It's a tough problem, and I wish I had the magic fix for it.
> 
> Jim McQuillan
> jam Ltsp org
> 
> 
> 
> >
> >I began to get scared a few years ago when so many new desktop
> >applications started to get written for Linux. So many of them
> >wouldn't work over the network. I got worried that LTSP might become
> >non-viable some day when all the standard apps needed local resources.
> >Once Freedesktop.org was started and picked up momentum with Jim as
> >one of the founding members, I calmed down, but I guess I shouldn't
> >have. Firefox seems to follow it's own rules all the time, anyway.
> >
> >Dan
> >
> >On 5/25/07, Dan Young <dyoung mesd k12 or us> wrote:
> >>On 5/24/07, Rob Owens <rowens ptd net> wrote:
> >>> So maybe the question should be:  Is there a browser that it better
> >>> suited to LTSP than Firfox is?
> >>
> >>Well, part of it comes down to tuning. Eric put together a Firefox
> >>extension that sets several options to more friendly levels. In
> >>particular:
> >>
> >>browser.cache.memory.capacity
> >>and
> >>browser.sessionhistory.max_total_viewers
> >>
> >>The defaults are variable depending on the total memory of the
> >>computer. Of course, in an LTSP environment, it's all shared, so a 4G
> >>host can't expect to have all that for one browser instance.
> >>
> >>As I understand it, the defaults have been dialed back somewhat for
> >>Firefox 2. Eric's Firefox extension dials back these values too.
> >>http://www.redhat.com/archives/k12osn/2006-May/msg00372.html
> >>
> >>-- 
> >>Dan Young <dyoung mesd k12 or us>
> >>Multnomah ESD - Technology Services
> >>503-257-1562
> >>
> >>_______________________________________________
> >>K12OSN mailing list
> >>K12OSN redhat com
> >>https://www.redhat.com/mailman/listinfo/k12osn
> >>For more info see <http://www.k12os.org>
> >>
> >
> >_______________________________________________
> >K12OSN mailing list
> >K12OSN redhat com
> >https://www.redhat.com/mailman/listinfo/k12osn
> >For more info see <http://www.k12os.org>
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN redhat com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]