I get lots of them...

Why not do what I saw some newspapers did when their server load went up after A Certain Violent Incident a couple of years ago: use a temporary minimal design.

Something like this:

[www.ludd.luth.se]

or even like this:

[www.ludd.luth.se]

(of course "read comments" should be changed to "add a comment" when there are no comments)

I can't speak for the others, but I believe there's been far too much work gone into this site to start stripping it apart to its basic components. All the features on the site have been requested time and time again, it's taken thousands of hours of development time, and I'd hate to see it ruined. At the end of the day, aside from a handful of SQL queries, your stripped site is still going to generate a similar load. All the SQL queries etc are cached for 5 minutes these days - you very very rarely see a page "live" as it were. That's not what's causing the problem. The problem is simply one of MASSIVE IO load in displaying and generating pictures. Unfortunately, your solution doesn't solve that - it still has to be done.

Unfortunately, as we've said, we require new hardware. We need it urgently. The site costs me over $300 USD every month to run, and the new hardware we need will cost over $500 USD every month. I'm not paying that.

As of today, ONE PERSON has donated to help the site from its current situation. I don't see the point of putting even more development time into making the site work better for those people who aren't willing to support it anyway.
Basically, we're being left no choice but to turn to advertising for revenue to pay for the site. Last month we used over 600GB of data. This, along with hardware, does NOT come cheap. We have created a new user class for people who donate so that if they do so they'll not see any advertising, and as much as we *NEVER* wanted to have advertising on the site, its own popularity requires it. Even without the current server load problems, with the increase of bandwidth use every month we'll need a similar amount of money to pay for that within the next 2 months regardless.
It's a little disappointing that out of 15,000 visitors per day, 10,000 of which are pretty much daily viewers, only one person has stepped up to help us when we requested it.

"Last month we used over 600GB of data."

30% of which was html code? (just guessing)

Oh! Hang on! You're not talking about what goes through the wires (but you're bound to hit the ceiling there too eventually). You're talking about all your little statistics calculations behind the surface?! Quite frankly, most of your users probably couldn't care less about those! (and just because you spent hours developing a feature it doesn't mean it's automatically a *good* feature)

You could offer a "minimal" design as an alternative "style" for the site and see what happens...

[www.catb.org]

[and BTW, I've been meaning to "strip apart" my own site "to its basic components" for years (at least, since 2000). It hasn't happened yet (it's still not "mature" in my head), but I don't see that as a Bad Idea either... Actually, I have done two such complete redesigns, (in 1996 and 1998) and even though it meant throwing out lots of work, the result was worth it.]

You're right, however because we've spent hours developing a feature DOES mean I don't want to just throw it away. Bandwidth use isn't causing the too many connections problems. That's just ANOTHER problem that's coming soon, and that is automatically solved by the new server as it'll come with more than 2x the data allowance of what we have now. And when I say 600GB, I meant in images. Down the wire. HTML is on top of that, and maybe only around 5%.

You're right, the site has suffered a little bit of "feature creep" but the vast majority of the work has been done behind the scenes on optimisation. Aside from a couple of little things like recommended images and categories (which I believe you were one of the people petitioning for) what's really changed lately? Neither of those use resources.

What does use resources is when you go from 200 users online in a peak hour to over a thousand - in about a 6 week period. We don't have CPU issues. It's got nothing to do with how "bloated" the site has become HTML-wise. Our problem is PURELY I/O. When the load average suddenly slams over 50, and IOWAIT is 100% of the delay, and CPU is still 80% free, that's not telling me the site is too bloated. It's telling me we need faster disks, SCSI interfaces and better hardware. Because we rent this server, we can't just upgrade a part of it, we have to replace the whole damn thing.

This site runs off a pretty low spec desktop PC at the end of the day. Cheap nasty shit because it's cheap to rent. It's a 2.4ghz P4 with 512 meg RAM and one IDE disk. Even a second disk would make a world of difference to the IO problems, however that's $50 setup and another $40 USD a month to rent. Given when the site was started it was just run off the back of another server I ran, and used zero resources, it cost nothing. Now it requires its own DEDICATED server.. and that's not good enough.. the costs are out of control.

The statistics generation (such as top viewed, users online, etc) takes a percentage of a second, and is done once every few minutes and cached for all users to see. Again, the things you have stripped out of the site for your "minimal" design are NOT what is causing the delays.

Your pages are 40kB html and 20kB logos, stars and stuff. If that's "5%" then the images have an *average* size of 1MB. I find that very hard to believe. Somewhere between 20-100kB, sometimes as much as 300kB per image, with an average less than 100kB sounds more likely to me. Compared to that your html pages are something like 30% of the total load.

That's odd. Wget just grabbed this current thread, and including all the text above it's still less than 20KB.

-rw-r--r-- 1 root root 20392 Feb 1 06:45 232

Then I did a wget on a random image, 8694, and the HTML for that page worked out to be under 8KB.

-rw-r--r-- 1 root root 7528 Feb 1 06:46 8694

The #plus613 logo at the top of the page was even more surprising.

-rw-r--r-- 1 root root 2543 Nov 9 23:01 plus-logo.gif

The stars make up a whopping 1,800 bytes.

-rw-r--r-- 1 root root 349 Nov 9 23:01 stars-1.gif
-rw-r--r-- 1 root root 438 Nov 9 23:01 stars-2.gif
-rw-r--r-- 1 root root 444 Nov 9 23:01 stars-3.gif
-rw-r--r-- 1 root root 453 Nov 9 23:01 stars-4.gif
-rw-r--r-- 1 root root 322 Nov 9 23:01 stars-5.gif

And finally, that massive question mark that you can mouseover and it gives you instructions.. that's worth a huge 417 bytes.

-rw-r--r-- 1 root root 417 Dec 6 21:50 question.png

So, all told, HTML, the logo, the stars, the question mark for image 8694 comes to a whopping 12,494 bytes.

I don't quite understand where you're getting your figures from.

Even so, even IF the HTML is more than 5%.. even IF it's 80% of the bandwidth usage....... how exactly does that affect the I/O throughput of the server?

I don't know if you noticed, but I already did this calculation on one of your pages (it's in the "revert" thread, January 26, 2005, 4:42 am). The result I found was 40 kB for the html alone, and 70 kB for the whole page minus the content image.

