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.
No. But I for one am not willing to spend the time to play around with the setting and chart server response time as related to the default number of posts per page. Even then, without access to server logs, it would be difficult for me to measure the effect of such a change.
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?
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 situation[sup]1[/sup]. 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?
[sup]1[/sup]An 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.
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.
Maybe you should purchase the Chicago Reader so you’ll have a leg to stand on when you tell them how they should run their business (and while you’re at it, throw some money our way for a new server and some more tech support).
Do YOU own part of the Chicago Reader? No? Then by your logic, YOU don’t have a let to stand on. Nor would the others above.
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?
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?)
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:
- 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.’
- 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.
- 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?
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.
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.
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.
It looks like conditions have changed since it had been determined. I guess it’s almost impossible to estimate the optimal settings, you have to determine them empirically, there are too many variables. Perhaps there’s such a big performance penalty on generating more pages that making them smaller wouldn’t pay off in gaining bandwidth. But it seems more than equally possible for it to shave off some of the unwanted server load. You won’t find out until you try again, and the potential benefit would be worth to branch off some effort into it.
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
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
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 God[sup]TM[/sup], so if you say it, I’ll believe it.
For you or I reading the threads and posting here, bandwidth is not the bottleneck. The bottleneck is in how fast the server can process the database queries. More memory or processor power, or faster disk access, might improve this, but all of those things cost more than gzip.
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.
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! 