All IP.Board updates via the RSS feed here

My opinion may be abit harsh but IP should stick to forums and possibly CMS; this will go wrong like vBulletin trying to get a taster of CMS action.

 

This seems like a very niche option with the hosting?

I think this comment hit it on the head from mat206...

 

As part of our ongoing commitment to deliver the best community software on the market, we routinely run IP.Board through various tools designed to measure efficiency and resource usage, helping us to identify areas that could benefit from minor and major refactoring to make the software more efficient. We do this periodically with all of our software in order to ensure we have not introduced new code that will cause resource usage problems on your community. This is typically an unexciting task that does not garner much interest from the average user, but we thought some of you might enjoy hearing about some of the resource-based improvements we have made for 3.2.3.

If hearing about the nitty gritty details that go into making the software used to power your community is of interest to you, read on. If not, and you just want to hear about upcoming features or service offerings, please skip this blog entry and stay tuned for next time!

What are we looking at?

When looking at the amount of resources our software uses, there are multiple points to consider. You have to keep an eye on memory usage, CPU usage and disk space usage. You have to consider the entire server stack too - MySQL, Apache (typically) and PHP, and of course the PHP code itself (e.g. IP.Board). There are some things within our control while developing the software, and there are some things that can only be controlled at the server level, so it is important to consider all angles (and server configurations), while tailoring the software to work in the widest array of environments possible. While we cannot control your MySQL or Apache configuration, some improvements can be made at the software level that will benefit everyone, regardless of your configuration, so we often look to these improvements first.

One tool available to PHP developers that can help while you profile your code to look for improvements is xdebug, and this is where the focus of this blog entry will be. When you use xdebug to profile PHP code, a file (called a "cachegrind" file) is created that you can then load into another software package in order to view the results. The most popular tools to view cachegrind files are kcachegrind (for Linux) and Wincachegrind (for Windows). If you are not familiar with what this looks like, here's a quick screenshot to give you an idea (taken using Wincachegrind, since I'm a Windows user):



Note: Times indicated are not representative of a normal page load. I run my local environment with development mode enabled which utilizes far more resources than normal, due to rebuilding of many caches, including skin cache files, on every page load. The screenshot is merely designed to give you an idea of the interface and types of information available with the tools used.


So...what did we find?

Well, it's rare that we find something big, because we routinely run our software through tools such as this. You generally only find huge areas that can stand for improvement when working through major code refactoring (such as IP.Board 2.x to IP.Board 3.x). We did, however, find many smaller areas of improvement that collectively can mean big resource gains when added up together. If you save 50ms of processing on a page, and that page is hit 10,000 times in a day...well, you can do the math.


Static caching

We found many functions that were called several times on each page load, very often with the same data, returning the same result. Without caching, the functions are required to perform the same operations repeatedly, so we added static inline caching to store the results from the processing so that future calls can just fetch from the cache, instead of reprocessing the same data, and returning the same result.

Some functions where we added static inline caching for 3.2.3:

• IPSMember::unpackGroup()
• IPSMember::makeProfileLink()
• IPSLib::getEnabledApplications()
• IPSMember::setUpModerator()

Unnecessary code processing

Every operation a PHP script has to perform consumes some level of resources; sometimes this is negligible and sometimes this is measurable and important. When code is executed that does not need to execute, however, it is simply a waste of resources, no matter how small that may be. In reviewing the profiling results, we found some code that was executing which simply did not need to, which we removed/fixed.

• We found some various array checks in the output class that were unnecessary, as the array was a class property and initialized when the class was instantiated into an object.
• We were parsing some dates in the search results area twice, when we only need to do so once.
• We were parsing the post content in search results, even when we displayed the results as topics. Parsing post content is an expensive operation, so this unnecessary operation was particularly wasteful.
• We found that one particular IP.SEO hook is outdated and provides no benefit as of 3.2.0. This will be investigated (and potentially removed) with the next release of IP.SEO: http://community.inv...topiclinks-hook
• Several operations were running when displaying a mini-calendar which were unnecessary (because the results were never displayed in the skin).
• The IP.Downloads board index latest files hook was loading the category helper class twice, unnecessarily. Similarly, some of the functions within this class were called multiple times, unnecessarily.
• IP.Downloads was utilizing an unnecessary "GROUP BY" SQL clause. Generally, this requires a temp table to be created, and in this case it was unnecessary.
• The UCP Manage Attachments page queries for attachments even if it discovers there are none (through the SELECT COUNT(*)... query that is first run). We removed this second query when there are no attachments to retrieve.

