IMPORTANT: Server Changeover

[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.

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.

That was for dynamic content, this is what the server is sending for static content, so it could do with the expires header, I will see about correcting this, thanks for pointing it out.

Code: [Select]

HTTP/1.1 200 OK
Date: Thu, 07 Mar 2013 08:03:24 GMT
Server: Apache
Last-Modified: Tue, 06 Sep 2011 12:20:54 GMT
ETag: "50043b-e0-4ac44dbe7d580"
Accept-Ranges: bytes
Content-Length: 224
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: image/gif

Edit: This has been fixed, all static content has an expiry of 1 day now.

[ve7xen]

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 .

I dunno that I'd call it a feature... but knowing the final size of the element lets the browser compose the final layout of the page and wait for the image to arrive, rather than waiting for the image header before knowing its size, and thus how the page will be laid out. I think browsers these days are pretty clever and will render as much of the page as they can as it comes in, but if those 1x1 gifs are above the fold on a main content div or something, they're going to stall the browser until they load.

[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 .

I dunno that I'd call it a feature... but knowing the final size of the element lets the browser compose the final layout of the page and wait for the image to arrive, rather than waiting for the image header before knowing its size, and thus how the page will be laid out. I think browsers these days are pretty clever and will render as much of the page as they can as it comes in, but if those 1x1 gifs are above the fold on a main content div or something, they're going to stall the browser until they load.

That's about right - personally I hate the darn things. There was a EC start up in the UK many moons ago that got engineered by a whole boat load of 'con'sultants on a crazed feeding frenzy, all working on their own modules and bits and pieces. I remember looking at the request chain for the home page, literally hundreds of bits of css, js and 1x1 gifs all over the place - like a black hole it literally collapsed under its own inefficient weight... My motto is keep it lean, keep it keen, always.

Plus if Dave ever gets his lovely mug on the telly - all this work will reap massive rewards as his site won't have such a tendency to do a 'click frenzy special'..

[EEVblog]

More graphs from MySQL
The server does seem to peak at using all 8 processors occasionally.
But server load averages are usually under 0.5

Dave.

[gnif]

More graphs from MySQL
The server does seem to peak at using all 8 processors occasionally.
But server load averages are usually under 0.5

Dave.

That is because I increased its limits so that it can use all 8, it might as well take advantage of your new hardware.

[EEVblog]

That is because I increased its limits so that it can use all 8, it might as well take advantage of your new hardware.

 

Dave.

[amspire]

Is the eevblog homepage meant to be offline? I have been getting an Apache Default Website page for the last few hours.

[Thor-Arne]

Is the eevblog homepage meant to be offline? I have been getting an Apache Default Website page for the last few hours.

I had  this problem to when using FireFox, IE worked fine tho.
Needed to clear all cache/history.

[amspire]

Is the eevblog homepage meant to be offline? I have been getting an Apache Default Website page for the last few hours.

I had  this problem to when using FireFox, IE worked fine tho.
Needed to clear all cache/history.

Thanks - that worked. Once the page gets redirected once to the default page cgi script, reloading the page in Firefox has absolutely no effect - it just reloads the cgi script again. It looks like clearing the firefox cache is the only way to get the home page back. Seems an odd way to implement a default page.

[Thor-Arne]

The problem is FireFox, for some reason it uses the cached version no matter what.
I guess there will be another FireFox update soon. 

[amspire]

The problem is FireFox, for some reason it uses the cached version no matter what.
I guess there will be another FireFox update soon. 

The problem is that the default cgi page is a permanent page (http://www.eevblog.com/cgi-sys/defaultwebpage.cgi) , and you cannot stop Firefox from redirecting first before a full refresh of the page - so it just refreshes the default cgi page. So once a redirect is in the cache, it seems you cannot prevent the redirecting in any way other then clearing the cache. It never tries to load from eevblog.com to see if the redirect is still present.

[gnif]

The problem is FireFox, for some reason it uses the cached version no matter what.
I guess there will be another FireFox update soon. 

The problem is that the default cgi page is a permanent page (http://www.eevblog.com/cgi-sys/defaultwebpage.cgi) , and you cannot stop Firefox from redirecting first before a full refresh of the page - so it just refreshes the default cgi page. So once a redirect is in the cache, it seems you cannot prevent the redirecting in any way other then clearing the cache. It never tries to load from eevblog.com to see if the redirect is still present.

Thanks for the URL, I will see if I can add a redirect in to fix the issue, firefox is a PITA with redirects like that.

[Thor-Arne]

The problem is FireFox, for some reason it uses the cached version no matter what.
I guess there will be another FireFox update soon. 

As I said, there was the update. 

[BravoV]

This thread "DIY Metcal 13.56 MHz RF Supply" at the last page 13 is acting up again -> https://www.eevblog.com/forum/projects/diy-metcal-13-56-mhz-rf-supply/180/

It displays blank screen as previous problem.

Edit : Looks like this thread got stickied at Projects, Designs, and Technical Stuff section with last post by EEVBlog, Dave broke it ! 

[baljemmett]

This thread "DIY Metcal 13.56 MHz RF Supply" at the last page 13 is acting up again [...]Looks like this thread got stickied at Projects, Designs, and Technical Stuff section with last post by EEVBlog, Dave broke it ! 

The last post in that thread is:

Title: Re: DIY Metcal 13.56 MHz RF Supply
Post by: EEVblog on March 08, 2013, 02:08:32 AM
PLEASE READ
There is something wrong with this thread in SMF, it is giving technical troubles. No idea why. 
Thread locked unless a fix can be found.

Dave.

... although I'm not sure how many people will have seen it!  The trick is to open one of the earlier pages in the thread and hit the Print option; the print-friendly version that appears will include all the posts, but alas no attachments.

[gnif]

The thread is fixed, it was caused by trying to upload an image that was way too big, SMF was not allocating enough ram to generate the thumbnail for it, and instead of failing gracefully... got a white screen.

I have increased the memory limit for larger files.

[BravoV]

Is there any restriction or setting at SMF to limit the picture resolution when people upload them ? Its quite annoying to watch pics dumped from camera without resizing it 1st, its just plain lazy. 

I think 1024 horizontal resolution should be enough.

[gnif]

I am not sure, Dave will have to have a look into it when he wakes up .

I have unlocked the thread.

[jancumps]

Old server showed posts one hour off here in cet timezone. New server 14 hours off.
The list of unread items seems shorter, ony a half page - used to be 2-3 pages.

Or maybe I need more sleep 

[gnif]

Old server showed posts one hour off here in cet timezone. New server 14 hours off.
The list of unread items seems shorter, ony a half page - used to be 2-3 pages.

Or maybe I need more sleep 

Check what your timezone is set to in your SMF profile. The server was in the incorrect time zone a few days back which Dave corrected, it could account for the difference.

[jancumps]

Just checked. I couldn't find a specific timezone setting, but my country is set to Belgium. I haven't touched my profile lately.

[justanothercanuck]

It's under account settings, look and layout, time offset. 

[jancumps]

That did it. It was set to autodetect. Behaviour seems to have cheged....
It's fixed now.

[Mr Smiley]

Hi,

I'm getting this today at 17:36 uk time, all other messages seem ok

500 Internal Server Error
https://www.eevblog.com/forum/microcontrollers/is-arduino-the-best/?topicseen

Mr Smiley 

[gnif]

Hi,

I'm getting this today at 17:36 uk time, all other messages seem ok

500 Internal Server Error
https://www.eevblog.com/forum/microcontrollers/is-arduino-the-best/?topicseen

Mr Smiley 

Sorry about that, it was me . We are expecting a load spike in the next 24 hours and as such I am preparing the server for it. Just clear your cache and try again.