Current time: 12-12-2017, 06:09 PM Hello There, Guest! (LoginRegister)

Post Reply 
 
Thread Rating:
  • 1 Vote(s) - 3 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help me to Analyse the Performance and get to the Root cause
05-09-2014, 09:09 AM (This post was last modified: 05-09-2014 01:08 PM by Anton Chigurh.)
Post: #11
RE: Help me to Analyse the Performance and get to the Root cause
(05-09-2014 08:38 AM)GreenGecko Wrote:  @Anton.

"Even a fool, when he holdeth his peace, is counted wise: and he that shutteth his lips is esteemed a man of understanding." Proverbs 17:28.

I hope that your continued bad advice and skewed logic isn't treated as truth by anyone out there. stick to the dayjob, and keep flipping that coin.
Let's not be silly with hyperbole. Show me one piece of BAD advice I am giving. Remember, BAD advice is your meter. Advice that if taken would do harm. Let's see it. I'm not knocking your suggestions, we're both just trying to help the best we can.



(05-09-2014 04:49 AM)a.chakery Wrote:  I noticed that your website is on a Windows server.

You know I am not really want to remove the whole question by my suggestion but if you really want to have an optimized website try to switch to Wordpress, hosted on an optimized Linux based server powered with LiteSpeed or NGiNX.

There are some great plugins for wordpress which will make it really easy for you to optimize your website as fast as possible.

Plus there is a great Theme Framework out there called Genesis which takes care of more than 50% of your page load time.

Good Luck.
Nice post, I really really hate a windows server.
Find all posts by this user
Quote this message in a reply
05-09-2014, 07:50 PM
Post: #12
RE: Help me to Analyse the Performance and get to the Root cause
(05-09-2014 04:49 AM)a.chakery Wrote:  I noticed that your website is on a Windows server.

You know I am not really want to remove the whole question by my suggestion but if you really want to have an optimized website try to switch to Wordpress, hosted on an optimized Linux based server powered with LiteSpeed or NGiNX.

There are some great plugins for wordpress which will make it really easy for you to optimize your website as fast as possible.

Plus there is a great Theme Framework out there called Genesis which takes care of more than 50% of your page load time.

Good Luck.

Hey Thanks a ton for your suggestion but the problem is that we cannot switch the server as of now. But please elaborate more on this that if I am moving from Windows to Linux then what all i need to do and all the changes and amount of work in details. This will help me to talk in the team and come to some conclusion.
Find all posts by this user
Quote this message in a reply
05-13-2014, 02:47 PM
Post: #13
RE: Help me to Analyse the Performance and get to the Root cause
(05-09-2014 09:09 AM)Anton Chigurh Wrote:  
(05-09-2014 08:38 AM)GreenGecko Wrote:  @Anton.

"Even a fool, when he holdeth his peace, is counted wise: and he that shutteth his lips is esteemed a man of understanding." Proverbs 17:28.

I hope that your continued bad advice and skewed logic isn't treated as truth by anyone out there. stick to the dayjob, and keep flipping that coin.
Let's not be silly with hyperbole. Show me one piece of BAD advice I am giving. Remember, BAD advice is your meter. Advice that if taken would do harm. Let's see it. I'm not knocking your suggestions, we're both just trying to help the best we can.

You:
- state that latency ( and location ) makes no difference
- state that CDNs make at best no difference, and at worst make things worse
- ignore the 9 second delay generating and delivering the html framework
- only concentrate on reducing payload even when savings are provably measurable in fractions of a second on a 17 second page load.

Those are the worst bits of advice you've given... all either outright lies or completely missing the point.

Your focus is only on content - static files - whereas in this case
a) the html framework generation ( so server sizing and tuning issues ) and
b) the delivery ( location and possibly available bandwidth )
are far more where the problem lies.
Find all posts by this user
Quote this message in a reply
05-14-2014, 02:48 AM (This post was last modified: 05-14-2014 03:09 AM by Anton Chigurh.)
Post: #14
RE: Help me to Analyse the Performance and get to the Root cause
(05-13-2014 02:47 PM)GreenGecko Wrote:  You:
- state that latency ( and location ) makes no difference
- state that CDNs make at best no difference, and at worst make things worse
- ignore the 9 second delay generating and delivering the html framework
- only concentrate on reducing payload even when savings are provably measurable in fractions of a second on a 17 second page load.

Those are the worst bits of advice you've given... all either outright lies or completely missing the point.

