Posts Tagged ‘cache’

Most Annoying Bug Ever: iOS/Safari Caches POST Responses, Decimates AJAX

Any AJAX developer will tell you that it’s just common sense to use POST over GET when submitting requests where the response should not be cached.

However – as I just learned today – that sense is not so common after all.

I’ve been trying to get a Cordova app which uses heavy AJAX to function on iOS on-and-off for the last couple of months. I could never understand why the iOS version wouldn’t work but any desktop browser (including Safari) and the Android version would. Plugging the desktop safari debugger into the iOS simulator showed that my polls were going through but – apparently – no data was being returned from the server in the response bodies.

The fact is, contrary to every other browser, mobile Safari (and therefore Cordova) caches POST responses by default. Those polls that looked like they were reaching my server were actually striking the cache. Talk about confusing.

Finding the problem was the hard part. Fortunately, fixing it is easy as pie. Simply add

Pragma: no-cache

to your response headers.

A Funny Thing Happened on the way to 100% Full tmpfs

I’ve been having trouble with XCache’s datastore lately and was prompted to revisit my SHM/tmpfs File-Based PHP Cache/Datastore in RAM strategy.

I mounted a 256MB tmpfs slice like this:

none                    /mnt/ram        tmpfs           defaults,noatime,size=256M      0 0

Somehow, after the storage was exhausted the number of files kept increasing.

$ watch "ls | wc -l"

To my surprise new, empty files were being created with a random string attached to their name.


Interestingly, while these non-files continued to accumulate the reported amount of storage used by tmpfs never changed. One might expect these file entries to be taking up some amount of space, somewhere.

I’ve done as much research as time will permit but haven’t found the purpose of this behaviour. Since the altered file name and lack of content makes these files void as far as my fcache implementation is concerned it highlights the importance of thorough garbage collection.

mpm_worker and Thread-Safe PHP are Toxic to APC

Technically the reverse is true but with all the problems folks seem to be having with the threaded Apache MPM mpm_worker and the supposedly “thread safe” versions of PHP one wonders – though it is said PHP itself is thread safe but many of its add-ons (apparently APC among them) are not. I can testify to that because I’ve been running a high volume site with threads for a few months with no issues except the big one: APC works for about 5 minutes then apache starts churning out blank pages. PHP appears to segfault but who knows what’s really going on when absolutely nothing shows up in any logs.

Supposedly mpm_worker offers great memory savings but I’ve failed to see it nor the benefits it brings and I’ve also failed to see any real difference in performance – though you could chalk that up to my having lost the bytecode cache. I’ve been back on mpm_prefork for a few hours now and haven’t noticed any significant change in load, though I’ll know by tomorrow if (apparently now stable) APC is doing anything for me.

So far it’s looking like threaded apache at this stage only really has a place on ram-constrained VPSes but as far as stability and interoperability is concerned if you got it, use it baby.

UPDATE Looks like load is actually about half what it used to be at peak hours. Threading is definitely not worth losing APC, at least for me.

Return top
Online Marketing Toplist
Technology Blogs - Blog Rankings

Internet Blogs - BlogCatalog Blog Directory

Bad Karma Networks

Please Donate!

Made in Canada  •  There's a fox in the Gibson!  •  2010-12