Configuring Koo for maximum performance
Albert Cervera i Areny 18 de gen. 2010
There's nothing new in this blog post but it will be useful to anyone who wants to try or deploy Koo.
In order to make Koo fly you'll need two server modules: pyro and koo. Let's see how they can be installed and how should be configured for best results:
pyro
The pyro module is very easy to use. You may download it from the usual location and once in your server, you just need to install it in a given database. From there on, each time you start that database the pyro protocol will be available on port 8071. It's important to note that you need to start the server with that database in order for pyro to be available so you'll need something like this:
./openerp-server.py -d "database_with_pyro_installed"
If you don't do that, you'll need to login to the database with another protocol, for the service to be available.
It is possible to change the port where the module listens to by adding "pyroport = 4500" to the OpenERP server config file.
Installing this module and using it in Koo (you need to specify the protocol with the "Change" button in the login dialog) will by itself give an important performance boost. Specially true on slow networks, or better said, with those with a big delay, such as ADSL or 3G. If you work in a LAN it's also worth using it, even you don't suffer performance problems because it will give users a noticeable sense of immediateness.
koo
Just like pyro, koo module may be downloaded from here. Just by installing the module, with no configuration, Koo already benefits from it. Let me explain:
In some cases users may try to sort a list view with a field by which it can not be sorted, simply because it's a functional field that does not exist in the database. Koo has no way of knowing that in advance without the koo module, and will simply try to sort. When it will receive the exception from the server it will be ignored and notify the user that she cannot sort by that field. The problem is that current OpenERP versions tend to take a lot of time when they throw an exception and this can make Koo unusable in some circumstances. So, yes, remember, at least to install the module if you intend to use the Koo client.
Another advantage you'll get simply by installing the module is storage of view settings on a per user basis. This basically means that if you change columns order or width in a list view, or the location to open a file in a binary field, or even receive cookies browsing the web using an embedded web field, that information is kept on the server and will be reloaded when you open the view again.
But this blog post was about Koo performance so let's see how one can tune Koo to be much faster. For that you'll need to create a new entry in the Koo Settings dialog you may find at "Administration -> Configuration -> Koo -> Settings"
Koo Settings Dialog
If you're worried about performance you'll surely want to "Allow Client Caching". This will let Koo keep views, actions and other stuff in memory so the server is only queried once. In "Administration -> Configuration -> Koo -> View Cache Exceptions" you can configure which views you don't want to be cached. This may be interesting in some cases because there are views that can be altered by user input and you may want to avoid them the need to click "User -> Clear Cache" each time they make a change the the given view. This is the case, of the partner view, in which users can change available company or contact titles in "Partners -> Configuration -> Titles". This really depends on your needs, and we don't usually add any exceptions because the performance gain of cached views is quite important.
Another setting you may want to tweak is the "Limit". With it you're telling Koo how many records it should load at once. In some cases (list views with fields that are slow to process, for example) you can see improvements by lowering that number. Also remember you don't want to make that value less than the number of rows that fit in screen because that will make two server calls each time you open a list view which will worsen the problem instead of improving it. The default value is 80.
In some cases you may want to set "Sorting Mode" to visible items only, which will make Koo behave more like GTK client which will only load "Limit" records, instead of making all of them available to the user. I must say we never use it and one can get very good results with the default "All Items" setting.
In some cases you may also want to set "Requests refresh interval" to zero, which will disable the requests Koo does to update the status bar information.
Once you have all desired settings you'll have to assign it to one or more roles. This is something we'll probably fix in the future, but by now I recommend you to assign it to only one Role and assign that role to the user. If you created settings for your own user you'll need to re-login in order for the changes to take effect.
Hope this clarifies how to configure Koo for a production environment!
