Code Optimisation

wolfman

I've seen quite a few posts about servers, load balancing, up and down time etc...

Modifying the hardware is one way to go to solve the problem, but also optimising the code, or making it leaner would also be a benefit.

I'm not sure how feasible it is, or how the source code is currently setup, but from looking at general pages their size is quite large. Most pages are over the 100kb mark without including css files, javascript or images.

Anything over 70kb is generally getting bloated.

This will especially eat up bandwidth usage. A re-style using css and cleaning up the code could drop the average page size from over 100kb, to around 50-60kb easily. May not sound like much, but say for example 100,000 pages are viewed in a week, that'd be a saving of around 5gb. Imagine how much it'd save over a year, plus it'd be less strain on the servers.

What would be the process with such a suggestion, and can others get involved?

tigermatt

wolfman wrote:

I've seen quite a few posts about servers, load balancing, up and down time etc...

Modifying the hardware is one way to go to solve the problem, but also optimising the code, or making it leaner would also be a benefit.

I'm not sure how feasible it is, or how the source code is currently setup, but from looking at general pages their size is quite large. Most pages are over the 100kb mark without including css files, javascript or images.

Anything over 70kb is generally getting bloated.

This will especially eat up bandwidth usage. A re-style using css and cleaning up the code could drop the average page size from over 100kb, to around 50-60kb easily. May not sound like much, but say for example 100,000 pages are viewed in a week, that'd be a saving of around 5gb. Imagine how much it'd save over a year, plus it'd be less strain on the servers.

What would be the process with such a suggestion, and can others get involved?

The only trouble is that vBulletin (the forum software) dynamically generates the pages running PHP code with the MySQL database server backend. This would mean a whole change in the PHP code and the templates it uses for generating pages.

There's also the new site design coming sometime soon so hopefully that will significantly reduce the size of the pages on the main site and the forum.

I presume the output from vBulletin is compressed (Gzip I think) so that it doesn't use too much bandwidth???

wolfman

Ah yeah, I know regarding the forums it'd be quite tricky. I've not used, or looked at vBulletin before so wouldn't really know. Should really finish the forums I started coding. It's in .Net though so that puts it out the window.

Forums aside though, the site itself could still do with being optimized. If though, as you say, a redesign (which'll be appreciated too!) is on the way then we'll have to wait and see.

With regards to the design then, is there any way of making some form of input into it. Not with regards to how it looks, but accessibilty, usability, good design, best coding methods etc... I'm sure there are a wealth of people on these boards that could give effective input.

tigermatt wrote:

I presume the output from vBulletin is compressed (Gzip I think) so that it doesn't use too much bandwidth???

Not sure I understand you there. What's sent to the browse is html, which is what I'm referring to using up the bandwidth.

tigermatt

wolfman wrote:

tigermatt wrote:

I presume the output from vBulletin is compressed (Gzip I think) so that it doesn't use too much bandwidth???

Not sure I understand you there. What's sent to the browse is html, which is what I'm referring to using up the bandwidth.

There's definately an option in my vBulletin settings (two options actually :rolleyes:) that do a thing called Gzip'ping. One turns this setting on and off and the other decides what compression level is used.

Here's what the options say:

1. On/Off Gzip: Selecting yes will enable vBulletin to GZIP compress the HTML output of pages, thus reducing bandwidth requirements. This will be only used on clients that support it, and are HTTP 1.1 compliant. There will be a small performance overhead.
2. Compression Level: Set the level of GZIP compression that will take place on the output. 0=none; 9=max.
   
   We strongly recommend that you use level 1 for optimum results.

Just doing a search on Wikipedia to see what Gzip actually is - all I know is that it is a compression tool.... http://en.wikipedia.org/wiki/Gzip

I hope this has given you more information

wolfman

Ah yeah now I get you. Actually seen that with Apache before, but never really used it. A solution I guess, although not direct, in terms that you're just masking the wound rather than healing it.