IMPORTANT: Server Changeover

[EEVblog]

Here is a capture of the live database connection just now.

Dave.

[amspire]

Just had an "Internal Server Error" for about 5 minutes when accessing the forum. It is running again now.

[EEVblog]

Just had an "Internal Server Error" for about 5 minutes when accessing the forum. It is running again now.

Yep, gnif just updated mySQL, fully expected.

Dave.

[EEVblog]

It seems that "persistent connection" and "email on database connection errors" SMF options were both disabled. Not sure why they would have been turned off.
Back on now.

With regards to forum caching, SMF says this:

SMF supports caching through the use of accelerators. The currently supported accelerators include:
APC
eAccelerator
Turck MMCache
Memcached
Zend Platform/Performance Suite (Not Zend Optimizer)
XCache
Caching will work best if you have PHP compiled with one of the above optimizers, or have memcache available. If you do not have any optimizer installed SMF will do file based caching.

SMF performs caching at a variety of levels. The higher the level of caching enabled the more CPU time will be spent retrieving cached information. If caching is available on your machine it is recommended that you try caching at level 1 first.

Note that if you use memcached you need to provide the server details in the setting below. This should be entered as a comma separated list as shown in the example below:
"server1,server2,server3:port,server4"

Note that if no port is specified SMF will use port 11211. SMF will attempt to perform rough/random load balancing across the servers.

SMF has detected that your server has APC installed.

So SMF may possibly be using APC caching at the moment, on "Level 1". There is "Level 2", and "Level 3 (not recommended)" options.
Before the server move, there was no caching detected, so it used file based caching.

Dave.

[gnif]

Dont see what is so funny, it has allowed/forced many many users to become familiar with Linux in the hosting environment which has pushed them to give it a go in other environments. Bugs get fixed, usability problems are found, etc, simply because more people are using it. I am not saying that it was 'cPamel' that made linux, I am saying that commercial products like cPanel help push more users towards Linux because they either want to cut costs, or they have no choice.

But that's not what you said, you said 'if it was not for platforms like cPanel the Linux community would suffer due to lack of users.', which means there wouldn't be enough users without it, which is hilarious. Linux has been the de-facto standard for shared hosting (and anyone sane doing serious deployments of anything else) long before cPanel was even a glimmer of an idea in some noob PHP3 programmer's brain. cPanel exists because of Linux's popularity in the server space, not vice versa, and without it the Linux community would be just as strong. Maybe we'd have more admins that actually know what they're doing.

Ok, sorry, it was a brainfart on my side, I did not intend it to come across that way.

It seems that "persistent connection" and "email on database connection errors" SMF options were both disabled. Not sure why they would have been turned off.
Back on now.

Persistent connections should not be needed any more, but wont hurt to leave them there. As for the caching, we are using APC now and I am currently getting memcached configured which will also improve things .

[gnif]

Ok, everything seems to be operational again, including some odd issues reported by some users. If anyone experiances any issues as of now, please update this thread to let Dave and myself know.

[vk6hdx]

The Wordpress blog on the main site seems to have done the time warp and is showing Posts from August last year at the top of the page.

[gnif]

Looks like a timezone problem, give me a few mins

Edit: It orders fine for me, can you please post the URL you are using?

[EEVblog]

The Wordpress blog on the main site seems to have done the time warp and is showing Posts from August last year at the top of the page.

I was afraid of that.
It's an issue with WP Super Cache.
I re-enabled it thinking it would magically work on the new server. Apparently not.
I'll turn it off again.

Dave.

[gnif]

Dave, the server is still set for an American time zone, should this be changed to Sydney Australia? This may be the reason for the super cache doing this.

[vk6hdx]

Yep all good now gnif seeing the up to date posts now.  I was just visiting http://eevblog.com screenshot attached.

P.s. the forum seems lightning fast now.. 

[manicdoc]

Dont see what is so funny, it has allowed/forced many many users to become familiar with Linux in the hosting environment which has pushed them to give it a go in other environments. Bugs get fixed, usability problems are found, etc, simply because more people are using it. I am not saying that it was 'cPamel' that made linux, I am saying that commercial products like cPanel help push more users towards Linux because they either want to cut costs, or they have no choice.

But that's not what you said, you said 'if it was not for platforms like cPanel the Linux community would suffer due to lack of users.', which means there wouldn't be enough users without it, which is hilarious. Linux has been the de-facto standard for shared hosting (and anyone sane doing serious deployments of anything else) long before cPanel was even a glimmer of an idea in some noob PHP3 programmer's brain. cPanel exists because of Linux's popularity in the server space, not vice versa, and without it the Linux community would be just as strong. Maybe we'd have more admins that actually know what they're doing.

Ok, sorry, it was a brainfart on my side, I did not intend it to come across that way.

It seems that "persistent connection" and "email on database connection errors" SMF options were both disabled. Not sure why they would have been turned off.
Back on now.

Persistent connections should not be needed any more, but wont hurt to leave them there. As for the caching, we are using APC now and I am currently getting memcached configured which will also improve things .

      

Good going - All that will be left to put on will be the speed stripes...

[BravoV]

