Jump to content
bfarber

Resource Improvements for 2.3

One of the driving focuses for IP.Board 2.3 was resource usage. We wanted to spend some time on improving the underlying operation of IP.Board, even if this meant not adding a lot of new features on the surface. As with most applications that develop beyond a few releases, over time so many features have been stacked into IP.Board that, while not necessarily ineffecient, we felt we could revamp some of the underlying code to make IP.Board run even better.

We wanted to highlight a few of these changes for those who are interested.

  • The parse_member method of topics.php has been moved to ipsclass.php to make it more centralized, as it's used by many various classes in IP.Board.
  • Similarly the member_set_information method out of profile.phpand into ipsclass.php as well.
  • We've added a new feature that allows skin template bits to be shared across different skin files. With 2.3 you can now simply edit the some template bits and automatically update all skin files where those bits are used. There are several template bits making use of this functionality to help reduce the number of skin files loaded on any given page view.

    If you would like to make use of this functionality (for example, with a custom modification), you can select to share a template bit to another skin file by going to Look & Feel -> Edit Template HTML for the skin -> (Select a skin group) -> (Select a template bit). Click the drop down button where you would normally edit the template's incoming data variables, and hit "Edit Cache Settings". You can select (or review) secondary skin cache files that will share the template bit you are viewing.
  • We've added a few more database indexes based on our analysis of some common database queries that IP.Board runs.
  • With 2.2, we introduced the new profile portal functionality in IP.Board. This uses an iframe to load center content, which requires a second call back to the server to load the center column content. In 2.3 we've pre-loaded the first tab's content to prevent this second request (on the initial profile page load) from being required.
  • For 2.3 we've added a setting in the Admin CP under CPU Saving and Optimization labeled "Use multi-byte safe wordwrap". International users can continue using the word wrap function more suited to matching 2 and 3 byte character sets, while users with only English text on their forum can use a much more effecient word wrapping function that doesn't need to take multi-byte characters into account.
  • We've also added a setting in the Admin CP under CPU Saving and Optimization labeled "Disable Topic Summary". Setting this to Yes will turn off the topic summary displayed at the bottom of the Add Reply page. This setting is Off by default (the summary will still display unless you turn it off).
  • We've disabled the custom error handler by default in IP.Board 2.3, which prevents our custom error handling function from being called with every PHP Notice (which are not displayed). If you'd like to revert this functionality, just edit init.php and change

    define( 'CUSTOM_ERROR', 0 );


    to

    define( 'CUSTOM_ERROR', 1 );

  • We've optimized our post parsing routine by preventing two expensive usort calls from being required, as they are already run when the associated data is saved in the admin CP.
  • We've enhanced our MySQL database driver when doing field_exists and table_exists method calls by
    • Using a 'SHOW FIELDS' query rather than a 'SELECT COUNT(col)' query to determine if a database field exists
    • We cache the fields in a table, and the tables in a database, the first time a field_exists or table_exists query is run to prevent having to query the database for the same data later during script execution
  • Announcements, Private Messages, Calendar Events, and Topic Posts are now parsed entirely on save, rather than when displaying the data (or in the case of topic posts, half on save and half on display). This prevents the parsing from running on display, and prevents having to load several parsing libraries and associated caches when displaying the data.
We've enhanced the rebuild posts tool to also support private messages, calendar events, and announcements for users who will upgrade and need to rebuild the content (to parse html and custom bbcode appropriately). Rebuilding posts will be necessary after upgrading in order to ensure all custom bbcode is parsed, however upon doing so we will be saving many resources at run time, which is by and far a more important consideration.

I hope this helps detail and clarify some of the resource improvements made for 2.3. The good news is that if you didn't notice any of these things already here on the company forums, then our changes are working exactly as we had hoped - same surface functionality, a much stronger backend to handle it.

×
×
  • Create New...