Your focus is only on content - static files - whereas in this case
a) the html framework generation ( so server sizing and tuning issues ) and
b) the delivery ( location and possibly available bandwidth )
are far more where the problem lies.
First of all, NONE of what you list above is ADVICE. It is merely disagreement on your part and apparently lack of even rudimentary reading comprehension.

I have given NO bad advice. I have advised for the OP to take care of the easy and basic tasks FIRST. NOT to ignore other suggestions. "Trim the fat site" is NOT bad advice.

Now, to your list of laments:

I proved here that your example of location making a difference was false, and you ignored the fact that your testing was inherently faulty - since the location nearer you was only loading half the KB of the same page, therefore totally skewing the results and making the example invalid. You seemed to just ignore that little detail. The reality is: LOCATION of the test browser really does NOT make all that much difference.
Quote:(You) state that CDNs make at best no difference, and at worst make things worse
That is completely a falsehood. My statement is that if your site is not optimized, a CDN can't do much for you (true) and if it IS optimized, you don't really need a CDN (also true.)
Quote:(You) ignore the 9 second delay generating and delivering the html framework
Nonsense. Part of the delay IS all the extra fat and baggage in the site itself. My suggestion is to first reduce the baggage and the fat, then see what happens to this delay. I have seen it improved vastly many times, in the dozens of sites i have optimized for people, or have helped them with, just by this simple and basic thing alone.
Quote:(You) only concentrate on reducing payload
Untrue - but I see how you might think that by either not reading well or not comprehending what you read. My suggestions about minimizing the KB footprint as much as possible are coming because that is the first, most basic thing everyone should do when trying to optimize their site. And one of the easiest things they can do.

We've shown the location of the test browser isn't relevant for this case, I've no idea why you continue to harp on it.

The OP has improved his site greatly by slimming it down, I've no idea why you can't see that. He took the one piece of advice I offered, and it helped.

You have your panties in a knot for no apparent reason, since I have not suggested or advised that the OP ignore your suggestions, advice and tips. And I have not attacked your positions or said you gave bad advice.

I am giving very good advice, which works every time it is tried. That you don't like the advice is exclusively your personal problem and if you don't like my posts you are invited to place me on ignore. Instead of helping the OP you're just a nattering nabob of negativism.
Find all posts by this user
Quote this message in a reply
05-14-2014, 01:39 PM
Post: #15
RE: Help me to Analyse the Performance and get to the Root cause
OK, I've been writing English natively now since I was about 5... so just on half a century. I've got the hang of it now.

I'll take just one of your statements:

"CDNs cannot improve performance of a site that isn't optimized, and if you do optimize it, you don't need a CDN."

Well, yes they can, and yes you do. By...

1. Delivering content from a local node. Less latency = faster delivery.
2. Delivering content from a fat pipe. Delivered at the available bandwidth of the client, not what percentage of the server's bandwidth is available for that particular client = faster delivery.
3. Reducing the load on the client's server frees up the server to deliver only the html framework of a dynamic page. Whilst the delivery of static content is not at all CPU intensive, it directly affects the available bandwidth to deliver it.

So yes, you do need a CDN to deliver graphically rich content. You've handed the job over to a supplier who specialises in it.
And yes, you do need a CDN to protect the available bandwidth on your server.

Maybe you're based in the USA, and don't see these things. It would explain your quoting Spiro Agnew at me. However, the OP - and myself - certainly aren't.

You are wrong. Maybe it's you who should learn to read. And learn a wee bit more about server tuning and content delivery to extend the scope and relevance of your advice.
Find all posts by this user
Quote this message in a reply
05-14-2014, 02:14 PM (This post was last modified: 05-14-2014 02:20 PM by Anton Chigurh.)
Post: #16
RE: Help me to Analyse the Performance and get to the Root cause
(05-14-2014 01:39 PM)GreenGecko Wrote:  
OK, I've been writing English natively now since I was about 5... so just on half a century. I've got the hang of it now.

I'll take just one of your statements:

"CDNs cannot improve performance of a site that isn't optimized, and if you do optimize it, you don't need a CDN."

Well, yes they can, and yes you do. By...

1. Delivering content from a local node. Less latency = faster delivery.
2. Delivering content from a fat pipe. Delivered at the available bandwidth of the client, not what percentage of the server's bandwidth is available for that particular client = faster delivery.
3. Reducing the load on the client's server frees up the server to deliver only the html framework of a dynamic page. Whilst the delivery of static content is not at all CPU intensive, it directly affects the available bandwidth to deliver it.

