Java-based chatters

From: Dancer <>
Date: Thu, 30 Oct 1997 12:24:09 +1000


I've been getting complaints that loading java-based chat clients seems
to be much slower than loading anything else. Accordingly, I looked into
the problem, and this is what I found...

878177377.567 4985 TCP_CLIENT_REFRESH/200 827 GET
- DEFAULT_PARENT/ image/gif
878177390.423 12041 TCP_CLIENT_REFRESH/200 3129 GET
- DEFAULT_PARENT/ image/gif
878177396.058 5587 TCP_CLIENT_REFRESH/200 636 GET
- DEFAULT_PARENT/ image/gif
878177402.008 5897 TCP_CLIENT_REFRESH/200 851 GET
- DEFAULT_PARENT/ image/gif
878177408.188 6112 TCP_CLIENT_REFRESH/200 876 GET
- DEFAULT_PARENT/ image/gif
878177413.518 5157 TCP_CLIENT_REFRESH/200 535 GET
- DEFAULT_PARENT/ image/gif
878177418.477 4897 TCP_CLIENT_REFRESH/200 687 GET
- DEFAULT_PARENT/ image/gif
878177423.497 4965 TCP_CLIENT_REFRESH/200 772 GET
- DEFAULT_PARENT/ image/gif
878177450.138 16599 TCP_CLIENT_REFRESH/200 8424 GET
- DEFAULT_PARENT/ image/gif

Behold, the java clients are _forcing_reloads_ of images
_every_damn_time_ the chat program loads. The above excerpt is only a
fragment of the total load (which for this particular chat session took
12 minutes to load, and a half-meg or so of bandwidth).

What a _waste_!!

Now, I see some options:
1) Copy all their image URL's to a local server, and update the redirect
script to point to it. Users on modems will still have long load times,
but the bandwidth choking and expense will be shifted off the main IP
2) Kick the people who wrote the chat thing until they fix it.
3) Figure some way to tell squid _not_ to allow the object to be
refreshed by the client, so long as there is a copy in the cache.



Note to evil sorcerers and mad scientists: don't ever, ever summon
demons or rip holes in the fabric of space and time. It's never a good
ICQ UIN: 3225440
Received on Wed Oct 29 1997 - 18:29:41 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:37:22 MST