Worried about the load on the DB for something that will generate as much traffic as the revision text. Currently revision text data scales only because old revisions get archived into External Storage (http://www.mediawiki.org/wiki/External_Storage).
First we need to estimate how much load/data we are generating currently. To do that Asher needs the following numbers:
- proposed site %: 10% on July 3
- current % of site that has AFTv5 on
- current rate of new feedback creation
- an estimate of the % of feedbacks that have comments > 255 characters
Since it was determined to 255bytes is not an acceptable comment input limit that can be surfaced in the UI. We consider the following possibilities
- If the rate is small enough, it may be possible to close this bug without addressing the issue at all
- Most likely, we should scale therefore we propose the following changes be added to the code before July 3 ramp-up
- Add table af_article_answer_text with id's aa_article_answer_text_id
- Change the schema of aft_article_answer to add a row aa_article_answer_text_id of type integer unsigned (foreign key into above). is_null is allowed
- Change type of aa_response_text to varchar(255)
- Change code to do a join against the above
- When saving, if text > 255 bytes, save to new table and add link plus empty aa_response_text field to the db
- (Optional: migrate/upgrade old text files > 255 bytes)
- If (2) isn't good enough then we're s.o.l. until August when sharding becomes available.