So yes, you do need a CDN to deliver graphically rich content. You've handed the job over to a supplier who specialises in it.
And yes, you do need a CDN to protect the available bandwidth on your server.

Maybe you're based in the USA, and don't see these things. It would explain your quoting Spiro Agnew at me. However, the OP - and myself - certainly aren't.

You are wrong. Maybe it's you who should learn to read. And learn a wee bit more about server tuning and content delivery to extend the scope and relevance of your advice.
You're quoting CloudFlare propaganda almost verbatim. And completely ignoring the fact that if a site is on a slow machine, the CDN does little to help speed. I've yet to see any CDN improve first byte time. That is because it cannot do that.

It is my opinion based on EXPERIENCE that you don't NEED a CDN. Notice the operative word, NEED.

You DO need to slim down a fat page, every time as a first step to fixing a slow website problem. Hopefully we can agree on that very simple, common sense basic.

I concentrate on the basic, simple things a typical site owner can do, first. At NO time have I told anyone not to take your advice as well. But cleaning up a fat site does much more than might meet the eye at first.

Good example: When a site owner complains to his shared hosting about his slow site, you well know the first thing they are going to do is find ways to blame HIM. But if the site is optimized, is svelte and is taking advantage of caching and compression, that's a BIG area of blame they try to use, gone. I've even seen on many occasions, hosts blaming use of a CDN for their slow machine!

I try to help people eliminate the simple stuff first. Works every time it is tried.

And the quote was William Safire, incidentally.
Find all posts by this user
Quote this message in a reply
05-14-2014, 03:58 PM
Post: #17
RE: Help me to Analyse the Performance and get to the Root cause
No, a CDN will not affect TTFB, but - once again - the locality and size of pipe will affect delivery performance. Some parts of the functionality of a basic CDN aren't propaganda, but physics... speed of light and all that.

By the way, lowering the size of static resources won't change the TTFB either: the client'll still be waiting just as long for the html to be generated, then getting it delivered (along with the same number of files in parallel - as soon as it knows what others to get).

[Image: if_eth0-day.png]

This is a graph of internet traffic: the slashdot effect... well mainly twitter in this case, but you know what I mean. Just think what that would be performing like if this server *wasn't* using a CDN. Registering nearly 200Mbit/s over a 5 minute average, and yet still delivering a hefty 3MB page (using over 200 files) to a (local!) client inside 5 seconds.

No I didn't write it, I just deliver it in a timely manner.

ngx_pagespeed is next for this site, but the resources will still be delivered via a CDN. It might slow the TTFB by the odd few MS ( and the extra admin involved is terrible with a non-technical client ), but the html will still be the same size. However, the 1.3MB/page saving to the client is where postprocessing their images is really worthwhile - 1 second off 5, rather than your 0.5 off 17 seconds.

And the improvements are above the fold, too.
Find all posts by this user
Quote this message in a reply
05-15-2014, 12:28 AM
Post: #18
RE: Help me to Analyse the Performance and get to the Root cause
As far as Windows vs Linux, they can both perform well. Scaling Nginx is a lot easier for ME but that's mostly because I don't have a lot of experience tuning an IIS install. It looks like the site has a lot of custom back-end application logic so I'd recommend just looking into instrumenting and improving that. New Relic has a Windows agent that can probably tell you what in the code is the slow parts. Wordpress is NOT a solution. Yes, they may have a theme that is lightweight but if you've hand-built an app then it makes no sense whatsoever.

We should probably fork the CDN discussion off to a separate thread but I'll weigh in with my 2c based on a lot of history running huge global sites as well as small regional ones.

If you are serving content to a fairly small region (within just the US, Just within Europe or even a single country) and your server is hosted fairly centrally to that region then a CDN isn't necessary and may actually hurt things. If you are serving traffic globally then a CDN is CRITICAL to performance.

When you start talking about India (or Australia) -> US you start getting round trip times on the order of 1/4 second. Every socket connect and request has to pay that round trip cost but the real killer is in TCP slow start. For each new connection you can only deliver 4-15KB (depending on server TCP config) before having to make another round trip and it doubles for each additional round trip. Delivering a useful amount of content ends up requiring a lot of those round trips and your get fetch times measured in seconds even for small resources.

