Switched to Filesystem from DB for Picture Storage - 500 Error

4 years ago
I got a 500 error (effectively a request timeout) after switching from database storage to file system storage for pictures.  The site seems to be working, but images are broken.  Did it fail to write all of the images to the file system or is it a background thread that just needs to be left alone to finish.

I'm half wondering if I should restore a DB backup.
4 years ago
msumerano wrote:
I got a 500 error (effectively a request timeout) after switching from database storage to file system storage for pictures.  The site seems to be working, but images are broken.  Did it fail to write all of the images to the file system or is it a background thread that just needs to be left alone to finish.

I'm half wondering if I should restore a DB backup.


Note that this is nopCommerce 3.40.
4 years ago
Got a 500 error switching back to DB as well, but at least the images came back.  Is there another way?  DB-stored images is causing performance issues on Azure.
4 years ago
So, I did lose some images.  I had to go to a backup and update ones that were missing.  I can tell you that I have about 17K images stored in the database and whatever happened to have the site timeout and give a 500 error while it was switching from DB to file system for the image storage does not work well enough to support this many images.

For now, I must keep them in the DB, but really want to move them to the file system to help with Azure DB performance and potentially to be able to use a CDN instead.

If there are any options out there for addressing this (even if it's a matter of extracting the images to the file system myself and uploading them), it'd be greatly appreciated.
3 years ago
Using a combination of a tool that I wrote to export images and nullifying the picture in the Picture table, I was able to fully switch to a file-system based configuration for pictures.

https://github.com/sumo300/nop-tools

For approximately 17K images of all sizes with the database in Azure, it took a little over an hour to fully export.  It also took more than an hour to nullify the picture storage in the Picture table.  I could have just dropped the column and re-added it, but I wanted to see how long it would actually take to update the column to NULL.

The built-in feature really is not going to work if it takes longer than a request times out in.  I had to do this "offline."

I continue to tweak the tool to see if I can actually get it to run all in one step.  The update of the table from EF fails after about 30 minutes or so with a very cryptic error that is documented as being a problem with EF 6's inability to retry.  EF Core has better features for this and I'm tinkering with that.