Forum:How we fix slow articles

Forums: Index > Watercooler > How we fix slow articles

I have come up with a technique that will allow contributors to create arbitrarily complex templates without making page loads slower for other folks that may not be interested in the features provided by those templates. This "cache property" technique performs all the complex work on a subpage, then stores the results of the processing in a property or properties with the type "code". The main page simply loads the result property and is freed of the labor of recalculating it. A short technical description may be found below. Anyone interested in details please contact me.

One idea floated earlier was to validate values for consistency. Such a quality control page could be done this way. EG: does the page name or any of the values have all cap names, are the locations valid place names, do the dates make sense (eg child born to a woman that would have been 9 years old).

• If any of these conditions are true, then the article is placed in hidden maintenance categories EG: articles with all cap names, articles with inconsistent dates, and so on.

If this "cache property" method is fruitful, it will mean that we don't have to choose between speed and features. We can have both. The cost is only that the data from time consuming templates will be out of date until the page is updated (either manually with a refresh, or via someone using Help:AutoWikiaBrowser to periodically refresh them.

---

In a nutshell...

• Say page foo calls Template:LetsWatchPaintDry
• Create page foo/someSubPage
• Move your slow templates to that page and store the results in a property or properties of type code For instance:

  {{#set:DriedPaint={{LetsWatchPaintDry}} }}

  • An example of a property of type code may be found at Property:Birth blurb
• Display the results on the main foo page with a normal show call, EG:

  {{#show:foo/someSubPage|default=|?DriedPaint=}}

~ Phlox 17:53, October 10, 2009 (UTC)

This operation is largely complete, and folks should notice a marked increase in speed of displaying and saving main pages. Anyone concerned about pages using showfacts templates that do not appear to be any faster, please contact me.

Folks not using templates don't need to do anything different except press the create sensor page if they wish to have the benefit of sensor page features. For template users and writers, time consuming templates should be placed on a /sensor subpage, and the only part on the main page (if any) would be a quickly executing template to move the results to the main page. This means that most users viewing the main page will not see any slowdown, but will gain the benefits of the calculations performed "in the background" on the sensor page. If sensor pages are not automatically refreshed by normal wikia operations, a bot will be run on a periodic basis (monthly or perhaps faster or slower) to force updates during times of low server load.

An simple example a main page display of a sensor page result would be a templates that sets a category based on a property calculated on the sensor page. A more complex example of this would be to display a table with the statistics on the percentage of ethnic groups represented for the person. All the main page would do is fetch the property with the calculated values and put them in a table. The math and lookups for all the values would take place on the /sensor subpage. (If anyone wants to do this particular template, you could quickly scan the ancestors property and use the ahnentafel values of all leaf most nodes to calculate the proper values. Of course, folks would have to start encoding and ethncity/ancestry group property in a uniform way, so it might be tough to get folks to save the data needed to make this work.)

There are more speed improvements to come, but probably this will have been the biggest increase in speed.

~ Phlox 16:42, November 6, 2009 (UTC)