Skip to content

Feature/dynamic bind: 增加DynamicBind工作池模式,类似于Bind工作池模式,每个连接绑定一个worker, 但不像Bind模式那样会闲置很多worker#339

Merged
aceld merged 2 commits into
aceld:masterfrom
jursonmo:feature/DynamicBind
Oct 11, 2024

Conversation

@jursonmo

@jursonmo jursonmo commented Oct 3, 2024

Copy link
Copy Markdown

具体实现: DynamicBind 模式 也是一个连接对应一个worker, 给新连接分配worker时, 优先从已初始化好的工作池里取,如果工作池里的worker已经用完了,没有空闲的worker,就动态创建一个worker绑定到每个连接。这个临时创建的worker, 会在连接断开后销毁。

@GStones

GStones commented Oct 10, 2024

Copy link
Copy Markdown
Collaborator

首先肯定Dynamic Bind 会比 Bind 模式实现方式好很多。
下面说下我的想法:

  1. Bind 模式下,服务器启动会start所有workers是不是本身就有问题?
  2. 建议把DynamicBind的优化合并到 Bind 模式里:
    • 增加配置workerMinNum 用来管理预启动的worker数量和最小worker数量
    • 服务启动只start workerMinNum 的workers

@hcraM41

hcraM41 commented Oct 10, 2024

Copy link
Copy Markdown
Collaborator

建议增加 max_idle_worker 机制,避免 worker 频繁创建和销毁的开销。

@jursonmo

jursonmo commented Oct 10, 2024

Copy link
Copy Markdown
Author

首先肯定Dynamic Bind 会比 Bind 模式实现方式好很多。 下面说下我的想法:

  1. Bind 模式下,服务器启动会start所有workers是不是本身就有问题?

  2. 建议把DynamicBind的优化合并到 Bind 模式里:

    • 增加配置workerMinNum 用来管理预启动的worker数量和最小worker数量
    • 服务启动只start workerMinNum 的workers

Dynamic Bind模式下,配置参数“WorkerPoolSize” 就是预启动的worker数量,也是worker最小数量,配置参数“MaxConn”是最大worker数量

@GStones

GStones commented Oct 10, 2024

Copy link
Copy Markdown
Collaborator

首先肯定Dynamic Bind 会比 Bind 模式实现方式好很多。 下面说下我的想法:

  1. Bind 模式下,服务器启动会start所有workers是不是本身就有问题?

  2. 建议把DynamicBind的优化合并到 Bind 模式里:

    • 增加配置workerMinNum 用来管理预启动的worker数量和最小worker数量
    • 服务启动只start workerMinNum 的workers

Dynamic Bind模式下,配置参数“WorkerPoolSize” 就是预启动的worker数量,也是worker最小数量,配置参数“MaxConn”是最大worker数量

确实可以复用 WorkerPoolSize 配置,另外考虑下是否可以把DynamicBind合并到Bind模式中?这样就不需要多加一个模式

Comment thread znet/msghandler.go

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

	handle := &MsgHandle{
		Apis:           make(map[uint32]ziface.IRouter),
		RouterSlices:   NewRouterSlices(),
		WorkerPoolSize: zconf.GlobalObject.WorkerPoolSize,
		// One worker corresponds to one queue (一个worker对应一个queue)
		TaskQueue:   make([]chan ziface.IRequest, TaskQueueLen),
		freeWorkers: freeWorkers,
		builder:     newChainBuilder(),
		// 可额外临时分配的workerID集合
		extraFreeWorkers: extraFreeWorkers,
	}

中,TaskQueue: make([]chan ziface.IRequest, TaskQueueLen), 能否做 zconf.GlobalObject.WorkerMode == zconf.WorkerModeDynamicBind 的区分,这样不会影响到之前的WorkerBind模式。

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TaskQueue 的长度 TaskQueueLen 已经有针对DynamicBind 模式的区分

Comment thread znet/msghandler.go

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image
StartOneWorker() 中,对于!ok的处理,要不也加上模式的区分,否则会不会全部的管道读取错误都会归类到当前模式worker的关闭,这个还不确定。 @jursonmo

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

一旦关闭queue,不管什么模式下,worker都应该退出的,不然一直能从queue读到一个空的request。

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aceld
aceld merged commit e442c38 into aceld:master Oct 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants