|
|
|
|
#1
08-12-2002, 06:08 AM
|
|||
|
|||
|
Bandwidth-saving suggestion for the boards
Reduce the size of the Straight Dope banner on the top of the page.
It's currently 466 x 119 pixels and 256 colours - and is just under 7K. It's also rather large in comparison to the current trends of the web. Reduce the size to a more elegant 200 x 51 pixels, and reduce the number of colours to 8 (I've done this here with no discernible loss of quality) and it's only 2.15K. Feel free to use this if you think it's a good idea. Caches notwithstanding, you'd save 5K per page view - which would add up to a lot of bandwidth saving over the course of a day. 
|
| Advertisements | |
|
|
|
|
#2
08-12-2002, 06:34 AM
|
|||
|
|||
|
Correct me if I'm wrong, Arnold's usually the one to do the tech stuff, but: wouldn't the SD banner be in your cache after you first download it? I doubt it needs to be picked up from the SD server everytime someone loads a page.
|
|
#4
08-12-2002, 07:04 AM
|
|||
|
|||
|
On most users' PCs it would be cached, and also cached if someone's using a proxy server. I suppose the true saving would be shown by the number of unique users per day.
The server logs should show the amount of times the image is actually accessed, as opposed to cached file requests. It was just an excuse really: I'm motivated by the aesthetics.
|
|
#8
08-12-2002, 07:24 AM
|
|||
|
|||
|
Ditto.
I got so blasé about the logo being there that I didn't realise how visible it was to my boss, 20 yards away. I now have to open teensy little windows and scroll down hurriedly. Of course I'm sure he now recognises the grey/white stripes as well...
|
|
#12
08-12-2002, 01:42 PM
|
|||
|
|||
|
FWIW, I agree with jjimm's suggestion to reduce the size of the banner.
A few k here, and a few k there, and pretty soon you're talking real bandwidth. I agree that it'd be an asthetic improvement too. Then again, probably the best bandwidth improvement could be obtained by eliminating "me too" posts. 
__________________
"Time flies like an arrow, fruit flies like a banana." (Groucho Marx; but also used to test a language recognition algorithm) "The essential is invisible to the eye." (The Little Prince)
|
|
#13
08-12-2002, 05:13 PM
|
|||
|
|||
|
Changing bitmaps for aesthetics/efficiency would probably be more Gaudere's forte, but 7K is minuscule! And I'm not convinced that we need to go to additional trouble to make it easier for people to surf the web at work.
Nevertheless I will raise the idea with the powers that be, but I doubt any change will be made.
|
|
#15
08-13-2002, 10:06 AM
|
|||
|
|||
|
Poor guy, really thinks Cecil's ego could be squeezed into 200 x 51 pixels.
:wanders off, shaking head in pity:
|
|
#17
08-22-2002, 10:07 AM
|
|||
|
|||
|
Reviving thread to indulge pathological geekyness, with some additional options...Even if you don't choose to resize the image, there are several ways to cut the file size down. I realize that the bandwidth used by the banner isn't really significant, but heck, there's nothing wrong with saving The Reader a couple bucks, and the modem users half a second, is there?
1) Keep the current image as a GIF, but reduce the number of colors. This has the most modest size savings, but has no cons. I think 2k can be shaved off of it with no visible difference, bringing the file down to about 5k. 2) Change the format of the current image to PNG. Pros: Absolutely no change in appearance of the image, at all. Much smaller file size. Con: People using web browsers older than v4.0 won't be able to see the image, but its hardly critical to the functioning of the site. 3) Do both! Same Cons as #2, but the file size ends up being the smallest of the bunch. Overall, however much I might personally lust over option #3, #1 probably makes the most sense for the board in general. No visitors are lost, and there is a moderate file size savings. Actually reducing the dimensions along with #1, as jjimm originally suggested, would help even more.
|
|
#18
08-22-2002, 04:02 PM
|
|||
|
|||
|
I've just saved this page to my hard disk. The page itself is 118k. The images total to 22k. Grand total - 140k. This makes the banner 5 percent of the total. Even if eliminating the banner entirely caused a corresponding drop in response time (unlikely), it wouldn't be noticed.
|
|
#19
08-22-2002, 10:15 PM
|
|||
|
|||
|
I was going to start a thread on this but I might as well post it here as I'm sure the ever-vigilant Arnold will see it anyway.
Is there anything sacred about fifty posts per page? When I'm viewing a thread with say, 45 responses, it can take forever to load. This wastes both my time and the server's bandwidth if I'm re-visiting a thread and only want to see the last fifteen or so responses. In some forums, this probably isn't a big deal. But in GD or the Pit, the posts can be quite long. If the page size were, say, 25 posts instead of 50, the server would have to do considerably less work because it won't have to serve up those 30 posts that I don't really need to see again. It's true that shorter pages might have some effect on the continuity of the debate. On the other hand, I doubt fifty posts per page has been emperically determined to be optimal. Oh, and Rowrrbazzle, I think the 5% number may be misleading. My understanding is that sometimes, even a small increase in server load can dramatically erode performance. It's not really linear. If you could decrease the server load by 10 or 15%, you might see a pretty dramatic decrease in response time.
|
|
#21
08-23-2002, 07:32 AM
|
|||
|
|||
|
rowrrbazzle: First of all, no one is denying that the difference would be very insignificant. However, it doesn't cost anything. It's a FREE half second speedup for the dialup users. Everyone else would never notice the difference, but again, it doesn't cost anything, nor require any more work from the SD Staff than uploading the new image. And, it's less money out of The Reader's pocket for bandwidth. Again an insignificant amount, but it all boils down to a minute benefit for no cost whatsoever. Also, note that in your example, the page itself will be compressed for those who'd even notice (dialup users). This will generally result in a 75% reduction in size, against which the graphics DO become a slightly significant figure.
|
|
#22
08-23-2002, 01:04 PM
|
|||
|
|||
|
Quote:
|
|
#23
08-23-2002, 01:13 PM
|
|||
|
|||
|
While the effect of an individual snowflake is nearly non-existent, the cumulative effect of many snowflakes can result in a powerful avalanche.
I run into this resistance to making minor changes all the time in a business setting. Arguments range from "this little change won't have any impact" to "we shouldn't even make the effort to change unless we have an idea of the magnitude of the result". (regarding this second point, sometimes the effort to measure the probably impact is greater than the change itself). My answer usually revolves around "so what?" (though I try to sound a little more professional about it). If it's easy to do, the risk is low, and it's a change in the right direction, then why not do it?
|
|
#24
08-23-2002, 07:21 PM
|
|||
|
|||
|
Algernon, addressing the larger point - in my professional life in the software industry, I have seen many times the result of a "minor, insignificant" change resulting in a bug showing up a client site in in some obscure situation1. So I agree with your colleagues that ask that there be a justification for a change. If the little change won't make any improvement then why introduce the change?
1An example: in our software product we added a column to a query to display to the user. Everyone agreed that it was an "insignificant" change so it was added to a patch without going through the Quality Assurance department. Everybody was happy.. except for this major customer, in whose database the new execution plan caused by a bug in the query optimizer changed the screen display time to go from 1 minute to 15 minutes. The "minor" change caused us a lot of grief.
|
|
#25
08-24-2002, 01:22 PM
|
|||
|
|||
|
The reason so many smart people continue to suggest changes is that they know the board could be better.
For smart people, their primary answer to life is "yes". When Una was posed this identical suggestion at the Unaboard site, her answer was a simple "Yes. Thanks. Works great. Tell me when you have more suggestions." Maybe we should get her to work here and soften up the stonewall of "no" personalities.
__________________
Somebody has to be first, so let it be me 
|
|
#26
08-24-2002, 04:55 PM
|
|||
|
|||
|
Quote:
|
|
#27
08-25-2002, 02:09 PM
|
|||
|
|||
|
Quote:
But they DO have a leg to stand on. This thread and others like it, and most of this forum, are dedicated to discussing what would be best around here. As for donations, you will notice that they have continuously and steadfastly REFUSED any and all contributions. When OpalCat was offered the identical suggestion, her response was "Yes. Thanks. Works great. Tell me when you have more suggestions." And the collections helped fund the new server. Any more bright insights? Or does White Lightning only strike once?
|
|
#28
08-25-2002, 03:09 PM
|
|||
|
|||
|
Notice the difference between 'telling' and 'suggesting'. The Chicago Reader's business with this message board is to not stay behind and give the Straight Dope an internet presence, hoping it someday pays off. They depend on pleasing the teeming millions and making us think warm and happy thoughts about them (and thus let them, if they try, make money with us). They need us suggesting things that would make us even happier. They still also need some kind of "no" personality to cope with the random noise and find the average direction of demand, but then they have to follow it whichever it is, as far as they think it's worth to.
Arnold, such bugs always show up in obscure situations, or else they would have been eliminated in the earlier debug phases. How do you know that not avoiding changes doesn't on average make bugs show up earlier, causing less harm? Killing the messenger doesn't prevent getting bad news, and by nailing your door shut you can only delay them. If bugs lurk somewhere, blame the one who was supposed to find them, or the one who wasn't supposed to create them in the first place, but not the event that triggers them. So if this major customer had asked you for a minor change, you would have turned him down saying "Sorry, but we're afraid there are too many hidden bugs in our software, and we're lucky it runs the way it is." We are your major - your only - customer. We aren't one discrete person, you don't lose us either completely or not, we are continuous statistics. The goal is to find the optimum of our satisfaction versus the effort to reach it, and it absolutely doesn't matter how it's reached, as long it is reached, either in one big step or in many seemingly insignificant ones adding up. I'm sure the total amount of effort actually is smaller if you take many little, easy steps. And there certainly have been done bigger things for us than optimizing one image file. Our average desire seems to be faster loading pages. You don't need a chart to see that not having to load posts you don't need to read would both increase performance and reduce bandwidth. There's no need to find and measure the optimum to the n-th decimal place, and not being able to do it isn't a reason to do nothing at all. Set the number of posts anywhere between 50 and an arbitrary value you're sure of it's not too low again, and we all are better off than before. Just adding another little step in the right direction. Changing an image or the default setting for the number of posts isn't an operation after which the administrators have to take turns in poking the server with a stick to see if it's still safe to be in the same room with it. If things like this reveal bugs, then it's about time for them to show up. (Arnold, I tried to e-mail you last week and yesterday (re quick reply box bug). Seems there's something wrong with either your or my e-mail. Didn't you receive anything?)
|
|
#29
08-25-2002, 03:51 PM
|
|||
|
|||
|
One, take me to the Pit if you want to talk trash.
I get tired of people coming in here and criticizing the administration of this board, as if they could do better. Your first post raised my ire for several reasons: 1. You compare the SDMB to the Unaboard. To my understanding, Una is the owner/operator of her own board, and is free to operate it any way she pleases. Such is not the case here. There's a lot more going on here in terms of who's in control of the board, and there are many more issues with server strain and high traffic. Your criticizing the administration of this board by comparison is akin to accusing your local McDonald's of not caring about their customers because they don't heed every request that goes into their suggestion box, and defending yourself with 'well, the mom and pop burger joint down the street does it that way.' 2. You imply ( if a = b, and b = c, don't say you didn't say a = c) that the people that run this board are stupid and unresponsive. I take exception. 3. You don't get to make the personnel decisions at this board. 'Discussing what would be best around here' is decidedly different from insulting the people that run it now. I hesitate to say it, but -- if you're so upset with the way things are around here, perhaps you and your 6 posts would be happier somewhere else?
|
|
#30
08-25-2002, 11:25 PM
|
|||
|
|||
|
There's not a monotonic relationship between page size and server effort. With large page sizes, the server must redundantly serve the same posts several times. With small page sizes, the server must handle a larger number of discreet requests. Somewhere in between there, there is an optimum page size. The optimum size has not been determined empirically, but is estimated to be approximately 50 posts. So, 50 it is.
|
|
#31
08-26-2002, 11:06 AM
|
|||
|
|||
|
femtosecond, you misunderstood the situation. In the case I describe the program change revealed a bug in the underlying database software, with which our application was supposed to work. We have no control of the bugs in the software that our application has to work with. The example was meant to show why it's a good idea to be cautious with software changes.
A similar example would be the following: someone suggested once a change to the Spoiler tag. That change would have made the spoiler tag unable to work in some versions of Netscape. So we didn't implement the change. (We already have the problem that it doesn't work with Opera.) Let's suppose (though I agree that it's very unlikey) that changing the image makes it display incorrectly in some browsers. I don't see a lot of benefit to us in finding bugs in older versions of browser X. As far as the image being changed, we don't bother the Chicago Reader IS staff unless it's for a good reason. The minuscule change in page size by modifying the image is not sufficient reason. I'll check my e-mails tonight.
|
|
#32
08-26-2002, 04:40 PM
|
|||
|
|||
|
I know that the diversity of message boards is too big for this to prove anything, but I just checked the posts-per-page settings of some other high-traffic boards which I randomly picked off a list (of course we're in it!) found at vbulletin.com : 15,15,15,20,15,15,15,25 - Either they've all got server power to burn, or we're the only people smart (or desperate...) enough to find our optimum settings, or we're just different.
Chronos, The number of posts being read isn't independent of the page granularity. In GQ you would often want to go back a page to read the whole thread again, but about 95.4% of its threads don't even reach 30 posts. On the other hand, I highly doubt that in the big-thread forums not being able to read 50 posts instead of 30 would prompt another page request. In fact, as you can see, people ask for not having to load so many posts. Quote:
Arnold, ah, but if you are too cautious, you get outcompeted by someone who wasn't. Here too again, you have to find and try to reach the optimum between risk, effort, and benefit. Indeed, you're right, adding the quick reply box triggered a little itch in vBulletin just where you can't reach it. Does it mean you weren't cautious enough and it never should have been added? Or for what reason then did you add the spoiler tag in the first place? There was some risk, it took some effort, but the expected r/e/b ratio was pointing upwards. The really difficult thing is to pick out the positive ideas from the bad ones. Of course changing an image might make someone's cache explode. But if you can expect significantly fewer people complaining about this than that it would be nice to have a slightly smaller loading time, then there's a net benefit, then that's the direction to move in. The absolute risk could be kept smaller, but doing so and leaving out the little steps actually means relatively going backwards from where you could have come to with an optimal effort/risk ratio. We don't ask you to ring up the staff in the middle of the night whenever we've got a new suggestion. But surely they keep a list of "little things to do when there's some time for it which would add up in making the board a better one" and we could add to it. I've sent another mail at Mon, 26 Aug 2002 19:58:30 +0200 to make sure
|
|
#33
08-27-2002, 11:02 AM
|
|||
|
|||
|
I reinstalled the mod_gzip Apache module this morning in order to reduce bandwidth utilization for the web server. mod_gzip is an Apache module that can be added to the web server in order to compress files sent to HTTP 1.1 compliant browsers. We'll see a reduction in current bandwidth utilization by about 50%. That is what we've seen in the past when mod_gzip is running on the SDMB.
About 7 weeks ago we were forced to upgrade our Apache web server version. I didn't have time to reinstall mod_gzip at that time so we've been running without it for about 2 months. Will the reinstallation of mod_gzip make any noticeable performance improvements to the SDMB? Highly doubtful but the bandwidth savings will be significant. I know this isn't what people want but unfortunately it's what you're getting. Little to no increase in performance for the users but a definite reduction in bandwidth utilization for the Chicago Reader. Jerry
|
|
#34
08-27-2002, 11:10 AM
|
|||
|
|||
|
Thanks Jerry.
Hard to believe that an improvement in bandwidth utilization of that magnitude wouldn't have an effect on the end-user's perception of responsiveness... but hey, you're the Tech GodTM, so if you say it, I'll believe it.
|
|
#35
08-27-2002, 05:06 PM
|
|||
|
|||
|
Quote:
On the other hand, the Reader has to pay for bandwidth costs, so decreasing the bandwidth used is something that the Reader likes, and so they pay Jerry (upon him be peace) to do that for them.
|
|
#36
08-28-2002, 03:28 PM
|
|||
|
|||
|
Do you know how hard it will be for us to push up our bandwidth consumption back to the old value, when the server capacity isn't doubled at the same time? That's not fair!
|
 |
| Bookmarks |
| Thread Tools | |
| Display Modes | |
|
|
Linear Mode
