Updating to new backlight

Backlight 4, 5 & 6 Support
#21

@Ben

When I open circuitpics.nl (wordpress) the site is fast.
It is only when opening the webshop @ circuitpics.nl/webshop

I still think this is something within the webshop.

Should it be a test that I setup the webshop on a different subdomain to check if a new installation is fast?
I am comming from a lot of updates even before backlight was introduced. Maybe something broke in the code?

#22

Hi @Phoentje, I doubt itā€™s anything in our code. Backlight runs fast elsewhere and there arenā€™t any recent changes in the code that would impact performance like this.

Iā€™ve run some tests, and it appears that your site loads slowly if more than ten minutes has passed since the previous access. The webshop takes about 17 seconds to load when it hasnā€™t been accessed for over ten minutes, but around 3 seconds to load if it has been accessed less than ten minutes before. I suspect then a service on your server is going to sleep after ten minutes of inactivity.

I suggest raising this with your host.

FYI:
First page load: 17 seconds
Immediately reloading the page: 3 seconds
Reload after 590 seconds: 3 seconds
Reload after 610 seconds: 17 seconds
Reload after 590 seconds: 3 seconds

I came to the ten minute mark after running other tests prior to the tests above.

#23

Hi this is the answer I getā€¦ not really something I can do now can I? :frowning:

Iā€™ve taken a closer look at the behaviour you described, and what youā€™re seeing is not a ā€œsleep modeā€ on the server, but typical ā€œfirst uncached requestā€ behaviour on a WordPress webshop.

ā€¢ After around 10 minutes of no visits, the first visitor triggers all PHP/WordPress/WooCommerce code and database queries again, so the page takes much longer to generate (in your case, about 17 seconds)
ā€¢ The requests that follow shortly after are served from cache and from already-initialized PHP processes, so they drop to about 3 seconds again. When the cache expires or the PHP workers go idle after some time (which matches the 10-minute pattern you noticed), the next ā€œfirstā€ hit is slow again

On shared hosting this is very common, and the way to hide it from your visitors is to put proper page caching and a CDN in front of WordPress. That way, almost everyone gets the fast, cached version instead of forcing the site to warm up each time.

For circuitpics.nl, please do the following:

  1. In your WordPress admin, make sure the free one.com parent plugin is installed and activated.
  2. Inside it, install/enable the Performance Cache plugin.
  3. In Performance Cache, turn on caching and CDN for the site.
  4. If you already use another page-cache plugin, disable it so only one page-cache solution is active.
#24

That depends. Is your web shop using Wordpress and if so is that something expected or required?

#25

Nope just using g backlight only. ā€¦
Can I test a fresh install and export my settings ?

#26

Is there any Wordpress used on your site at all, such as at the top level?
Itā€™s possible that your host has modified one of the .htaccess files to call Wordpress before Backlight runs.

Can you take a look at those files under https://www.circuitpics.nl/, https://www.circuitpics.nl/webshop/ or https://www.circuitpics.nl/webshop/backlight/ to see if thereā€™s anything that looks related to Wordpress, or anything outside of Backlight?

A fresh install in another directory would be fine, e.g. at https://www.circuitpics.nl/backlight-test/

#27

Okay this is funny and scary.
I have not yet changed anything but checked htaccess for some unusual stuff. Nothing to be found, yes circuitpics.nl is running wordpressā€¦

After several contact moments with the hosting it now is very fast? ā€¦

#28

Nevermind haha still slow. Can I export the configuration from the old to a new instance aswell?

#29

@Ben
I have installed a new instance on Home - Your Company

This acts fast! So any suggestions? Can I export the old to the new to test if then it still runs fast?

#30

thereā€™s no ā€œexportā€ function.
What you can try is copying the backlight/ folder, and the galleries/ folder to the new location.
You could move the folders using your FTP program but it would be safer downloading to your computer and then uploading to the new location.

After the files are moved/copied, log into Backlight in the new location and change the Site and Company URL to the new location.

