The Witnet explorer: version 1.2

It is time for another release of the Witnet explorer. The most significant improvement in this release is that it adds request caching. It improves the average response time for the end user and offers a smoother overall experience while using the explorer.

Implement request caching through memcached

In the previous version of the explorer, most user requests were not cached or only cached after it was requested once. This lead to pretty slow response times for heavier requests such as fetching a data request report. This release improves this behavior by adding upfront data request report caching. Essentially, the explorer will now watch for new data requests, (re)build the report on each block and save it in a memcached instance. In doing so, the explorer response time improves significantly as evidenced by below plot.

Previously, fetching the result of a data request took on average 1.28s on average. In the new release, fetching a cached data request report takes only 0.14s on average. This is an 8.9x imrovement in response time!

Of course, fetching a data request report which has not been cached will still be pretty slow. Currently, I am caching every data request report which is less than 3 months old.

Next to data request reports, the explorer will also cache value transfer transactions and blocks, as well as the home, reputation and balance page.

Bugfixes

Of course, this release also contains a number of (visual) bugfixes. Some of these were reported by other users and in the context of the Witnet Community Developer Program, they were rewarded for this [1], [2], [3].

The funniest bug I encountered in the past months was a crash in the explorer backend because someone sent a value transfer transaction with a fee of 1900 WIT. Because of the magnitude of this fee, the priority (transaction fee divided by transaction weight) did not fit in an integer type anymore.

A dedicated server

In order to be able to cache all this data, I had to move to a more powerful server. As of now, the explorer runs on dedicated hardware. This should allow it to scale well into the future.

Next steps

Some of the component of the explorer such as address lookups are not cached yet as they are not static. Caching them is quite resource intensive as they potentially need to be updated on every block. The plan is to explore how this can be improved.

As always, if you encounter a bug, send me a message on Telegram or Discord and you may just be eligible for a reward.