mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-05-04 18:08:46 +03:00
Bookstack Sort leading to PHP TimeOut leading to Database Corruption #127
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @armouredking on GitHub (Jul 9, 2016).
I don't know what specifically it is about the "Sort book" function that makes the PHP script take so long, but if you're sorting a book composed of many chapters and pages it will take a long time and in my case it's hitting the PHP timeout wall causing a gateway error. This in turn results in the database having chunks missing - I "lost" an entire book this way.
To be clear, when I say "lost" I mean it no longer showed up in the front end. The database itself still contained all information from the "missing" stuff.
I was able to correct it by creating some extra books in order to split the big book up, going into the database, manually altering the ids to match where they should be based on the tables ( but now split up into 4 other books ), then as my administrator account on the front end sorting each book ( I just moved one item up or down in there to cause a 'change ). The books would not show up on my regular user account directly following the database edits, but they did show up for the administrator account following the database edits hence why I used it. Following the sort by the administrator account, all user accounts were able to "see" the books again.
Granted, one way to correct this would be to increase PHP timeout but this should not be necessary. While the book is large ( 19 chapters, 224 pages ) it shouldn't be doing that. I don't know what BSA is meant to 'scale up to' but I wouldn't assume these values should be it's stopping point.
A theory; perhaps it's because it's trying to save every entry? I don't pretend to know how the sort function of BSA works ( not a coder ) but if it's trying to physically save each page entry over itself then that might account for the long load times using the sort function. The "pages" table of my BSA instance is now at 79.7MiB ( for the whole thing, not just this book ). This book was probably the largest one I had made up so far, but I have a couple more approaching it in size ( with 16 books in total ). The speed that a "book sort" completes is directly proportional to the amount of items in the book ( in my experience ).
Updating with environment information from other bug entries:
@ssddanbrown commented on GitHub (Aug 26, 2016):
Hi @armouredking, Really sorry about this issue and the problems it caused you.
There was indeed some inefficient code which was causing way too much database access. I set up a controlled test (Swapping a chapter between two books) to benchmark and worked on improving the speed. Here are the results:
The tests are performed as a best-case scenario but the results mean that all sort operations should now be vastly sped up.
This change will be in the next release version of BookStack.