MySQL works poorly & more details
-
Since a few revisions have come out, I have taken the time to try to do more thorough testing on a dev version of my site to use 2.0.14, and tried to get more details than I have previously. While I updated from 1.9.13, I decided to stick with making new galleries to reduce any chance of incompatibility issues. I used the import feature since we upload our images via FTP. I imported two folders, the first with 59 images and the second with 41.
Pass 1 (59 images)
The entire time the progress bar (which doesn’t really show any progress) was in the browser, MySQL was running at a full CPU with the one query, which seemed to only have the image_slug value change anytime I looked at the processes. I did not time this as I should have, but the bar was up for quite a long time it felt. However, it appears that the thumbnails are generated during this, a nice change from pre-2.
I had TEST at the end of the folder I was using, however it seems like capital letters are not tolerated, since a folder was created with test in lowercase and all the images copied to this new folder, and the plugin referring to this new folder.
All of these files in this new folder (and thumbs sub-folder) were created with 600 file permissions, instead of 644. While I can see how this would be acceptable in some setups where the nobody/apache user is executing the script and therefore the owner of the files, many people such as myself have suPHP enabled making 644 required.
After chmod’ing the files to 644, the manage gallery page for this new gallery loaded nearly instantly. I created a page with the basic nggallery id tag and loaded it. MySQL acted as it was previously. Essentially a full CPU to run a query, with image_slug acting as previously mentioned. This query took ~5 minutes to fully process, and the page loaded within a second or two of its completion.
While my previous formatting for gallery pages of having columns line up and spread across the page is no longer in place, as much as I would like to see how I can use the newly available tags and resources, a 5 minute wait time to see the effects of each change I make is much too long for me to work with this.
Pass 2 (41 images)
I went through the settings before this pass, disabled the backup option, noticed a resize option there by default to 85% quality for 800×600. I’m not sure how I feel about that since it didn’t look like I could turn it off, and seems like a waste at least in my case, where we already process our images for the galleries before we upload them.
Processing the folder import took just over 4 minutes. I had my test in the folder name in lowercase to avoid a copy of this folder being created. However, the backup images were still made regardless. It doesn’t seem like the images were resized as the options menu implied. All files created by the plugin still had 600 permission which was changed to 644.
The manage gallery page again loaded instantly with the thumbnails as the other manage gallery page. As with the first test page, MySQL lagged in the same fashion and took slightly less than 4 minutes to process the query. The page loaded in less than a second following this.
At this point, in my view, issues have been lessened down to mostly MySQL. Unfortunately I’m not a programmer, so I can’t offer any sort of suggestions to improve this. If the queries were executed in a reasonable amount of time, I wouldn’t really be having any issues. Though the image backups being generated when I turned it off is also a concern. However, I can’t have this version on the live site yet, as this would eventually kill my server because of the resource consumption. I also have many galleries that have 400 – 500 images. It seems like progress has been made, however until MySQL issues have been sorted out, I can not roll this out.
- The topic ‘MySQL works poorly & more details’ is closed to new replies.
