This week has been a weird one in that I just don’t know where the time has gone despite working on things other than not doing quite as much plug-in coding as I’d probably have liked to have done due to some non-Winamp stuff that also needed to be done.
The main time as such has been spent on behind the scenes website stuff (hence getting https support), working on analytics and what the data on the site has been for the last few months and trying to do some seo related improvements (particularly for making any embedded links for the site work better on twitter and facebook).
On the coding front, i didn’t progress much on the muchfx and ‘playlist file remover’ (aka plfr) updates as I’d have hoped as the time that was available for plug-in coding was spent looking into adding a recovery mode to my nde library replacement as a means to take just a main.dat file and either re-build the required main.idx file or just have a means to extract the information so that a manual re-import of the information can be made.
This stemmed from a Winamp user having had data loss which led to the library database files being reset to their default values i.e. it all appeared to have been lost. Thankfully, there were still some intermediate dat files present in their settings folder which is what holds the actual database information. So hopefully by next weeks update I’ll have sorted out the remaining quirks I’ve got with the code so that it will be possible to regenerate a main.dat and main.idx pair of files as long as the main.dat file can be re-processed (as there are cases where that will just be completely messed up and data recovery is not possible).
I’ve also been having a look at how to in general speed up the blog as response times aren’t as good as they could be from what I’ve seen from the analytics / page speed testing. As a few seconds to get and render it probably is acceptable (apart from when it hangs for a few seconds on getting the first bytes) but considering there’s not much on the pages, it feels like something isn’t right and as something to tinker with when it comes to php,
it’s one of those practical things that I like to mess around with (and will hopefully be helpful down the road on a few web-based things for Winamp that I’d like to do) but it looks like from a quick bit of testing that flatpress doesn’t work fully with PHP7 (which is meant to be better for reducing the time to process php vs the current PHP 5.6 version being used - apart from when everything breaks, heh). So i’ll have to look into that a bit later on as I’m intrigued if it would make any noticeable difference or not from raw PHP 5.6 to 7 (along with improving the caching regime).
The only other notable thing is that I’ve moved the Winamp download mirror on winampplugins.co.uk to here.
So until next week (or sooner), happy Winamping!
-dro
Have you installed and enabled the opcache module for php? That’ll help alot, if you’re not already using it.
It appears that opcache is already enabled. I’m still reasonably new to php and also what this blog software is doing behind the scenes (which I intentionally picked for it being a flat-file setup so there isn’t a db dependency and it looked relatively easy to modify if needed), so it’s likely I’ve probably missed something or need to do a bit more work on things.
As it looks like the page cache the blog does is not a complete one and so there’s still a fair bit of building up of the page before its finally served up. Plus I’ve still to properly see the effect of hooking things up to use memcached for the final formed page (which isn’t something it seems to provide as a native option or via one of it’s plug-ins that I can find).
But then again I might just be looking for load time reductions that aren’t really needed.(3s first view and 1s repeat view is about the norm from webpagetest.org which I know is just a guide than a definitive but having a F on the first byte time makes me a sad panda ;o) ) or feasible with the setup I’m using (host and blog software) other than for the first time viewing the blog as the secondary view on tests is more than good enough it seems. It’s just seeing some values in the analytics data that showed a 15sec loading time which somewhat worried me.
I’d say memcached isn’t going to help you. It’s the sort of thing that helps when you have 1000s of views per second, but for a static site like this I doubt you’re getting that (forgive me!)
You’d be better off doing something like Wordpress does with it’s WP-Cache plugin, where it generates a static HTML page and serves that up (via .htaccess rules). Not sure how Flatpress works, but given it’s static text I’d assume it would be quite fast anyway?
I certainly don’t feel you’ve got any speed problems.
You’re probably right that it won’t help too much and yes trying to get a proper pre-created static page is what I’m also thinking will be better. Though like I mentioned, it doesn’t appear that it is making such a pre-generated file and is still re-making most of it (with that being built up from static elements) so it’s just getting things to a point that it will work with a static cache.
But like you note, it’s probably a bit on the pointless side if things are generally ok. Is mainly academic and a means to tinker on something that I’ve now got known metrics on just to see what may / may not work better (in preparation for some other aspects that will likely need such a behaviour to help keep server loads in-check).
Anyhoo, thanks Tim for the suggestions and putting up with my dumbness :o)