Hjælp til Amino's services

Svar: The Amino Speed Project

Kim Tetzlaff - Kim Tetzlaff ApS — Thu, 24 Mar 2011 16:06:26 GMT

Martin Thorborg:
Well, the average load time is 3 seconds and that is ok.
But we know that the faster Amino loads, the happier users, so it is something we spend time and money on. But we don't have unlimited resources

And don't forget a happier Google ;)

MVH Kim

Svar: The Amino Speed Project

Jacob Rohde — Thu, 24 Mar 2011 16:00:52 GMT

Martin Thorborg:

Martin:

Your site is by all definitions slow - to the point where users make topics about it.

Just loading this page to comment was a 8.9 second load.

Wether or not you want to spend the money to fix it is clearly your choice. I hope you get the best out of the many valid point provided in here and hopefully, in time, the site will run much faster.

Well, the average load time is 3 seconds and that is ok.
But we know that the faster Amino loads, the happier users, so it is something we spend time and money on. But we don't have unlimited resources.

Cheers

Martin

Also - when 1902 have implemented some of the new changes. I am sure it will load pretty well. So we will all be happy. We all want a fast site of course :) So let us rejoice on the speed project here on Amino's birthday :)

Svar: The Amino Speed Project

Martin Thorborg — Thu, 24 Mar 2011 15:58:14 GMT

Martin:

Your site is by all definitions slow - to the point where users make topics about it.

Just loading this page to comment was a 8.9 second load.

Wether or not you want to spend the money to fix it is clearly your choice. I hope you get the best out of the many valid point provided in here and hopefully, in time, the site will run much faster.

Well, the average load time is 3 seconds and that is ok.
But we know that the faster Amino loads, the happier users, so it is something we spend time and money on. But we don't have unlimited resources.

Cheers

Martin

Svar: The Amino Speed Project

Martin — Thu, 24 Mar 2011 15:26:57 GMT

Martin Thorborg:

Well, i don't blame you for not understand, because you don't know our business ;-)
First of all, there is more to a business than speed.
One thing is revenue, another is fixing worse errors than speed and I could go on...

Of course there is more to running a business than page speed, but i don't recall making that statement. It was you who started a thread about improving page speed, naturally i assumed that was the topic.

Martin Thorborg:

So Jacob is absolutely right. The speed on Amino is ok, and the site works ok.
But we will implement optimized code a one piece at a time, over the next 6 month.

Your site is by all definitions slow - to the point where users make topics about it.

Just loading this page to comment was a 8.9 second load.

Wether or not you want to spend the money to fix it is clearly your choice. I hope you get the best out of the many valid point provided in here and hopefully, in time, the site will run much faster.

G'day to you.

Svar: The Amino Speed Project

Kim Tetzlaff - Kim Tetzlaff ApS — Thu, 24 Mar 2011 14:44:35 GMT

Jacob Rohde:

KTJ-Media.dk:

Jacob Rohde:
The answer to this is to optimize our use of CSS and images. We can save a shitload of requests by using some CSS sprites. Some of our people will soon implement some of these changes that will make the sending of the page be much faster.
I know the solotion :) I gave you the solution. And yes you can save alot by using CSS sprites. And no the answer to that is not to use css sprites, but as i said to use HEX color code :)

In the case of single colors? Oh absolutely. I was more talking in general terms with our backgrounds.

OK, cool, just so we are on the same page ;)

Svar: The Amino Speed Project

Jacob Rohde — Thu, 24 Mar 2011 14:43:08 GMT

KTJ-Media.dk:

Jacob Rohde:
The answer to this is to optimize our use of CSS and images. We can save a shitload of requests by using some CSS sprites. Some of our people will soon implement some of these changes that will make the sending of the page be much faster.
I know the solotion :) I gave you the solution. And yes you can save alot by using CSS sprites. And no the answer to that is not to use css sprites, but as i said to use HEX color code :)

In the case of single colors? Oh absolutely. I was more talking in general terms with our backgrounds.

Svar: The Amino Speed Project

Jimmy B. Carlsen — Thu, 24 Mar 2011 14:42:31 GMT

CMS:
I would too prefer Hex color anytime possible instead of a css sprite. The intrepretation of a Hex color will always be faster then css sprites.

Working with PNG's in IE however, would require a separate IE-stylesheet for matching the color exactly. This is due to IE's faulty gamma-correction of PNG's.

Svar: The Amino Speed Project

Kim Tetzlaff - Kim Tetzlaff ApS — Thu, 24 Mar 2011 14:41:59 GMT

Try to red my post about what you can do, it is better in danish
http://www.amino.dk/forums/t/119405.aspx?PageIndex=3&#798982

And the english version :) and may I say a very bad version :)

http://www.amino.dk/forums/t/119510.aspx?#799182

Almost all the speed tips are very easy to implement, and Amino will gain alot from implementing those tips.

Svar: The Amino Speed Project

