Cache Layer
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.
Pre-fetching
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.
Data-Layer Enhancements.
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.
COMMENTS
This is great! Looking forward to 3 big releases!
This is going to be great. Can’t wait to get started with this release!
This looks awesome! I am really looking forward to the Cache Layer Feature most! Way to go Work Etc. Keep being the best!
Looking forward to even better performance. Thanks for your commitment to continuous improvement
Thanks for the feedback.Having used the updated code, it has certainly made a huge difference. Look forward to hearing how it impacts on your business
The ideas you have planned to implement are great. Caching is always a good idea. I worry about whether we might see stale data coming back from time to time, though.
And for those of us blessed with a (painfully) slow French internet connection… praise be for Pre-fetching!
well done! As our business grows speed and efficiency have become major factors in project management – and increasing the already realized savings from WE is another great benefit.
As our company grows tagging new contacts is vital for our business, this is a tedious and slow task, now with this improvement the job is done mutch faster!! thanks!!
The speed issue was starting to be a bit of a pain to be honest so thanks for addressing it, good work.
Speed is important with all web applications! We deal with this issue with our customers as well. Thank you for addressing the issues!
Pre-fetching is a very intuitive idea. With speed always playing a part in web applications, being pro-active in downloading content can really help out the end user.
Excellent concept. I have not really noticed speed issues but it’s nice to know they are staying ahead of the curve.
Thanks for this, as a developer these are concerns I face in my work. I have noticed that W[e] performance has increased recently (I have been a user for approx 14 months). How much would you say pre-fetching has improved performance, or is that difficult to quantify?
Good stuff – I think the search area for people is still a WIP – but really keen to see the design refresh 🙂
Speed is indeed the most important for web applications. We changed all our systems to only work in the cloud and slow web applications are not easy to work with especially cause it slows down the workflow.