Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Massive Lag Before Page Load
rossharvey wrote #289029:
Unless it is related to the sheer number of images in the CMS. Then I’m screwed :¬)
Not necessarily. With a tiny bit of core hacking (adding a callback) and a small plugin which I’ve just written (untested yet), we could migrate all your images to sub-folders. Date-based schemes work best for keeping file numbers down:
/images/2014/0925/1.jpg
/images/2014/0925/2.jpg
/images/2014/0928/3.jpg
/images/2015/0604/1397896.jpg
...Since the image creation date never changes (ha! well, need to check that things stay the same at DST changes), it’s a simple process for the plugin to iterate over your images and move them to the new folders en-masse, and from then on, it’ll keep order on your behalf. Would need thoroughly testing first of course :-) And I’m not sure how well it would play with smd_thumbnail or other image manipulation plugins until they’re tweaked. In theory this little plugin falls back on the /images folder, but if you’ve already moved your images to subfolders, you don’t want another plugin trampling over that and using the base folder for its own stuff.
Anyway, that’s all detail. Bottom line: there’s a solution if it turns out to be the sheer number of files. The first step is ascertaining if that is actually the cause.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Massive Lag Before Page Load
Blimey, that was quick Stef, thank you! Sounds like a handy plugin regardless. I’ll be doing some (simple) testing by elimination soon, although it’ll be related to form content only. That’s as far as my TXP debugging ability extends :¬)
Offline
Re: Massive Lag Before Page Load
Bloke wrote #289030:
Not necessarily. With a tiny bit of core hacking (adding a callback) and a small plugin which I’ve just written (untested yet), we could migrate all your images to sub-folders. Date-based schemes work best for keeping file numbers down:
/images/2014/0925/1.jpg...Since the image creation date never changes (ha! well, need to check that things stay the same at DST changes), it’s a simple process for the plugin to iterate over your images and move them to the new folders en-masse, and from then on, it’ll keep order on your behalf. Would need thoroughly testing first of course :-) And I’m not sure how well it would play with smd_thumbnail or other image manipulation plugins until they’re tweaked. In theory this little plugin falls back on the
/imagesfolder, but if you’ve already moved your images to subfolders, you don’t want another plugin trampling over that and using the base folder for its own stuff.Anyway, that’s all detail. Bottom line: there’s a solution if it turns out to be the sheer number of files. The first step is ascertaining if that is actually the cause.
Would it be easy to test the sub folder theory by moving only one image? The image used in the Holly post that was mentioned in this thread, perhaps?
Offline
Re: Massive Lag Before Page Load
Once the lag thing is resolved, I’d recommend following some of the advice laid out here too.
In particular:
- Use progressive JPEGs in future if possible
- Use a CDN (such as CloudFlare, which is free)
Offline
Re: Massive Lag Before Page Load
rossharvey wrote #289032:
Would it be easy to test the sub folder theory by moving only one image?
Not really. I could do with a few images to test at first, then I’d like to let it rip on a few thousand files at once and see how it goes. I need to write that part of the plugin yet though…
Pete and I are setting up an installation with a few thousand files in it to see if we can replicate what you’re experiencing, then I’ll use that to test the plugin.
This might be one of those things whereby it’s not one thing in isolation. We just need to chase down the variables and eliminate them one by one until Bob’s your mother’s parrot or something.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Massive Lag Before Page Load
Bloke wrote #289036:
Not really. I could do with a few images to test at first, then I’d like to let it rip on a few thousand files at once and see how it goes. I need to write that part of the plugin yet though…
Pete and I are setting up an installation with a few thousand files in it to see if we can replicate what you’re experiencing, then I’ll use that to test the plugin.
This might be one of those things whereby it’s not one thing in isolation. We just need to chase down the variables and eliminate them one by one until Bob’s your mother’s parrot or something.
You guys are fast! Thank you, lost for words :¬)
Offline
Re: Massive Lag Before Page Load
rossharvey wrote #289037:
You guys are fast! Thank you, lost for words :¬)
No probs. Have you sent the login details to Pete yet?
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Massive Lag Before Page Load
Offline
Re: Massive Lag Before Page Load
If this is a filesystem issue due to the amount of files and assuming it’s EXT3 or higher, make sure you have dir_tree enabled:
tune2fs -O dir_index /dev/sdx1Where sdx1 is the partition involved.
Offline
Re: Massive Lag Before Page Load
ruud wrote #289040:
If this is a filesystem issue due to the amount of files and assuming it’s EXT3 or higher, make sure you have dir_tree enabled:
tune2fs -O dir_index /dev/sdx1...Where sdx1 is the partition involved.
Thanks! Not sure if I can do that on cloud hosting (Vidahost) though!
Offline
Re: Massive Lag Before Page Load
Sorted (pending final confirmation from Ross). Spam blocklist checking was snagging somewhere; site back to normal.
Last edited by gaekwad (2015-03-14 17:05:07)
Offline
Re: Massive Lag Before Page Load
gaekwad wrote #289061:
Sorted (pending final confirmation from Ross). Spam blocklist checking was snagging somewhere; site back to normal.
Thanks Pete!
(And everyone else who offered ideas! Really appreciate it.)
Last edited by rossharvey (2015-03-14 17:23:14)
Offline