作为一款低代码开发平台，衡量其优劣很重要的一个指标就是可配置性。odoo提供了哪些可配置的功能呢，此文不做展开，留待后续专题讨论。odoo除系统启动相关的配置外，其他可配置的内容最终都依赖数据库进行持久化。所以如果不对odoo底层框架或者上层的业务逻辑处理做一些优化处理的话，那系统的性能瓶颈都将落到数据库层面。
缓存的合理运用无疑就是解决此类问题的银弹。odoo提供了缓存装饰器，只要在函数上添加该装饰器，第一次函数调用的结果将缓存在odoo应用所在服务器的内存中，之后再调用此函数时将直接返回缓存的结果。另外odoo还对缓存进行了统计分析，可以轻松查看缓存命中率。缓存装饰器及查看命中率的具体使用方法请参考odoo开发指南。在这里想说明一点，该缓存属于本地缓存，在分布式环境下，可能会因为不同的负载均衡策略，导致多个负载结点都存有相同的一份缓存，无疑对内存的使用造成了浪费。如果因为某些要求需要缓存失效的话，那还需要考虑如何实现多结点失效的问题。这些问题反映的是去中心化所带来的副作用。那有什么好的解决方案么？相信大家都会想到集中式缓存处理，想到大名鼎鼎的redis，确实如此。odoo官方没有提供这种方案，需要我们自己做扩展处理。网上也有类似的解决方案，可自行搜索。
无论是对odoo的功能实施还是二次开发，很容易陷入性能的泥潭。归根结底还是因配置化以及底层功能的高度封装导致的。odoo官方特别推出了profiler相关的工具，开发人员可以轻松识别出性能问题点。数据库作为最宝贵的资源，开发人员对于每一次数据库的交互必要性都应进行深思熟虑，能不调的就不调，能少调的就少调，多次调用能否合并一次调用。即使在内网环境中，一个最简单的sql查询，整个执行过程耗时都将达到毫秒级。之前做过一次粗略的统计，大概在4~7ms。想要写出高质量的或者有明确性能要求的代码，涉及到数据库的交互都需要精打细算。在odoo的请求响应的log中，我们可以很方便的看到本次处理中数据库的查询次数及耗时情况。
