We should probably stop saying “unlimited cards”…

OK, so our website has long stressed the word “unlimited”, and maybe that’s not such a great idea…

Most people have boards with a few dozen cards.

Some folks have boards with a couple of hundred cards.

Very few people have boards with up to 1,000 cards.

It turned out that one of our users had a board with nearly 4,200 cards, of which over 4,000 were in the Trash.

And that’s not good! A board with several thousand cards on it is going to take a long time to load, because each card has many different attributes to it: details, chat, assignments, status, history, etc.

And when someone with a very large board uses Kerika, this can cause very unexpected loads on the servers, particularly in terms of network I/O and CPU utilization.

This is what it looks like when someone suddenly opens a board with thousands of cards on it:

CPU spikes
CPU spikes

We have talked about this before, and now we need to do something about it…

Most of the time, boards get very big because they are very old: stuff piles up in the Done column, or, as in this case, in the Trash column.

Having very large boards can impact performance: unlike, say, email which you may be accustomed to leaving piled up in your Inbox for years on end, Kerika’s cards are “live object”: even when a card is in the Done or Trash columns, it is constantly listening for updates from the server, because it could be moved out of Done or Trash at any time by someone on the team, or have some of it’s attributes changed.

For example, even though a card is “Done” or “Trashed”, it could have its details updated, or new chat added to it.

This is different from email messages, which are essentially “dead objects”: once you get an email and read it, it doesn’t update after that, so it can sit for years in your Inbox without trying to get fresh updates from the mail server.

So, when you have 4,200 cards on a single board, you have that many live objects trying to get updates from the server at the same time, and that’s not good for your browser or our server!

(Imagine your laptop trying to read and display 4,200 emails at the same time, and you will get an idea of the problem…)

Having very large boards is not a good idea from a workflow or process management perspective, and so perhaps Kerika needs to do something about it: we need to think about how we can help our users improve their workflow, while also avoiding these CPU spikes.

A couple of ideas that we are considering:

  • Start warning users when their boards are getting too big.
  • If boards hit some threshold values (which we have yet to figure out, maybe it’s 1,000 cards?) force the user to reconfigure their board so they don’t affect the quality of the service for everyone.