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

Re: [K12OSN] Client Ram





Rob Owens wrote:
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)

The Xserver doesn't know anything about the internet. It received the image from the client application (firefox). If the Xserver deletes the image, due to memory being full, it would need to tell firefox to resend it. Unfortunately, there's no mechanism for that in the X11 protocol.

Sure it could be added, but you'd have to consider whether that breaks anything in the protocol. Keeping in mind that there's an awful lot of programs out there that depend on the current protocol.

Jim McQuillan
jam Ltsp org




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>

_______________________________________________
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]