跳转至内容
  • 版块
  • 标签
  • 热门
  • 用户
  • 群组
皮肤
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • 默认(Flatly)
  • 不使用皮肤
折叠

Odoo 中文社区

  1. 主页
  2. 版块
  3. Odoo 安装指南
  4. OpenERP 负载平衡

OpenERP 负载平衡

已定时 已固定 已锁定 已移动 Odoo 安装指南
26 帖子 14 发布者 38.7k 浏览
  • 从旧到新
  • 从新到旧
  • 最多赞同
登录后回复
此主题已被删除。只有拥有主题管理权限的用户可以查看。
  • JoshuaJ 离线
    JoshuaJ 离线
    Joshua 管理员
    写于 最后由 编辑
    #4

    前排,占坐,感谢buke分享如此强大的文章!

    【上海先安科技】(joshua AT openerp.cn),欢迎关注公众号:openerp_cn

    1 条回复 最后回复
    0
    • C 离线
      C 离线
      ccdos
      写于 最后由 编辑
      #5

      强人。
      buke分享,必定是重量级的

      1 条回复 最后回复
      0
      • O 离线
        O 离线
        oldrev
        写于 最后由 编辑
        #6

        很厉害的呢,这种最适合弄个分支然后提交给官方合并。

        我觉得普通企业用恐怕需求不大吧,因为 OE 这类应用的瓶颈还是在 DB 上,快来人写 PostgreSQL 负载均衡和高可用文章

        1 条回复 最后回复
        0
        • W 离线
          W 离线
          wangbuke
          写于 最后由 编辑
          #7

          [quote author=oldrev link=topic=5703.msg14029#msg14029 date=1358770532]
          很厉害的呢,这种最适合弄个分支然后提交给官方合并。

          我觉得普通企业用恐怕需求不大吧,因为 OE 这类应用的瓶颈还是在 DB 上,快来人写 PostgreSQL 负载均衡和高可用文章
          [/quote]

          ;D , OpenERP s.a.  don't bird me , I don't bird OpenERP s.a. 

          1、OpenERP 官方从6.0 开始做SAAS, 他们不缺这个技术。
          2、此文不对应用场景下结论,需不需要做负载平衡,这个大家自行根据实际情况判断。
          3、PostgreSQL  的历史和口碑远胜于OE,PostgreSQL 负载均衡方案早就很成熟了,比如pgpool-II 等。

          SO ....  祝玩的开心 ~

          1 条回复 最后回复
          0
          • wjfonhandW 离线
            wjfonhandW 离线
            wjfonhand
            写于 最后由 编辑
            #8

            转载到和公司logo更贴近的地方去了。

            这篇文章是cc协议吧?

            GoodERP -- Odoo China fork

            1 条回复 最后回复
            0
            • N 离线
              N 离线
              NewZN
              写于 最后由 编辑
              #9

              好文,谢谢buke分享!如果运营SaaS模式,这个办法很好。

              我有个问题请教下:
              如果日订单平均1万单(对于某些较大的电商,这是完全可能的),一年下来就超过300万单。
              就OE和PostgreSQL而言,这个数据量的处理会有哪些瓶颈呢,有什么办法克服此瓶颈吗?

              1 条回复 最后回复
              0
              • W 离线
                W 离线
                wangbuke
                写于 最后由 编辑
                #10

                [quote author=Jeff link=topic=5703.msg14033#msg14033 date=1358780186]
                转载到和公司logo更贴近的地方去了。

                这篇文章是cc协议吧?
                [/quote]


                是,谢谢转载,欢迎转载 ~

                1 条回复 最后回复
                0
                • W 离线
                  W 离线
                  wangbuke
                  写于 最后由 编辑
                  #11

                  [quote author=NewZN link=topic=5703.msg14034#msg14034 date=1358782739]
                  好文,谢谢buke分享!如果运营SaaS模式,这个办法很好。

                  我有个问题请教下:
                  如果日订单平均1万单(对于某些较大的电商,这是完全可能的),一年下来就超过300万单。
                  就OE和PostgreSQL而言,这个数据量的处理会有哪些瓶颈呢,有什么办法克服此瓶颈吗?
                  [/quote]


                  一切不给出详细数据来谈优化和性能,都是耍流氓。

                  我这里也就纸上谈兵,空谈几句。。。

                  先说说优化原则:
                  1、[b]不要过早优化[/b]。能通过升级硬件就升级,能多机负载就搞多机。
                  2、[b]空间换时间[/b]。除了不合理的或错误的方法外,所有的优化原理上都是以空间换时间,木有之一。

                  需求分析:
                  首先,日均1万单,那峰值加一个数量级: 10万单/天
                  按照电商行业高峰期算半天:10万单/12小时 = 23单/秒
                  看起来很简单嘛,嘿嘿 ~ 且慢!订单处理就是OE的核心,可以说订单处理基本上把OE都搞了个底朝天,对数据库来说这里基本还都是事务操作,懂不懂就要锁行甚至锁表。。。

                  此外,正常运作起来的ERP,用户少不了查询、统计、报表。。。。这些也是一大块

                  按经验,这里最有可能的瓶颈就是数据库

                  数据库可能的优化:
                  1、换 ORACLE
                  2、请一个DBA
                  3、如果以上2条都没办法,先那么就考虑 PG 集群吧

                  PGPOOL-II = 负载平衡 + 读写分离 。这个配置的好,服务器不是太差的话,对付每秒几百单的需求应该都可以了

                  4、如果读写分离也搞不定,那就做sharding ,横切竖切,除了整一个DBA回来外,当然OpenERP 的DB路由、表结构都得改改了

                  5、还是搞不定? 尼玛这估计都到每秒几千单了,电商当中你都是 TOP 10 了吧,还在折腾OE? 风投的钱不花白不花啊


                  OE Server 部分可能的优化
                  前端优化的好,可以减少很多DB请求,思路也是一样,空间换时间

                  1、多机负载
                  2、缓存!缓存!缓存!一切能缓存的都给缓存了
                  3、尽可能减少实时计算
                    类似OE 的 funcion field 统统 store = True
                    OE 的 kanban view 等,把结果缓存,或多建几个冗余表放在数据库里
                    OE的列表查询,宁可翻页,也不能让客户选择分页数。
                    一些统计分组查询之类,比如月报表、周报表、日报表,放在固定时间跑批,然后放数据库或缓存
                    报表尽量在客户端渲染,或者生成之后然后缓存

                  现在能想到的大概就这么了。。。

                  总结:
                  在合理优化的前提下,使用多机负载方法,我认为是可以满足您的需求的。

                  以上罗罗嗦嗦,如果不当之处还请大家斧正。

                  1 条回复 最后回复
                  0
                  • P 离线
                    P 离线
                    paizzj
                    写于 最后由 编辑
                    #12

                    oe 6, 6.1也可以和gunicorn一起 集成,跨CPU,支持多进程模式(多个worker,不过这个参数是在gunicorn中配置),
                    从代码变迁可以看出,oe官方真是说干就干啊,oe7版本就直接借用了 gunicorn 的设计
                    附件中是,oe6.1和gunicorn配置,详细细节

                    谢谢 wangbuke的好文

                    1 条回复 最后回复
                    0
                    • P 离线
                      P 离线
                      paizzj
                      写于 最后由 编辑
                      #13

                      不好意思,附件多穿了个

                      1 条回复 最后回复
                      0
                      • K 离线
                        K 离线
                        klm2242
                        写于 最后由 编辑
                        #14

                        Thanks for your sharing

                        1 条回复 最后回复
                        0
                        • mrshellyM 离线
                          mrshellyM 离线
                          mrshelly
                          写于 最后由 编辑
                          #15

                          OE 对于数据库好象没有做 读写分离一样...

                          不知道 pgpool 怎么样玩...

                          1 条回复 最后回复
                          0
                          • W 离线
                            W 离线
                            wangbuke
                            写于 最后由 编辑
                            #16

                            对OE来说,PGPool就是透明的,不需要关心细节,PGPool 会自己处理读写分离。

                            PGPool会将需要复制的SQL发到Master数据库,不需要复制的SQL符合条件的情况下将可能被分发到Slave数据库以达到负载均衡的效果。

                            只需要配置好 PGPool ,然后将OE数据库连接改为连接PGPool即可。


                            1 条回复 最后回复
                            0
                            • W 离线
                              W 离线
                              wangbuke
                              写于 最后由 编辑
                              #17

                              PostgresStreamReplication+PGPool-II+HA集群最佳实践

                              1 条回复 最后回复
                              0
                              • mrshellyM 离线
                                mrshellyM 离线
                                mrshelly
                                写于 最后由 编辑
                                #18

                                这个必须要关注...

                                太强大的步科妹纸了....

                                1 条回复 最后回复
                                0
                                • JoshuaJ 离线
                                  JoshuaJ 离线
                                  Joshua 管理员
                                  写于 最后由 编辑
                                  #19

                                  谢谢buke分享

                                  【上海先安科技】(joshua AT openerp.cn),欢迎关注公众号:openerp_cn

                                  1 条回复 最后回复
                                  0
                                  • N 离线
                                    N 离线
                                    NewMoon
                                    写于 最后由 编辑
                                    #20

                                    太强了,先收藏!

                                    1 条回复 最后回复
                                    0
                                    • K 离线
                                      K 离线
                                      klm2242
                                      写于 最后由 编辑
                                      #21

                                      Thanks for your sharing..... 😉

                                      1 条回复 最后回复
                                      0
                                      • W 离线
                                        W 离线
                                        wangbuke
                                        写于 最后由 编辑
                                        #22

                                        [quote author=wangbuke link=topic=5703.msg14263#msg14263 date=1361510433]
                                        PostgresStreamReplication+PGPool-II+HA集群最佳实践
                                        [/quote]

                                        声明一下:

                                        PostgresStreamReplication+PGPool-II+HA集群最佳实践 非本人作品。

                                        此文档作者及联系方式

                                        萧少聪 [Scott Siu]
                                        EnterpriseDB认证讲师
                                        RHCA红帽认证架构师
                                        E-Mail: [email protected]
                                        Tel: +86 18600036141

                                        我仅转载,有需要请联系原作者。再次感谢萧少聪先生的精彩文章。

                                        1 条回复 最后回复
                                        0
                                        • W 离线
                                          W 离线
                                          wenzizone
                                          写于 最后由 编辑
                                          #23

                                          敢问楼主,odoo的所有信息都是存在postsql数据库中吗?包括上传的附件什么的???

                                          1 条回复 最后回复
                                          0

                                          • 登录

                                          • 没有帐号? 注册

                                          • 登录或注册以进行搜索。
                                          • 第一个帖子
                                            最后一个帖子
                                          0
                                          • 版块
                                          • 标签
                                          • 热门
                                          • 用户
                                          • 群组