Hang on! You're looking at *this* page?! A *text* page! I'm talking about those other pages that people come here to see, the heavy pages with the big images. Those are a lot bigger than 12kB.

Was it a page with a large number of comments? My numbers sure as hell don't match that

Ultimately, server side, the size of the HTML is irrelevent. Apache generates the HTML from a couple of PHP scripts. It's all in memory and doesn't really touch the disks.

The only thing that uses the disks, and causes I/O load, are displaying images and logging hits into the access_log, and occasional SQL queries that aren't already cached.

We're considering putting the database into a ramdisk to speed it up and remove it from the I/O pool, however this would require a reboot and that's not something we're too keen on.. and we probably don't have enough RAM either.

Don't get me wrong, I appreciate your views, and you make a lot of good suggestions.. I just don't think it'd make THAT big a difference. The I/O load on the server shoots through the roof, which means it starts queueing tasks, which suddenly start blasting the SQL server and too many connection problems are seen. I really do think the only way forward is for all SCSI, and at least 2 disks.. and the next level of server up from where we are provides this. At a price.

[Bleah! Exact page size varies, of course, with how much text is on it...]

To make more comparable numbers, here's my go at downloading this page "with everything":

html page: 34074
arrow: 90
globe: 868
css files: 2828 + 729
logo: 2543
?-mark: 417
js files: 6256 + 15560
thumbnails: 6955 + 6120 + 8027 + 5612 + 5508 + 3152 + 10104 + 1813 + 20062 + 2833
some little gif: 574

Sum, html only: 34 kB, or 33 if we consider that I've made a couple of posts since your measure.
Sum, everything: 134kB

Remember: it's what the users sees that matters, not what's in your "raw data" files.

Anonymous@199228 posted on February 1, 2005, 7:06 am
Hang on! You're looking at this* page?! A *text page! I'm talking about those other pages that people come here to see, the heavy pages with the big images. Those are a lot bigger than 12kB.

--

If you re-read what I wrote...

Then I did a wget on a random image, 8694, and the HTML for that page worked out to be under 8KB.

-rw-r--r-- 1 root root 7528 Feb 1 06:46 8694

The HTML for image 8694 was 7528 bytes. The 20k comment was just an example that even a page FULL of text isn't very big.

The thumbnails on the image pages are only loaded if you mouseover on them. However, I'll concede that I forgot about the JS and CSS files.

If you want the "raw data" as it shows up at this end:

sister~/www/pics/temp>ls -l 232*
-rw-r--r-- 1 vk other 34074 Feb 1 15:13 232.html