P.s. the forum seems lightning fast now.. 

Agree, its blazing fast here, props to gnif ! 

Now its time to do QC of his work by hammering the forum ...  ..j/k

[gnif]

Thanks guys, Id love to see how fast it is when you are local(ish) to the server, I can see that the request->response time is exceptional, just our AU lag hides how quick the site is a little.

[EEVblog]

Dave, the server is still set for an American time zone, should this be changed to Sydney Australia? This may be the reason for the super cache doing this.

I set the timezone to Sydney this morning.
No, nothing to do with the Supercache bug IFAIK.
Supercache used to work for me for several years, then it started doing this crazy stuff going back several weeks or months.
IIRC it can be temporarily fixed by clearing the cache, but then it just comes right back again.

Dave.

[gnif]

Dave, the server is still set for an American time zone, should this be changed to Sydney Australia? This may be the reason for the super cache doing this.

I set the timezone to Sydney this morning.
No, nothing to do with the Supercache bug IFAIK.
Supercache used to work for me for several years, then it started doing this crazy stuff going back several weeks or months.
IIRC it can be temporarily fixed by clearing the cache, but then it just comes right back again.

Dave.

Very odd, although I will admit that I have barely used it, I am more into the server side of things then the actual hosted content .

[vk6hdx]

Supercache used to work for me for several years, then it started doing this crazy stuff going back several weeks or months.
IIRC it can be temporarily fixed by clearing the cache, but then it just comes right back again.

Have you tried the HyperCache WP Plugin?  It seems to get a pretty good write up here.

[EEVblog]

Have you tried the HyperCache WP Plugin?  It seems to get a pretty good write up here.

Ah, the bug seems to be in garbage collection somehow.
Might give Hypercache a try.

Dave.

[manicdoc]

Thanks guys, Id love to see how fast it is when you are local(ish) to the server, I can see that the request->response time is exceptional, just our AU lag hides how quick the site is a little.

BTW the local jquery is still on the local homepage, also a lot 1x1 monitoring gif's hanging off the page - just double check the markup has width='1' height='1' in it or the page rendering will hang waiting for those to come through (looks like they are down a long pipe).  also seeing 304 Not Modified responses coming through, so looks like on firefox at least its still pinging the box to see if the file has changed - seems to be doing it with each new forum page one loads (ETag's?) - so if you walk the forum with firebug on you keep seeing the 304 coming in.

[gnif]

BTW the local jquery is still on the local homepage, also a lot 1x1 monitoring gif's hanging off the page - just double check the markup has width='1' height='1' in it

Is that a browser feature? If so I was unaware of this, good to know . As for checking for modified versions of the dynamic pages, this is required so you see if people have modified a post, etc. Not sure how E-Tags would help in this instance, care to elaborate?

The client may then decide to cache the resource, along with its ETag. Later, if the client wants to retrieve the same URL again, it will send its previously saved copy of the ETag along with the request in a "If-None-Match" field.

On this subsequent request, the server may now compare the client's ETag with the ETag for the current version of the resource. If the ETag values match, meaning that the resource has not changed, then the server may send back a very short response with an HTTP 304 Not Modified status. The 304 status tells the client that its cached version is still good and that it should use that.

So this will still cause a 304 response, which you are already getting.

[EEVblog]

Some database stats:
ø per hour: 135,833
ø per minute: 2,264
ø per second: 38

Network traffic since startup: 5 GiB

This MySQL server has been running for 0 days, 7 hours, 18 minutes and 30 seconds. It started up on Mar 06, 2013 at 05:06 PM.

Traffic                    ø per hour
Received   400 MiB   54.7 MiB
Sent   4.6 GiB           650.4 MiB
Total   5 GiB           705.2 MiB

Connections                           ø per hour   %
max. concurrent connections   24   ---   ---
Failed attempts   35           4.79             0.12%
Aborted                   7           0.96             0.02%
Total                           29 k           3,978.47   100.00%

Those error rates are pretty low compared to the previous server.

Aborted clients           7    The number of connections that were aborted because the client died without closing the connection properly.
Aborted connects   35    The number of failed attempts to connect to the MySQL server.

Dave.

[gnif]

Aborted clients           7    The number of connections that were aborted because the client died without closing the connection properly.
Aborted connects   35    The number of failed attempts to connect to the MySQL server.

These occur even when everything is working 100%, they can be caused by clients that started pulling a page and hit the stop button before it was finished, or someone was performing some testing directly on the database on the server (ie, it was possibly me )

[manicdoc]

BTW the local jquery is still on the local homepage, also a lot 1x1 monitoring gif's hanging off the page - just double check the markup has width='1' height='1' in it

Is that a browser feature? If so I was unaware of this, good to know . As for checking for modified versions of the dynamic pages, this is required so you see if people have modified a post, etc. Not sure how E-Tags would help in this instance, care to elaborate?

The client may then decide to cache the resource, along with its ETag. Later, if the client wants to retrieve the same URL again, it will send its previously saved copy of the ETag along with the request in a "If-None-Match" field.