More specific changes...

Additionally, we have found several more specific areas of improvement that we have corrected for 3.2.3. These areas of improvement, as a general rule, improve resource usage more than the items listed above, but are less trafficked and thus less likely to be noticeable. As such, your mileage may vary with these improvements depending on how your site is utilized by your members.

We build a cache of each item's 'like' data, and store this separately so that we do not need to query all of an item's like data on every page load ('like' data here means the follow/unfollow system in IP.Board and applications). We were caching this for one hour, however the software is doing a good job of ensuring the cache is rebuilt as needed when records are deleted and so forth. Thus, we have increased this cache from one hour to one day, limiting how often the software needs to rebuild this cache.

A change that we made to one of our JSON encoding routines was causing significantly more resource usage compared to previous versions. We reverted that change back to match 3.2.2, saving nearly 100ms of processing per page this occurred on.

We have a call in our registry destructor that saves topic markers back to the database so that they are not lost between page loads. This is necessary, of course, in order to maintain topic markers across different browsers and computers. We found, however, that this was occurring even when you were using an application that does not utilize the item marking system in our framework (for instance, when you are browsing IP.Calendar). By adding a check in the destructor, we save the software from having to load up the topic marker library, parse all topic markers, just to save them back to the database when the application you are using does not need item marking capabilities.

We discovered a minor bug with the reputation cache loading when the central comments class was utilized in some cases. In certain places, the reputation cache would not load correctly, and while the software largely corrected for this automatically, it meant using more resources than necessary to rebuild this cache because it did not load correctly the first time. By fixing this bug, we saved the software a lot of extra unnecessary processing (and fixed an unreported/undiscovered bug in the process . ).

We found some applications were not loading caches (from the cache_store table) that they were using. We added these to the initialization routines for the respective applications, saving database queries later on to fetch the caches individually.

We discovered a few areas that were calling IPSMember::buildDisplayData() were not caching the member data as designed. Upon inspection, this was because the member data was joined onto the main queries, rather than fetched separately, so the check in buildDisplayData() to verify the same information is being passed always failed. By refactoring how we pulled members and called this method in a few places, we allow the software to cache the results and prevent parsing of data multiple times unnecessarily. In most cases this means an extra database query, but less PHP processing - the tradeoff is worth it in this case, as the PHP processing is more expensive.

In IP.Content, attachment parsing was happening in a loop for each record that was being displayed in listings. While this is not a problem by itself, per-se, we were able to refactor the code to parse all of the attachments at once, allowing us to run just one database query, instead of one per-record.

Again, in IP.Content, we found that the topic posting library was being called when you were a moderator and unpublished or unapproved records were being displayed to you. The topic library was called in order to post the topic (that mirrors the article, or stores the comments, depending on your configuration), however it was not necessary since the article is not yet visible. We added some simple checks in the code to save from having to load this library unnecessarily.

And last, but not least, we found a major improvement area for IP.Calendar. The mini-calendars displayed in IP.Calendar (and in IP.Content mini-calendar plugin blocks, and on the board index if you utilize the calendar mini-calendar hook) are very much static HTML. The only change that occurs in these mini-calendars is that the current day is bolded, if you are viewing the current month. We utilized some clever caching techniques (using the cache_store table) in order to save the HTML output that is generated, and then we reuse this output instead of rebuilding it repeatedly. The end result is that mini-calendars only need to rebuild once a day now, instead of on every single page load.


Conclusion

IP.Board and our addon applications have large, complicated code-bases. We are beyond the stage, for the most part, where you will find silver-bullet resource hogs in the code that you can fix by adding a simple database index, or changing a couple lines of code. Instead, we are always on the hunt for areas of the code that are heavily utilized (such as library methods) as any small improvements in these areas will add up to significant gains based on the sheer number of calls to the methods.

The above changes may seem minor and unimportant, but the end result was that some pages, following the changes noted above, utilized anywhere from 10ms to 200ms less processing time. When you multiply that by the number of times the pages are viewed in the course of a day, you start to see very real and useful improvements in loading time, without the loss of any existing functionality. These are resource improvements that benefit all sites, from the smallest to the largest, and we are glad we could implement these for 3.2.3 to help you make the most of your community.

