Bug 1065586 - csprocessor will sometimes fail to assign fixed urls when building new books
Summary: csprocessor will sometimes fail to assign fixed urls when building new books
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: PressGang CCMS
Classification: Community
Component: CSProcessor
Version: 1.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 1.5
Assignee: Lee Newson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-15 04:46 UTC by Matthew Casperson
Modified: 2014-08-04 22:28 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-01 21:40:03 UTC
Embargoed:


Attachments (Terms of Use)

Description Matthew Casperson 2014-02-15 04:46:33 UTC
I have seen this error a lot lately:

Doing Fixed URL Pass
        Failed to update the Fixed URLs for the topic

This happens when building a new book (with between 80 and 90 new topics). It happens over a VPN and when building books on the server itself, so it is not network related.

Comment 1 Lee Newson 2014-04-03 23:54:52 UTC
Doing some debugging for BZ#1067783 showed that this appears to be failing because of a timeout on the updateTopics() REST call, so we might be able to mitigate it by doing updates in batches until BZ#1070040 is implemented.

Additionally we should probably take a look at why it is so slow server side on doing the updates.

Comment 2 Lee Newson 2014-04-04 05:58:52 UTC
Doing more investigating into this issue turned up that because the XML validation was always being performed, even when the XML wasn't changed, it was slowing down the processing time. eg (these values are just for the processing and exclude DB commit time):

With XML Validation/Processing/MinHash calculation:

80 topics took 97 secs

Without XML Validation/Processing/MinHash calculation:

80 topics took 13 secs

(Just for additional details, for 80 topics it was taking about 40 secs to commit)

Comment 3 Lee Newson 2014-04-11 01:44:14 UTC
Fixed in 1.5-SNAPSHOT build 201404041725

Builder:

The builder has been updated to do a couple of optimizations. The first is that the fixed urls will now be updated in batches to seriously lower the chance of a timeout occurring. I've also updated it so that there will be a couple less calls, in the event that the fixed url isn't unique within the book.

Server:

I've wrapped the xml processing/validation in a check so that it will only happen when the following is updated:

- XML
- Title
- Locale
- Format
- Tags (due to the topic type)

Comment 4 Lee Newson 2014-04-11 03:15:32 UTC
To add some more stats to this, it looks like the MinHash calculation is the most time consuming part (for 80 topics):

XML Processing Average: 0.007 seconds
XML Validation Average: 0.09 seconds
MinHash Calculation Average: 0.46 seconds

Note: The above values are all tested with a warmed up cache and no load. Here are the initial values of 2 small topics  (ie a title and 2 paras) with an empty cache (app and db server restarted before each test):

XML Processing Average: 0.008 seconds
XML Validation Average: 0.21 seconds
MinHash Calculation Average: 0.45 seconds

The above difference in the Validation times, is likely due to the BlobConstant being used being cached. This however doesn't apply to the MinHash calculation since it uses a query to get all the XOR values and we don't have queries configured to cache, as such we should be looking to cache those values as well (see BZ#1074705).

Comment 7 Matthew Casperson 2014-04-22 21:22:45 UTC
Tested this by creating a fairly large new book that I know failed previously and building it locally. Fixed URLs were successfully generated.


Note You need to log in before you can comment on or make changes to this bug.