CDNs can also provide a lot of other helpful services that aren't directly related to the perf of serving a single page but do seriously affect the scalability of the system. If you serve a lot of static content you can offload all of that bandwidth (and qps) onto a CDN which gives you a lot fewer servers to manage. They can also provide "evergreen" failovers to static pages in the case that your origins go down.

Yes, you are handing off some responsibility and adding a dependency but all of the major CDN's tend to have better uptime than individual hosting (or your upstream providers).

You shouldn't use them as a crutch because they can't solve the "10MB and 400requests" problem (though they will make it look better in something like keynote or gomez) but they are an absolutely critical part of a high performance global site.
Visit this user's website Find all posts by this user
Quote this message in a reply
05-15-2014, 02:47 AM (This post was last modified: 05-15-2014 03:00 AM by Anton Chigurh.)
Post: #19
RE: Help me to Analyse the Performance and get to the Root cause
(05-14-2014 03:58 PM)GreenGecko Wrote:  No, a CDN will not affect TTFB, but - once again - the locality and size of pipe will affect delivery performance.
We can tit for tat all day, but the main point you seem to still be missing is I am saying if your site is optimized, and it's a small site anyway, you don't NEED a CDN. NEED being the operative word.

And the size of the pipe really is irrelevant if the internet service of the visitor is small pipe, and especially if there is a TTFB problem needing addressed. If you know a CDN won't help TTFB, why recommend it then? Let's fix the fat site and the TTFB problem first, is my idea.

I do not deal in theoretical, ephemeral high brow concepts when it comes to helping someone with their slow site. I stick to the objective concrete, nuts and bolts, SIMPLE things the person can do himself - right away - to improve performance. I do not say stuff like, "I don't know, maybe it's this maybe it's that" like you had in your first reply to this thread. I go right to the meat of a situation with things I KNOW about, that help.

I could show you a dozen examples of sites I have optimized for people which had CDNs on them when the work started and were terrible performers, which now are excellent performers globally and don't use a CDN any longer. I am not speaking from theory, I am speaking from experience of actually optimizing many sites.

There's no reason for us to quibble and fight, we're both trying to help people, volunteering our time and asking for nothing in return. Hopefully you can respect that too.
(05-15-2014 12:28 AM)pmeenan Wrote:  If you are serving content to a fairly small region (within just the US, Just within Europe or even a single country) and your server is hosted fairly centrally to that region then a CDN isn't necessary and may actually hurt things. If you are serving traffic globally then a CDN is CRITICAL to performance.

When you start talking about India (or Australia) -> US you start getting round trip times on the order of 1/4 second. Every socket connect and request has to pay that round trip cost but the real killer is in TCP slow start. For each new connection you can only deliver 4-15KB (depending on server TCP config) before having to make another round trip and it doubles for each additional round trip. Delivering a useful amount of content ends up requiring a lot of those round trips and your get fetch times measured in seconds even for small resources.

CDNs can also provide a lot of other helpful services that aren't directly related to the perf of serving a single page but do seriously affect the scalability of the system. If you serve a lot of static content you can offload all of that bandwidth (and qps) onto a CDN which gives you a lot fewer servers to manage. They can also provide "evergreen" failovers to static pages in the case that your origins go down.

Yes, you are handing off some responsibility and adding a dependency but all of the major CDN's tend to have better uptime than individual hosting (or your upstream providers).

You shouldn't use them as a crutch because they can't solve the "10MB and 400requests" problem (though they will make it look better in something like keynote or gomez) but they are an absolutely critical part of a high performance global site.
Thanks for this clear and informative, objective assessment of the CDN situation Patrick. You went right to the heart of the matter for me - way too many people think a CDN is a "magic bullet" for every ill a site might have, recommend a CDN in knee-jerk fashion, and too many people take that advice thinking they fixed everything. People tend to gravitate towards the quick and easy solution when really they need to roll up their sleeves and go to work actually optimizing their site.




The OP wanted to know the root cause of his problems. I defined the root cause correctly, as a fat page. He slimmed the page down and improved the issues - he need only slim it down some more to see further improvement.
Find all posts by this user
Quote this message in a reply
05-15-2014, 04:46 PM
Post: #20
RE: Help me to Analyse the Performance and get to the Root cause
Hi All,

http://www.webpagetest.org/result/140515_57_7GD/ this is my newest report where I have compressed the images but still the load time is very high. I have also noticed that combine.js file is taking a lot of time. This is the same file where we have combines our all js files as per the recommendation. Let me know what to do now.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)