Continue reading...

 

Invision Power Services, Inc. is pleased to announce the release of IP.Board 3.2.3, IP.Calendar 3.2.2, IP.Downloads 2.4.2, and IP.Content 2.2.2!

These are maintenance releases after our highly anticipated release of IP.Board 3.2 and its related applications. These releases fix many reported issues.

We are releasing the following new software:


IP.Board 3.2.3
Fully featured community platform including forums, members profiles, status system, integration, and much, much more.


IP.Calendar 3.2.2
Event calendar for your community with multiple calendars, public/private events, and iCal support.


IP.Downloads 2.4.2
Complete file management application including file version control, commenting, and forum topic linking.


IP.Content 2.2.2
Content management for your community - run a full web site or a simple community portal. The possibilities are endless.



Release Notes

• If you are upgrading a community with a large number of posts from version 3.1.4 or earlier you may wish to have your web host execute the post table alter query on your behalf. Large post tables may time out running this query in the browser. The upgrade system will warn you if this is needed. As a benchmark, our install of 865,000+ posts took a bit less than 3 minutes to run this query.
• If you are upgrading from version 3.1.4 or earlier, your skin will of course need to be redone after you upgrade to 3.2.
• The visual skin editor in 3.2 should still be considered a beta feature. It will be improved with each maintenance update.
• Each of the applications specified above is only compatible with IP.Board 3.2 and not older versions (for example, IP.Nexus 1.3 cannot be installed on IP.Board 3.1.x).
• We may reply to this topic with hot-fix patches or notes if any critical issues come up so please use the "Follow this Topic" feature to get notified.
• If you experience any problems, before submitting a ticket, please disable all third party applications and hooks.
• Please remember that IP.Calendar and IP.Chat are separate downloads in your client area. You will need to download and upgrade these separate applications (in addition to IP.Board itself) if you wish to continue using them with IP.Board 3.2.

What's New

In addition to many fixes for reported issues, the following changes have been made:
IP.Content: WYSIWYG fields now allow you to configure how to handle line breaks when HTML is accepted

• IP.Calendar: Users can now un-RSVP themselves from events
• IP.Board: HTML emails
• IP.Board: URL photo import
• IP.Board: Autosave and editor live-switching in ACP

Continue reading...

 

They sure do post a lot of updates..

 

To wrap up our series of blog entries on IP.Nexus 1.4, there's just a few more new features and enhancements that warrant mentioning.


HTML Emails

Matt recently blogged about the new HTML email support in the IPS Community Suite....

View the full article

Continue reading...

 

IP.Chat is our AJAX-powered chatting software application, available as an addon for IP.Board. IP.Chat takes a "less is more" approach and focuses on providing a simple but powerful interface for your users to chat, real-time, on your forums. We have spent some time enhancing the functionality available in IP.Chat to make it more...

View the full article

Continue reading...

 

Ever have a question you wanted to pose to our staff? Now is your chance for one on one Question and Answers with IPS.

Post a new topic here: http://community.inv...um/474-ask-ips/

For a limited time only. Act now. On sale today. Come on down. Etc.


Note: we're getting some duplicate questions so we will only answer one in...

View the full article

Continue reading...

 

Commenting is an integral and central park of our application framework. Because we have a solid commenting system in our core framework, we can easily and consistently role out commenting to each of the addon applications, while delivering a consistent experience no matter what application the user is using. While commenting itself has been...<br /><br />View the full article

Continue reading...

 

Invision Power Services, Inc. is pleased to announce the release of IP.Nexus 1.4.0!

This newest version of IP.Nexus adds many features and fixes reported issues to enhance your community commerce.

IP.Nexus 1.4.0

Fully featured commerce system to sell products, membership access, advertising, digital downloads, and more. Includes tools like a support desk to help manage you clients.


Release Notes
IP.Nexus 1.4.0 requires IP.Board 3.2.3.



What's New

In addition to many fixes for reported issues, the following changes have been made:

• http://community.inv...ate-storefront/
• http://community.inv...update-hosting/
• http://community.inv...der-management/
• http://community.inv...s-enhancements/

Continue reading...

 

