The Amino Speed Project

You can add HTML output caching, if not already done. This is ofcourse mainly for the static elements fo the page, since the threads are updated so often it doesn't benifit that much for HTML output caching.

You can also distribuate the cache by using Memcache/Velocity etc. if not already done. Thereby you can have one main server, one database and several caching serveres which are just thin clients.

You have probably already done this, but if not, look into it :)

Jacob Rohde:

Hi guys,

Thanks for your replies. I did first become aware of this issue last night, since I have not had any problems what so ever myself and just been insanely busy with other things. It can be a bit difficult to pin point what is going in since everything runs smoothly here. But I have looked at some things, and as far as I can see the actual server side stuff seems to be fine. Currently it takes about 2-5 seconds to generate the page depending on content, and that does seem ok I would say.

On the actual page send process, some things can be done. Most of this has already been mentioned here - though no all applies to our setup. But what I think we can look at first is to use some CSS sprites for some of the stuff, and try to bundle some of the JS files. Whether this alleviates the problem some are experiencing I am not sure, but it will make the pages render a bit faster.

Anyway, thanks for your posts - hopefully you will soon see the speed improving :)

What are you building it on that it should be fine with 2-5 seconds just to render a page? it is not because it's so much data to be rendered. I also think that if there is so much difference, it would appear that something is instability on the server or the programming code.

I optimized even simple programming code and won about 15 times as fast a rendering. It means of course that the website gets thrown out faster to users. The same I believe may well be the case with amino.dk if it takes between 2 and 5 seconds to render a page. it is simply too long no matter what website they are.

You say it is hard to say where exactly amino.dk should do something, but I say that if you look at the things I've written, it's all stuff you can do to optimize it and it will certainly make a whole lot of speed on the website. And there are certainly some places in the programming code where Amino.dk can also do something, read about speed optimization and you will become a part wiser. I doubt that you already have looked each a little code to go through to find the places where there are some bottlenecks, which can be optimized in the code.

Take the things I write as things you can do and use the tips you get. I have among other things, many years of experience with speed optimization, which also means that the things I say are thoroughly tested. So you can safely use the tips because they work perfectly.

My own page loads in less than 0.5 seconds, the first time, and 0,230 seconds the second time... And most sites (98%) I've optimized all came within 1 second, even though some of them started out at 8-9 seconds and it is among other things, the tips I've written that have done it.

Regards
Kim Tetzlaff

I also just ran a Firebug/PageSpeed.

First of all image caching should be set, obviously for all buttons and badges, but also for the avatars.

One of the other complaints that PageSpeed brings up is redirects. There are numeorus redirects for the avatars - which results in a huge amount of requests - and requests are expensive.

Another thing with the Avatars - it seems like the size of the requests exceeds a standard packet size of 1024 bytes, meaning that these requests requires twice as many packets.

Apart from these obvious things that page speed reports, you could probably reduce the number of user generated requests by increasing the number of posts per page (currently 10 - could be increased to maybe 25 (or even a user defined number). This would not only reduce the number of requests towards the web server, bu also the number of requests towards the database server.

All in all you have probably introduced a speed penalty when you changed the avatars functionality.

In addition to Firebug/Pagespeed you can also get a lot of request information from the Fiddler Web debug tool (which is also a free plugin for Firefox)

best regards

Jan

Many valid and good points in this thread. 3-5 seconds are acceptable at best, there's loads of things that can be done to get this site rolling more swiftly.

A number of users have suggested Page Speed - i would like to recommend ySlow for Firefox together with Page Speed to get the site up to terms.

Here's what ySlow says about the frontpage and the number of HTTP requests:

------

This page has 25 external Javascript scripts. Try combining them into one.
This page has 7 external stylesheets. Try combining them into one.
This page has 35 external background images. Try combining them with CSS sprites.

Decreasing the number of components on a page reduces the number of HTTP requests required to render the page, resulting in faster page loads. Some ways to reduce the number of components include: combine files, combine multiple scripts into one script, combine multiple CSS files into one style sheet, and use CSS Sprites and image maps.

------

Besides that ySlow features the "Smush.it" funtionality that allows you to compress your images further without visual loss.

As an example Smush.it will save you 47% on filesize for just the logo, so something tells me that you didn't apply proper compression for your site graphics. Especially .png images can be compressed by using some nifty Photoshop tricks, See http://www.smashingmagazine.com/2009/07/15/clever-png-optimization-techniques/ for further reference.

thevicarious:

Are the developers asking the users how to optimize their code?

Nope, I do.
Even though our developer are super, the brain of many skilled programmers, can come up with solutions, that are better than a couple of programmers can think up.
It's called knowledge sharing and using your network, you should try it ;-)

Cheers

Martin

It's not about whether the server is under stress or not. It is more about how we can optimize the code, web pages, database queries and more. As described earlier, the website can gain much speed right there. even if the server is not under stress and it might be much far from being so. it would be better for the website to optimize this part as much as possible. Both for the site will be faster but also make it more stable.

However, it is one thing that takes time to correct, so I'd still recommend the first look at the things I've written previously, because they are faster to implement and hence can achieve a lot in no time.

The image sizes are almost never set in the HTML output code, i.e: <img src="/cfs-file.ashx/__key/CommunityServer.Components.UserFiles/00.00.03.45.50.Vedh_E600_ftet+Fil/5621.TechoCowboy250x50.jpg" border="0" alt="" />

Some browsers renders the images slower when the size is not set, so do that if possible, it can increase speed in some browser. (and should hopefully be an easy, though minor, fix.)