Page History

...

Testing without local modifications

Local code modifications – especially custom list views and filter policies – can introduce inefficiencies that lead to poor performance. Similarly, code under development may contain performance regressions or new features that have not yet been optimized.  If you have made any such modifications or are using pre-release code, it is important to test performance when your VIVO database is used with an official VIVO release.  If the observed performance differs significantly from that exhibited by a modified version, the modifications are suspect.

Tuning for improved performance 

...

If VIVO's dynamically-generated pages do not exhibit acceptable load times, you may wish to enable HTTP caching.  See Use HTTP caching to improve performance.  With this configuration, subsequent requests for pages whose contents have not changed will result in those pages being served directly from a cache instead of being regenerated from data in the triple store.

...

While VIVO is tested with and configured by default to use Jena's SDB triple store with the MySQL database server, VIVO also includes support for TDB and Virtuoso as well as the ability to connect via HTTP to a SPARQL 1.1-complaint endpoint.  Use of a different store may yield performance improvements, offer additional possibilities for performance tuning, or enable features such as clustering and load balancing.  In addition, configuring SDB to use a database server other than MySQL may offer advantages for your installation.   Note that some of the SPARQL queries in the list views employed by VIVO in page rendering have been optimized for SDB/MySQL with substitution of UNION for OPTIONAL.  These queries should be modified for optimum performance with other stores that do not exhibit the same quirks.  

...