Designermøbler — Thu, 24 Mar 2011 14:39:34 GMT

I would too prefer Hex color anytime possible instead of a css sprite. The intrepretation of a Hex color will always be faster then css sprites.

Svar: The Amino Speed Project

Kim Tetzlaff - Kim Tetzlaff ApS — Thu, 24 Mar 2011 14:17:17 GMT

Jacob Rohde:
The answer to this is to optimize our use of CSS and images. We can save a shitload of requests by using some CSS sprites. Some of our people will soon implement some of these changes that will make the sending of the page be much faster.

I know the solotion :) I gave you the solution. And yes you can save alot by using CSS sprites. And no the answer to that is not to use css sprites, but as i said to use HEX color code :)

Svar: The Amino Speed Project

Jacob Rohde — Thu, 24 Mar 2011 13:07:37 GMT

KTJ-Media.dk:

I saw that you as a background on amino uses an image of 1x1 pixels, I do not understand why because it would be far better to just use a background color: #f0f0f0. You do not need to use an image for the background, it does’nt do any good.

The answer to this is to optimize our use of CSS and images. We can save a shitload of requests by using some CSS sprites. Some of our people will soon implement some of these changes that will make the sending of the page be much faster.

Svar: The Amino Speed Project

Jacob Rohde — Thu, 24 Mar 2011 13:03:03 GMT

Lundsby:
CQRS is all the rage these days, stands for Command Query Responsiblities Segregation, I would recommend looking it up on the net, understanding it and see if any of the ideas can be applied to Amino. I am currently doing a performance optimization, based on some of the ideas of it, and it's going to make writes in CloudSprout somewhere between 100 to a 1000 times faster.

Thanks for that - I will look into it, and see how it relates to our stack.

Lundsby:
If you a not on a 64-bit system, you really really need to be, it solves a lot of memory and related stability problems. Also the database needs to be on a 64-bit system, as it really likes the extra memory that can be allocated.

Yeah, we are all 64-bit

Lundsby:
Did you know that .Net 4 is significantly faster and better at garbage collection then it's predessessors. Upgrading to it is highly recommended.

Yeah .NET 4 is awesome. Most of our new services run in .NET 4. Our CS stack run in 3.5 if I am not mistaken.

Lundsby:
Personally I use DotTrace from JetBrains for serverside profiling and Firebug for client based. You could have a look at DynaTrace they have the only tool I know off that provides end-to-end profiling (Cool Stuff)

JetBrains make some awesome products! I couldn't code without R#. Anyways, we actually just purchased dotTrace the other day beccause of a perf problem we had. It is expensive but worth it. It took me perhaps ten minutes to find the culprit.

Thanks for your input - appreciated.

Svar: The Amino Speed Project

Martin Thorborg — Thu, 24 Mar 2011 13:02:48 GMT

Martin:
Why settle with "fine" ?

Well, i don't blame you for not understand, because you don't know our business ;-)
First of all, there is more to a business than speed.
One thing is revenue, another is fixing worse errors than speed and I could go on...

Another thing you obviously don't know, is that the Amino Platform is a product we bought several years ago and the platform is not supported anymore. So every thing we do, we do on our own on a platform we did not build. A lot of the suggestions mentioned in this thread, require us to tamper with the "DNA" of the system, which in some cases is a "black box" we do not have the source code to. So it would be foolish to just do stuff, even though you think it's easy or a "quick fix". If we fuck up this system, we are in deep trouble.

So in other words, trimming Amino is a huge and dangerous task, which will cost us a shit load of money and take a lot of time.

So Jacob is absolutely right. The speed on Amino is ok, and the site works ok.
But we will implement optimized code a one piece at a time, over the next 6 month.

Cheers

Martin

Svar: The Amino Speed Project

Jacob Rohde — Thu, 24 Mar 2011 12:13:43 GMT

Martin:

Jacob Rohde:

Unless I am misreading that chart - 3 seconds seem fine in relation to user loss.

Why settle with "fine" ?

As others have pointed out in this thread there are loads of things that can be done to optimize the site. Some can even be done rather quick and at minium costs.

I don't understand why you would ever settle with second best and the article at pearanalytics clearly states that every 100ms added to loadtimes have a negative effect.

As I have already stated there are some people looking into this and implementing some changes. So I don't know what you are insinuating.

Also it is a matter of resources. Should we spend time ad money going from 2.8 to 2.6 or should they be spend elsewhere. But anyways that is not a discussion I any way or form intend to take here.

Svar: The Amino Speed Project

Martin — Thu, 24 Mar 2011 12:08:37 GMT

Jacob Rohde:

Unless I am misreading that chart - 3 seconds seem fine in relation to user loss.

Why settle with "fine" ?

As others have pointed out in this thread there are loads of things that can be done to optimize the site. Some can even be done rather quick and at minium costs.

I don't understand why you would ever settle with second best and the article at pearanalytics clearly states that every 100ms added to loadtimes have a negative effect.