For your first question, you should probably based all your VOs on EOs even if they are read only.
This way you'll enjoy the benefits of EO data caching in the middletier.
You can just set those VO to not allow update when this is their usage.
We document application module pooling parameters in the documentation - have a read to understand what you should set your system parameters to be.
Beyond that you should be doing load testing of your application to figure out your settings are good.
There are a lot of things you can do to tune your application for best performances:
Most important application module pooling parameter is "Referenced Pool Size (
Set this to the maximum number of concurrent users you expect to be accessing your site at the same time + 10%.
1 user session = 1 root application module, which in turn uses one database connection (if you use default am settings).
The consequence of getting this too low is a lot of system resources will be spent on activation/passivation of application modules. And if your application is not "activation safe" the users will experience "mysterious" errors.
You must also make sure that your database connection pool can support the same number of number of application modules. If not, you will get JDBC errors.
I don't understand why it is readonly in your application. It should be possible to change it.
As said earlier I suggest you set this number to the maximum number of concurrent users you expect to be accessing your site at the same time + 10%.
If you expect to have 100 concurrent users, set the value to 110.
Remember that your database connection pool must be able to support the same number of database connections at the same time.
The effect of increasing this number is that memory usage goes up. How much it goes up depends on how large your applications modules are. Many view object instances with large number of rows take up more memory than small number of view object instances, obviously.
I use JMeter to test how application behaves with maximum load.