232_files:
total 212
-rw-r--r-- 1 vk other 90 Feb 1 15:13 arrow.gif
-rw-r--r-- 1 vk other 868 Feb 1 15:13 globe.gif
-rw-r--r-- 1 vk other 2828 Feb 1 15:13 new-main.css
-rw-r--r-- 1 vk other 729 Feb 1 15:13 nicetitle.css
-rw-r--r-- 1 vk other 2543 Feb 1 15:13 plus-logo.gif
-rw-r--r-- 1 vk other 417 Feb 1 15:13 question.png
-rw-r--r-- 1 vk other 6256 Feb 1 15:13 sorttable.js
-rw-r--r-- 1 vk other 6955 Feb 1 15:13 thumb-bici.png
-rw-r--r-- 1 vk other 6120 Feb 1 15:13 thumb-jt.png
-rw-r--r-- 1 vk other 8027 Feb 1 15:13 thumb-lohan-050904-06.png
-rw-r--r-- 1 vk other 5612 Feb 1 15:13 thumb-vida-guerra-skins-01.png
-rw-r--r-- 1 vk other 5508 Feb 1 15:13 www_plus613_com_045906.jpg
-rw-r--r-- 1 vk other 3152 Feb 1 15:13 www_plus613_com_Rasputin.jpg
-rw-r--r-- 1 vk other 10104 Feb 1 15:13 www_plus613_com_finger.jpg
-rw-r--r-- 1 vk other 1813 Feb 1 15:13 www_plus613_com_image024.jpg
-rw-r--r-- 1 vk other 20062 Feb 1 15:13 www_plus613_com_sensi.jpg
-rw-r--r-- 1 vk other 2833 Feb 1 15:13 www_plus613_com_uccello.jpg
-rw-r--r-- 1 vk other 15560 Feb 1 15:13 wz_tooltip.js
-rw-r--r-- 1 vk other 574 Feb 1 15:13 x-click-but21.gif
sister~/www/pics/temp>

(I missed that you counted two different pages.)

"The thumbnails on the image pages are only loaded if you mouseover on them."

???

Back to the pages thing...

Image page 8694... same experiment...

sister~/www/pics/temp>ls -l 8694*
-rw-r--r-- 1 vk other 19717 Feb 1 15:28 8694.html

8694_files:
total 410
-rw-r--r-- 1 vk other 90 Feb 1 15:28 arrow.gif
-rw-r--r-- 1 vk other 2828 Feb 1 15:28 new-main.css
-rw-r--r-- 1 vk other 729 Feb 1 15:28 nicetitle.css
-rw-r--r-- 1 vk other 2543 Feb 1 15:28 plus-logo.gif
-rw-r--r-- 1 vk other 417 Feb 1 15:28 question.png
-rw-r--r-- 1 vk other 6256 Feb 1 15:28 sorttable.js
-rw-r--r-- 1 vk other 349 Feb 1 15:28 stars-1.gif
-rw-r--r-- 1 vk other 438 Feb 1 15:28 stars-2.gif
-rw-r--r-- 1 vk other 444 Feb 1 15:28 stars-3.gif
-rw-r--r-- 1 vk other 453 Feb 1 15:28 stars-4.gif
-rw-r--r-- 1 vk other 322 Feb 1 15:28 stars-5.gif
-rw-r--r-- 1 vk other 83930 Feb 1 15:28 www_plus613_com_045906.jpg
-rw-r--r-- 1 vk other 2617 Feb 1 15:28 www_plus613_com_AmericanStar.jpg
-rw-r--r-- 1 vk other 30304 Feb 1 15:28 www_plus613_com_Slipknot0.jpg
-rw-r--r-- 1 vk other 37609 Feb 1 15:28 www_plus613_com_deblaasInthewater_4248.jpg
-rw-r--r-- 1 vk other 1448 Feb 1 15:28 www_plus613_com_need20asplint.jpg
-rw-r--r-- 1 vk other 5708 Feb 1 15:28 www_plus613_com_quiteperfectthaiteen.jpg
-rw-r--r-- 1 vk other 6865 Feb 1 15:28 www_plus613_com_uglypeople.jpg
-rw-r--r-- 1 vk other 15560 Feb 1 15:28 wz_tooltip.js
-rw-r--r-- 1 vk other 574 Feb 1 15:28 x-click-but21.gif
sister~/www/pics/temp>

My comment: 19 is more than 8.

