Let’s talk about the caching layer first. For those that might not be aware what a cache is, the term is most often used in reference to web browsers where a cache is used to store a copy of the web pages and graphics you’ve recently viewed. By storing these items in a database on your PC it makes them faster to view the next time you return to view those web pages as your browser can just load them up from your PC, rather than having to pull them down again from the Internet.
What we have built is a cache that sits alongside your WORK[etc] account on the main WORK[etc] servers.
At the moment when you request a page of information from your account, our servers will take your request and pass it through to the application and database where a whole lot of calculations are actioned. Once completed, the returned data is used to create a web page and that is sent back down the Internet to your web browser.
It is a lot of work but mostly this all happens in milliseconds. Except what we’ve been starting to see is that on some pages where the information request is exceedingly complex or where an account has an extreme amount of active data, those milliseconds sometimes balloon out to seconds. And a second on the Internet can feel like an hour.
With this release we introduce a cache layer that sits between your web browser and the application server. The first time you request a page, that will request will push through the application and then the database servers to create the required data; pushing the completed page back to your web browser. However on the way through, the new caching layer captures all that information and creates a secure instance of your page.
Now, the next time you go to view that same page, the cache will step in on your request and within milliseconds determine if there have been any updates to that page. If there are no updates it will immediately send you back the page rather than go to all the effort in re-creating the page. If there have been some changes, then it will grab those changes, rebuild the page, save an updated version of the page for future use and send you back that most recent version.
It is important to remember that some of the activities you view on WORK[etc] might change hourly, for example a really active support ticket. Some information might only change daily, for example a hot sales lead. A contact list might only change weekly and contact details for a specific person might only change every few years.
Many pages that you hit frequently will now load instantly. But if you do hit an updated page, then it will load (the first time) as it normally would. For example, switching between the different tabs on a Project’s Activity Stream will now be almost instantaneous.
The Phase 1 release of the data cache has been built for
- Main screens for Projects, Tasks, Support Cases, Sales Leads and Discussions
- The Activity Stream across all modules.
- Discussion threads.
Closely related to the Cache Layer is our expanded use of pre-fetching information we think you’re going to want to view next. For example, if you load up the main Discussion page the odds are fairly good that you’ll want to view at least one of those discussion threads that you can see on screen.
Rather than wait for you to click on a particular thread headline before fetching the actual discussion, we now start downloading the contents of all the discussions you can see on screen. In the few seconds that you’ve taken to decide which discussion thread to view and moved the mouse to click it, WORK[etc] has already pre-fetched that entire discussion thread, allowing it to show instantly. This is a dramatic improvement on the old method where we waited for you to make a decision, then went off and fetched that discussion.
WORK[etc] is now also better equipped to fetch multiple objects at the same time. So, in the old version of WORK[etc], if you need to request 10 data items to build your page, then WORK[etc] would have to request each item at a time. The application is now better at merging multiple requests into a single query to reduce the number of database calls. We’ve also refactored the code to reduce requests for data that won’t be displayed or used by the request.
Who is Eligible for this Release? When will it be available.
This major Performance Enhancement will be rolling out across all accounts and all plans later this week (along with the other two surprise releases!)
If you’re jealous of the beta users who have had access to this new release for months already, don’t be. All you need to do is become an active member of our WORK[etc] Insiders’ program. We use this group to test product ideas and make available early beta releases. In the coming months we’ll be inviting top Insiders to beta test our upcoming design refresh and iPhone apps.