BF2S Forums Testing new images server

theres probably some sneaky catch that only allows u to use some taliban 56k servers for the first month free?

It takes me about 5 minutes to load up the stats pages and the pictures don't even come out, I don't believe it is a problem on my end, but i could be wrong.  I just beg of you, for the love of god, go back to the way it was... please...

Aloha,

Been primarilly using bf2s.com to check up on my stats and because of the recent probs i've been using bf2player.com (boo! hiss! )..

Anyway, I did a few websites for the company I work for. Two of them are purely static content only that are on hosting providers and the others (essentially one site but with multiple virtual hosts for different customers etc) are on our own inhouse webserver with a backend sql server. This webserver is hosted on our ADSL connection, so I had to really optimise the pages to be as small as possible so as to prevent our line from getting hosed.

For obvious reasons I'm not going to give the addresses.

I've quickly looked at a few things which you may want to change:

* Images, you extensively use 8bit GIF images.
* HTML Generated code, includes extensive spacing
* Javascript code that should be moved to a seperate .js file.
* Compress your webpages.

Images (i'll give a couple of examples):

bg.gif (23,266 bytes) - contains 256 colours and is an 8bit (256 colour) file.
inner-header.gif (5,526 bytes) - contains 128 colours and is an 8bit (256 colour) file, if you want to reduce this filesize whilst not losing any quality reduce it to 7bit (128 colours).

Doing the above, (reducing the bit depth) slightly reduces the sizes of the images whilst not losing anything in quality.

However, we'll lose at most a few bytes to a kilobyte tops.

To really reduce the filesizes you need to use a different format. Aka, PNG.

Lets convert the two files to PNG images.

http://homepages.nildram.co.uk/~mccasey/bf2s/new/bg.png (10,379 bytes)
http://homepages.nildram.co.uk/~mccasey … header.png (3,426 bytes)

That's a reduction of 12,887 bytes for bg and 2,100 bytes for inner-header!

Now, that's just two images but essentially for most GIF images over half a kilobyte you'll find a reduction in filesize. For lower sized images say <100 bytes you'll find GIF to be the better choice.


HTML Generated code contains spacing:

There are a couple of ways to remove all that spacing;

A. Manually remove the spacing.
B. Remove it at the server side.

For "A" it makes the HTML less readable when you're needing to edit it but reduces the size of the HTML file sent to the client.
B is typically an Apache module or something for PHP that removes the spacing before sending it on to the client. Downside to this is it might increase processor usage on the server, upside to this is that it doesn't screw up the readability of your original HTML/PHP files.


Javascript code that should be moved to a .js file:

The reasoning for this is simple, web browser caches. Everytime a web browser visits the site it's downloading your newly generated version including the same javascript code every single time. By moving the javascript into a seperate .js file it'll reduce the bandwidth as the client won't typically redownload the .js file (after the first download) unless they've told the browser to disable the cache.


Compress your webpages:

Let's have a look at the HTTP headers typically served from your webserver;

HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
X-Powered-By: PHP/4.4.0
Content-type: text/html; charset=utf-8
Date: Fri, 10 Feb 2006 00:17:57 GMT
Server: lighttpd/1.4.9

It appears as though you don't have gzip compression enabled for webpages, this can SIGNIFICANTLY reduce the size of text. The downside is that it obviously uses processor time to compress the page and also there have been security issues in the past involving zlib.


Other stuff off the top of my head, you can move it onto something like perl and literally generate the pages on a schedule rather than everytime requested.



PS.

For saving images the Gimp is excellent, Photoshop and a lot of other commercial programs tend to add little bits of crap to the images that increase their filesize.

For an example of settings you should use for PNG saving under see below..



Mark

Last edited by EvilMonkeySlayer (2006-02-09 16:38:51)

Chuy, are you rich? lol jk

Wow seems like a really good price.  Unfortunately i just spent about 15 minutes waiting for something to load (my new characters stats page).  I finally gave up and moved on when the status bar hadn't moved in 10 minutes.  I know something needed to be done, but i hope that it gets better than this.

EvilMonkeySlayer wrote:

Aloha,

Been primarilly using bf2s.com to check up on my stats and because of the recent probs i've been using bf2player.com (boo! hiss! )..

Anyway, I did a few websites for the company I work for. Two of them are purely static content only that are on hosting providers and the others (essentially one site but with multiple virtual hosts for different customers etc) are on our own inhouse webserver with a backend sql server. This webserver is hosted on our ADSL connection, so I had to really optimise the pages to be as small as possible so as to prevent our line from getting hosed.

For obvious reasons I'm not going to give the addresses.

I've quickly looked at a few things which you may want to change:

* Images, you extensively use 8bit GIF images.
* HTML Generated code, includes extensive spacing
* Javascript code that should be moved to a seperate .js file.
* Compress your webpages.

Images (i'll give a couple of examples):

bg.gif (23,266 bytes) - contains 256 colours and is an 8bit (256 colour) file.
inner-header.gif (5,526 bytes) - contains 128 colours and is an 8bit (256 colour) file, if you want to reduce this filesize whilst not losing any quality reduce it to 7bit (128 colours).

Doing the above, (reducing the bit depth) slightly reduces the sizes of the images whilst not losing anything in quality.

However, we'll lose at most a few bytes to a kilobyte tops.

To really reduce the filesizes you need to use a different format. Aka, PNG.

Lets convert the two files to PNG images.

http://homepages.nildram.co.uk/~mccasey/bf2s/new/bg.png (10,379 bytes)
http://homepages.nildram.co.uk/~mccasey … header.png (3,426 bytes)

That's a reduction of 12,887 bytes for bg and 2,100 bytes for inner-header!

Now, that's just two images but essentially for most GIF images over half a kilobyte you'll find a reduction in filesize. For lower sized images say <100 bytes you'll find GIF to be the better choice.

PNG comes with it's own failings, of course. First of all, PNG gets rendered differntly from platform to platform and even on the same platform such as windows Firefox to IE. I went this method at first, but it failed.

Small reductions in the other files may be worth further optimization.

EvilMonkeySlayer wrote:

HTML Generated code contains spacing:

There are a couple of ways to remove all that spacing;

A. Manually remove the spacing.
B. Remove it at the server side.

For "A" it makes the HTML less readable when you're needing to edit it but reduces the size of the HTML file sent to the client.
B is typically an Apache module or something for PHP that removes the spacing before sending it on to the client. Downside to this is it might increase processor usage on the server, upside to this is that it doesn't screw up the readability of your original HTML/PHP files.

It's my theory that gzip compression completely negates the need to do white-space stripping. I have no yet tested this, however.

EvilMonkeySlayer wrote:

Javascript code that should be moved to a .js file:

The reasoning for this is simple, web browser caches. Everytime a web browser visits the site it's downloading your newly generated version including the same javascript code every single time. By moving the javascript into a seperate .js file it'll reduce the bandwidth as the client won't typically redownload the .js file (after the first download) unless they've told the browser to disable the cache.

Most of it is. There are a few parts which I am lax on and haven't moved out.

EvilMonkeySlayer wrote:

Compress your webpages:

Let's have a look at the HTTP headers typically served from your webserver;

HTTP/1.1 200 OK
Connection: close
Transfer-Encoding: chunked
X-Powered-By: PHP/4.4.0
Content-type: text/html; charset=utf-8
Date: Fri, 10 Feb 2006 00:17:57 GMT
Server: lighttpd/1.4.9

It appears as though you don't have gzip compression enabled for webpages, this can SIGNIFICANTLY reduce the size of text. The downside is that it obviously uses processor time to compress the page and also there have been security issues in the past involving zlib.

Odd, all the pages on this site SHOULD be getting send out using gzip since I initialize it at the start via PHP. I'll check into this.

EvilMonkeySlayer wrote:

Other stuff off the top of my head, you can move it onto something like perl and literally generate the pages on a schedule rather than everytime requested.

For a few pages, I already do this -- using php. The homepage, for instance, is (mostly) static with a few small parts updated on load. A few other pages are like this, however the majority of pages this wouldn't make sense to do this for. (There's a lot of reasons behind this that I'd rather not get into.)

EvilMonkeySlayer wrote:

For saving images the Gimp is excellent,

p.s., I loathe "The Gimp". As for photoshop adding extra "stuff" it only does that if you don't know how to use it

Also, there are fantastic "cruncher" programs out there that do even better -- mostly for PNG though.



Thanks for the input.

Have you considered changing all your static urls to use the Coral cdn?

(ie: add .nyud.net:8090 to the end of the hostname in the URL)

More info here:
http://www.coralcdn.org/

I agree with dan500, I'm sure NVidia would pay nicely to sponsor the site, and I don't think many of us would be too bothered by the ads (as long as they aren't too intrusive or obnoxious).

PM me, i have all the answers for you.
scooby will save the day.

Cougar wrote:

Chuy pwned a server.

Nope. We pwned the server. Chuy just made it possible

dan500 wrote:

This might sound stupid but i'll say it;

BF2s has grown a LOT, not only into a stats site, but into a big community (all them points are plus's).

Why not approach such companys as nvidia, ATi, BF2s already has a name on other website's, so why not ask these companys for sponsorship, I would not mind a something advertising for them, I think this site gets enough hits for big companys to think about this, just a idea.

This might be a realy great idea I was asked today by a couple guys in the squad i was in about my video card and what i thought would be the best one for running BF2 with. That and i was asked about my joystick! ** I use a Saitek X45 for jets and my mouse and X45 throtle for Helos. Still working out tanks and jeeps.** But get a say three or four big names behind you and say have all four with ad on home page and maybe a rotating banner on the Fourm page that shows one then showes the next after a time........Might give you the extra help in cash to solve your problem. That and i have heard that they have been know to give gifts to people/companies that give them a boost. So if you were to be able to get backing by who ever it is that makes your servers and let it be known that they are the servers behind the site. Maybe they would hook you up with a better one!
       P.S. I don't know about software to save my life, Hardware a little......get me in to the components I.E. resistors, Caps, and Leds then i know whats going on. So bear with me If i get some things wrong.

EvilMonkeySlayer wrote:

Right, about the PNG colour problem. This is the gamma setting, you can sync up the colouring between IE and Firefox if memory serves. (i'll look into this when I get into work, I had the same problem)

I'm all ears, all the literature I've read says otherwise.

While using gzip compression does significantly reduce filesize removing whitespace before compression and then gzipping will make the output slightly smaller. (marginally so)

I double checked and I am certainly sending out gzipped content -- make sure, however, that when you do the request you have your testing setup include the "accepts: gzip" header Otherwise PHP is smart enough to NOT do that.