On this subsequent request, the server may now compare the client's ETag with the ETag for the current version of the resource. If the ETag values match, meaning that the resource has not changed, then the server may send back a very short response with an HTTP 304 Not Modified status. The 304 status tells the client that its cached version is still good and that it should use that.

So this will still cause a 304 response, which you are already getting.

I usually run with E-Tag's turned off - on the principal that if you have set it to cache on the browser, then the browser on its own can work out if its gone stale or not. If you want to send out a new version of a library or asset, change the URL - hence why all the libraries/css/etc come with their version baked into the URL... This saves the essentially zero useful info request and the server resources that go with it. I think Etags originally came from windows world if memory serves... Check out my old employers home page (au.yahoo.com) - no Etags anywhere.

FireBug is a plug-in - bees knees for this sort of optimisation.

[gnif]

BTW the local jquery is still on the local homepage, also a lot 1x1 monitoring gif's hanging off the page - just double check the markup has width='1' height='1' in it

Is that a browser feature? If so I was unaware of this, good to know . As for checking for modified versions of the dynamic pages, this is required so you see if people have modified a post, etc. Not sure how E-Tags would help in this instance, care to elaborate?

The client may then decide to cache the resource, along with its ETag. Later, if the client wants to retrieve the same URL again, it will send its previously saved copy of the ETag along with the request in a "If-None-Match" field.

On this subsequent request, the server may now compare the client's ETag with the ETag for the current version of the resource. If the ETag values match, meaning that the resource has not changed, then the server may send back a very short response with an HTTP 304 Not Modified status. The 304 status tells the client that its cached version is still good and that it should use that.

So this will still cause a 304 response, which you are already getting.

I usually run with E-Tag's turned off - on the principal that if you have set it to cache on the browser, then the browser on its own can work out if its gone stale or not. If you want to send out a new version of a library or asset, change the URL - hence why all the libraries/css/etc come with their version baked into the URL... This saves the essentially zero useful info request and the server resources that go with it. I think Etags originally came from windows world if memory serves... Check out my old employers home page (au.yahoo.com) - no Etags anywhere.

FireBug is a plug-in - bees knees for this sort of optimisation.

Well here are the headers the server is sending back:

Code: [Select]

HTTP/1.1 200 OK
Date: Thu, 07 Mar 2013 07:55:11 GMT
Server: Apache
X-Powered-By: PHP/5.4.12
Pragma: no-cache
Cache-Control: private
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Vary: Accept-Encoding
Set-Cookie: PHPSESSID=*REMOVED*; path=/
Last-Modified: Thu, 07 Mar 2013 07:55:11 GMT
Connection: close
Content-Type: text/html; charset=UTF-8

So no ETags, just a expire date in the past, which is what I would expect for dynamic content from the forum. It is showing the PHP version though, forgot to turn that off since the migration to 64bit.

[manicdoc]

BTW the local jquery is still on the local homepage, also a lot 1x1 monitoring gif's hanging off the page - just double check the markup has width='1' height='1' in it

Is that a browser feature? If so I was unaware of this, good to know . As for checking for modified versions of the dynamic pages, this is required so you see if people have modified a post, etc. Not sure how E-Tags would help in this instance, care to elaborate?

The client may then decide to cache the resource, along with its ETag. Later, if the client wants to retrieve the same URL again, it will send its previously saved copy of the ETag along with the request in a "If-None-Match" field.

On this subsequent request, the server may now compare the client's ETag with the ETag for the current version of the resource. If the ETag values match, meaning that the resource has not changed, then the server may send back a very short response with an HTTP 304 Not Modified status. The 304 status tells the client that its cached version is still good and that it should use that.

So this will still cause a 304 response, which you are already getting.

I usually run with E-Tag's turned off - on the principal that if you have set it to cache on the browser, then the browser on its own can work out if its gone stale or not. If you want to send out a new version of a library or asset, change the URL - hence why all the libraries/css/etc come with their version baked into the URL... This saves the essentially zero useful info request and the server resources that go with it. I think Etags originally came from windows world if memory serves... Check out my old employers home page (au.yahoo.com) - no Etags anywhere.

FireBug is a plug-in - bees knees for this sort of optimisation.

Well here are the headers the server is sending back:

Code: [Select]

HTTP/1.1 200 OK
Date: Thu, 07 Mar 2013 07:55:11 GMT
Server: Apache
X-Powered-By: PHP/5.4.12
Pragma: no-cache
Cache-Control: private
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Vary: Accept-Encoding
Set-Cookie: PHPSESSID=*REMOVED*; path=/
Last-Modified: Thu, 07 Mar 2013 07:55:11 GMT
Connection: close
Content-Type: text/html; charset=UTF-8

So no ETags, just a expire date in the past, which is what I would expect for dynamic content from the forum. It is showing the PHP version though, forgot to turn that off since the migration to 64bit.

hmm for the static files _only_ you want it like:

Cache-Control   max-age=86400
Connection   Keep-Alive
Date   Thu, 07 Mar 2013 07:58:58 GMT
Expires   Fri, 08 Mar 2013 07:58:58 GMT
Keep-Alive   timeout=10, max=98
Server   Apache
Vary   Accept-Encoding

that also plays nice with upstream caches. Only a browser refresh will force a fetch.