[Also: 34 is more than 20]

Consider how much information has been posted to this thread since I did that test

I dunno. Anyway I still don't care about the bandwidth at the moment, that's a problem for a couple of months from now, but if we do have to get the new server (which it still looks like we do) then the data problems are automatically fixed.

The problem is still I/O load.. And it's rapidly approaching 2am so maybe I'll care more tomorrow

to help clarify, the thumnails your including in your 'html' 199228 aren't loaded unless the user puts the mouse over the thumbnames for at least 1 second. So really you can't count them as they aren't loaded for each view.

So the total for your page views is 49k.

Yes this is a fair wack, however the real killer is simply the total randomness of having to access over 865M of images spread out over 8173 images (200k per image - a guess). Which would be fine except for 800+ people trying to do it at the same time.

If we did have a html minimal setup of the site it still would only help by a small amount, and then we'd have the same problem with 850+ users.

Ok i'll let you 2 get back to it

You keep talking about "IO load" but I'm not sure what you mean by that... Your pages (with or without the big content images) are huge, and they are slow (even if I don't count the half second or so extra it takes for the signals to travel around the world). A couple of big improvements on the speed was when you removed the transparent background (it was cute, but not practical) and another was when you set the image size in the html, but I still say that all those navigation links on the image pages are unnecessary. There it makes sense to have certain navigation links: 1. "Up to homepage", 2. "Up to gallery page this image is in", 3. "contact us" (email link), 4. "next".

Also, I get the impression that the thumbnail pages reload from the server every time I click "back" in my browser. That's one side of server settings I've never had to play with, but it might make a difference at your end... A frames solution would mean only loading that page once...

[www.ludd.luth.se]
[www.ludd.luth.se]
[www.ludd.luth.se]

A quick and dirty version of that would be to add to the tag in the design you already have.

DarkKlown >> Are you sure? When I saved that page the little status box just flickered and vanished. If it had downloaded all the pictures at that point it would have taken more than a fraction of a second... (and when I write "html" I most certainly do *not* include the thumbnails, that's the "filename.html" file, which I can open in emacs and examine and it contains *html* (lots of this kind of useless bla-bla: ) and nothing else!)

What are you using to save the html, all the style stuff is in the css file, maybe the program your using to save the html is importing the css into the html before it saves?

it's alot smaller html if it just says class="somethinguniq" rather than bgcolor="#e6ecff" style="padding: 3px;">

IO load = reading files from the hdd, or writing data to that disk..

I used Mozilla to save those pages. It saves a page including all the little files the page includes. The saving was very quick. So quick that I suspect that those thumbnails were already loaded even though I had not moused over them (I had not come up with the idea that that was possible and I was mystified by their presence) (hard to check that though).

The font bla bla stuff is copy-pasted straight out of one of your pages. Apparently you set a font several times in different ways and apply it to an image.

But I can also use Netscape 3, in which case the html files I get are - just as big.

[Netscape 3 doesn't do CSS and completely ignores those files. It also does not change the original in any way and only saves the html.]

"IO load = reading files from the hdd, or writing data to that disk.."

Aha. I got the impression that I was saying "your nose is green" and getting a reply "no, it's not, because my nose is green". :-)

"the html files I get are - just as big."

Not quite true. They are slightly smaller (say 34 instead of 36 kind of smaller).

sdgsszsfaftj@76215 >> You should try that in a monospaced font next time. Here's one of mine:

[www.ludd.luth.se]

I guess in the end #199228 is that whatever the design someone has to pay cash for it.

Thanks for feedback and suggestions for design layouts but we're just not ready yet. However I'm thinking of doing a little bit of work on the forum if you have any ideas.

Yes. I have an idea for the forum:

You change the URL to each discussion every time there is a new post in that discussion. That way it's easy to see when there are new posts (because they will be the "blue" links at the top of the list). In those discussions where you have already read the latest post the URL will be the same as when you looked at it, so they will show up as "purple".

E.g. a discussion the way things are now could be:

[www.plus613.com]

if you add the number of posts:

[www.plus613.com]

and then there is a new post:

[www.plus613.com]

When you click on a discussion where somebody has made a new post between the point when you loaded the forum list and when you actually clicked on the link you can do one of those redirect thingies, so that the URL is updated properly (and the user won't notice a difference).

Example of where I have used that is this URL to an old page:

[www.ludd.luth.se]

which is now part of a bigger page, in a different place, but the old address still "works".