So how to test these (you could rip the steps apart on a scientific basis, but they hold steady for practicality). Never forget that the subject and object of an observation influence each other. The bare fact of measuring the performance changes it:
- Network and native library: You use the command line interface (in Oracle a terminal like window) to execute whatever query you want to test. Record the time. You can proably automate this using a tool like STAF. This is your base line. If that is already slow, you know network and database might be the problem already (and yes: you could run the test on the DB server too eliminating the network in between too).
- JDBC and Connection pool: You don't write your own Connection Pool manager? Using a few lines of Java again from the command line will show how your VM is doing and how well the JDBC driver talks to the native libraries. You would already have a class that implements the Java LIST interface (preferably as virtual list), so you can use that as a data source later on. Heap size is a good candidate to tweak performance here
- XPages engine: You have code in one button instantiating the class you already used in the previous step and execute the same queries. This will show you the difference between "raw" Java performance and the XPages engine