Comments on: A Bad Tip For Speeding Up Your Site http://dan-cole.com/a-bad-tip-for-speeding-up-your-site/ An Electrical Engineer And Web Developer Thu, 17 Jun 2010 23:16:41 +0000 hourly 1 By: Alex Denning http://dan-cole.com/a-bad-tip-for-speeding-up-your-site/#comment-9 Alex Denning Thu, 04 Jun 2009 20:01:12 +0000 http://dan-cole.com/?p=38#comment-9 Hey Dan Thanks for testing that out - interesting to see what actual difference it makes. But, I'll stand by what I said on PBD; the difference may be negligible or nothing, but hey, at least it's good practice! Hey Dan

Thanks for testing that out – interesting to see what actual difference it makes. But, I’ll stand by what I said on PBD; the difference may be negligible or nothing, but hey, at least it’s good practice!

]]> By: Sean http://dan-cole.com/a-bad-tip-for-speeding-up-your-site/#comment-8 Sean Thu, 04 Jun 2009 04:11:51 +0000 http://dan-cole.com/?p=38#comment-8 Thanks Dan, I'm not sure I agree with the testing method, but the conclusions and your comments about page caching are on the mark. There's a lot of misinformation out there about website scalability and speed, glad to see some people take it seriously. Sean Thanks Dan,

I’m not sure I agree with the testing method, but the conclusions and your comments about page caching are on the mark.

There’s a lot of misinformation out there about website scalability and speed, glad to see some people take it seriously.

Sean

]]> By: admin http://dan-cole.com/a-bad-tip-for-speeding-up-your-site/#comment-7 admin Thu, 04 Jun 2009 03:46:51 +0000 http://dan-cole.com/?p=38#comment-7 @Sean, I used the PHP microtime function to time how long that single line of code took to process. So it wasn't the total time to process the page or to serve the page, but to process a single line of code. @Sean,
I used the PHP microtime function to time how long that single line of code took to process. So it wasn’t the total time to process the page or to serve the page, but to process a single line of code.

]]> By: admin http://dan-cole.com/a-bad-tip-for-speeding-up-your-site/#comment-6 admin Thu, 04 Jun 2009 03:35:55 +0000 http://dan-cole.com/?p=38#comment-6 @Stephen, If their not using caching, then that's what they should try and get, rather that changing their theme. Of course a lot of these methods depend on the options available. As far as the PHP commands accessing the database each time, that's not entirely correct. WordPress has its own cache built into the get_options function, meaning only one database request is made for each visitor, which is done by the wp_cache_get function. This don't exclude the process time, but I think this single tip does little to nothing when compared to the other tips in terms of performance. @Stephen,
If their not using caching, then that’s what they should try and get, rather that changing their theme. Of course a lot of these methods depend on the options available.

As far as the PHP commands accessing the database each time, that’s not entirely correct. WordPress has its own cache built into the get_options function, meaning only one database request is made for each visitor, which is done by the wp_cache_get function. This don’t exclude the process time, but I think this single tip does little to nothing when compared to the other tips in terms of performance.

]]> By: Sean http://dan-cole.com/a-bad-tip-for-speeding-up-your-site/#comment-5 Sean Thu, 04 Jun 2009 03:17:10 +0000 http://dan-cole.com/?p=38#comment-5 Hi Dan, I understand what you're driving at ("the original article isn't correct, you shouldn't be concerned with trivial details like that") which I agree with, but I don't understand what it is you tested, or what your environment was. One thing stands out that makes me wonder what it is you measured -- that you had a service time of 1/10000 second. This means whichever method that was, it can sustain 10K requests/second. 200 times that is then 2 million req/sec. If that's complete page loads then that's just insane performance. Can you lend some insight into your testing methods? Thanks, Sean Hi Dan,

I understand what you’re driving at (“the original article isn’t correct, you shouldn’t be concerned with trivial details like that”) which I agree with, but I don’t understand what it is you tested, or what your environment was.

One thing stands out that makes me wonder what it is you measured — that you had a service time of 1/10000 second. This means whichever method that was, it can sustain 10K requests/second. 200 times that is then 2 million req/sec. If that’s complete page loads then that’s just insane performance.

Can you lend some insight into your testing methods?

Thanks,

Sean

]]> By: Stephen Cronin http://dan-cole.com/a-bad-tip-for-speeding-up-your-site/#comment-4 Stephen Cronin Thu, 04 Jun 2009 02:34:43 +0000 http://dan-cole.com/?p=38#comment-4 Hi Dan, You're absolutely spot on with the caching angle, that makes it a non-argument. However, if you're not using caching, then I'd try to limit the amount of PHP commands used. For one visitor, there won't be any discernible difference, but if you get a lot of traffic and you're on shared hosting, then every little bit counts. Don't forget that most of the 'PHP commands' that Pro Blog Design are talking about actually make database calls. It's one thing if you're using PHP to echo text, but another thing if you're accessing the DB each time. My two cents anyway... Hi Dan,

You’re absolutely spot on with the caching angle, that makes it a non-argument.

However, if you’re not using caching, then I’d try to limit the amount of PHP commands used. For one visitor, there won’t be any discernible difference, but if you get a lot of traffic and you’re on shared hosting, then every little bit counts.

Don’t forget that most of the ‘PHP commands’ that Pro Blog Design are talking about actually make database calls. It’s one thing if you’re using PHP to echo text, but another thing if you’re accessing the DB each time.

My two cents anyway…

]]>