One of the most critical areas of a download manager application is, naturally, the download process. There are many things to factor in - you want to ensure the security of your files, you want to ensure the integrity of the system, and you want to ensure a nice user experience. IP.Downloads supports many features to help you control who can...

View the full article

Continue reading...

 

IP.Downloads features a robust and powerful file submission process, allowing your users to quickly and easily upload files to your site and configure them to the specifications your site has set. Users can upload multiple files and multiple screenshots, using either the traditional uploader or the flash uploader; you can configure custom fields...

View the full article

Continue reading...

 

IP.Blog is our popular blogging platform for the IPS Community Suite. We've been working on updates and improvements to this platform for the upcoming 2.5 release which we wanted to talk about today.



Interface Improvements

We've spent a lot of time cleaning up the interface and making use of the new styles available in 3.2. The...

View the full article

Continue reading...

 

Just combined all the 2.5 updates to one thread.
I don't think we need 4 threads for them right now..lol

hmm.. I wonder if I can get all the IPB feed post to go to one thread, allt he vB ones to another etc.. Allow comments on them still but have all of the feed updates to go to one main thread... I'll have to look into that

 

IP.Gallery is our popular photo and movie sharing platform for IP.Board. We've been working on updates and I wanted to take you through a few of them today.

IP.Board 3.2 introduced many new core features such as tagging and a Moderators' Control Panel. These features were written to allow other applications to take advantage of them...

View the full article

Continue reading...

 

We've already blogged about some miscellaneous changes you can expect to see coming in IP.Downloads 2.5, and hope you are excited about these enhancements and improvements to the software. We have just a few more changes we wanted to let you know about, so without further ado, and in no particular order, read on to see what else you can...

View the full article

Continue reading...

 

IP.Gallery is our popular photo and movie sharing platform for IP.Board.

Today, I wanted to take you through an important part of the IP.Gallery 4.2 update; the album selector.

At various places within IP.Gallery, there is a need to select an album. This may be because you're creating a new album; choosing an album to upload into; moving...

View the full article

Continue reading...

 

IP.Gallery is our popular photo and movie sharing platform for IP.Board. We've been working on updates and I wanted to take you through one today.

The IP.Gallery 4 Admin CP Album Manager streamlined down the various Admin CP functionality for managing albums but it was hard to locate specific albums and to drill down through the global album...

View the full article

Continue reading...

 

IP.Gallery is our popular photo and movie sharing platform for IP.Board. We've been working on updates and I wanted to take you through several today.

You've already read about the bigger features for IP.Gallery 4.2.0 such as tagging, quick navigation, moderators' control panel, album selector and the Admin CP updates.

This entry...

View the full article

Continue reading...

 

Invision Power Services, Inc. is pleased to announce the release of IP.Chat 1.4.0!

IP.Chat is our community live chat platform for IP.Board allowing you and your members to chat in real time. It is offered as a free service for all IP.Board users and can be upgraded beyond the free package levels for busy rooms. Changes and new features in this version include:

• Ban Confirmation - when right clicking on a member chattting and selecting 'Ban User' a confirmation is now offered to prevent accidental banning.
• Unbanning from ModCP - chat room moderators are now able to unban members from the chat room if required.
• Redesigned Interface - following feedback from customers, we have made some changes to assist with the use of the chat room.
• Mobile Support - it is now possible to use the chatroom from the mobile skin in Android, iPhone, Blackberry devices and more. Private chats are also available in the mobile skin.
• Full Guest Support - now it is possible to allow guests to use the chat room, subject to your permissions allowing it. As with members it is possible to have private chats and kick the guests if required. Guests will be shown as "Guest_####" (where #### is a random number).

Thank you to our team of Beta & QA testers who have made this release possible.

You can view our earlier blog on this release here - http://community.inv...lopment-update/

We welcome feedback on this or any other release in the relevant feedback forum http://community.inv...rum/436-ipchat/ including suggestions for future releases.

Purchasing

You can purchase IP.Chat right in your client area by clicking the green New Purchase button in the upper right corner. New clients can purchase IP.Chat right along with IP.Board. If you an IPS Community Hosting client, IP.Chat comes with all packages!

If you have already purchased IP.Chat, you can download this update in your client area.

NOTE: IP.Chat 1.4.0 requires that you be using IP.Board version 3.2.3

Continue reading...