I think this will work. Hopefully all your albums will be visible

If you were using Lightroom to upload albums and want to test that functionality, then be sure to change the API URL in Lightroom Publisher Settings for that instance of Publisher.

If you added inline images to text, you may need to edit the copy of those pages to update the URLs to those images.

#31

I can try that, but regarding this test itā€™s pretty obvious something broke in the webshop instead of being a server problem?

#32

I donā€™t know

#33

Nothing is obvious from the outside. Based on your hostā€™s response it looks like webshop is somehow processing Wordpress.

All of the settings are in the backlight/data directory. This and whatever gallery directories you have should bring you to the same setup.

#34

@Phoentje, I could help look into the cause of the slowdown if you like by looking at the Backlight code and seeing if there are any slow points, or seeing if the slowdown happens before Backlight executes. Iā€™d need FTP access to do that, so if youā€™d like me to take a look please provide me with FTP details by email or direct message here (by clicking on my profile name followed by Message).

#35

Hi @Phoentje, thanks for the access. After a bit of digging Iā€™ve found that the slow point is caused by trying to find random thumbnails for your cover images. When viewing the home page, three of the five album sets shown are set to have random thumbnails for their cover images. These thumbnails come from anywhere within the child albums and sets. That means theyā€™re drawn from a database query of tens of thousands of photos.

I temporarily set the thumbnails to the these albums to the first photo in the cover image list, and the page started loading quickly. Iā€™ve since changed the setting back to Random. Can you try setting Cover Images for all of those albums? They are the ones seen at https://www.circuitpics.nl/webshop/

This issue would also affect pages within those album sets if they also have Random cover images, such as https://www.circuitpics.nl/webshop/galleries/overzicht-2025/. The performance issue will decrease as you drill down further.

I canā€™t immediately see how I can optimise the query for random thumbnails. It has to do a lot to make sure only thumbnails for visible albums for unprotected photos are returned.

The other issue is that the site loads much more slowly after ten minutes of inactivity. This looks to be a factor in speed - all site operations are taking longer. Fixing the issue with slow cover images remediates this somewhat. This extra slowness may be related to the SQLite database being slow on first query. Or it could be explained the other way - running at the faster speed is because the SQLite database has warmed up or cached its data effectively.

Your hostā€™s feedback on Wordpress etc. looks to be a red herring.

#36

Hiya @Ben thanks for looking in.
I have removed my older albums and the only albumset left now is 2025.
I have drilled down every album within and set a fixed image instead of random.

Can you run the script again to see if this already gives a better result?

So next thing after that is that I have to open a query to look into the SQL database engine on the host?
But as far as I know is that for backlight there is no separate sql instance running am I correcT?

#37

Hi @Phoentje, Iā€™m not seeing any performance issues any more. Your main site loads in between 1-2 seconds from the command line. My browser has it at around half a second.

SQLite may be taking longer after a delay, but thatā€™s a multiple of a very short duration. The issue previously was a combination of very slow queries for cover images and slow performance after ten or so minutes since the previous access. Throwing some examples where an uncached query takes five times longer than a cached query:

Slow query: 2 seconds
Slow running of SQLite after ten minutes of inactivity: 10 seconds

Fast query (now that youā€™ve set cover images): 20ms
Slow running of SQLite after ten minutes of inactivity: 100ms (which is negligible for site loading)

This is a simplistic illustration.

SQLite runs as a PHP module. The databases reside in files weā€™ve named master.sq3, e.g. baclight/data/admin/master.sq3. This is unlike other databases such as MySQL that run as their own server and store their database across multiple files. SQLite is robust and efficient, and requires no configuration. This makes Backlight much easier to configure and eases our support. MySQL would probably be faster, but the trade-offs of configuration and support donā€™t make it worth it for Backlight.

SQLite is often used in desktop and phone applications. A good example is Lightroom catalogues. These are actually SQLite databases.

#38

Great! So random images is an option but in this case I had many many albums wich made the database go mad no?

So for now I will just move into fixed images from now!