Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 2 commits into from
Oct 11, 2024

Conversation

jursonmo
Copy link

@jursonmo jursonmo commented Oct 3, 2024

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

@GStones
Copy link
Collaborator

GStones commented Oct 10, 2024

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

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

@hcraM41
Copy link
Collaborator

hcraM41 commented Oct 10, 2024

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

@jursonmo
Copy link
Author

jursonmo commented Oct 10, 2024

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

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

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

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

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

@GStones
Copy link
Collaborator

GStones commented Oct 10, 2024

首先肯定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模式中?这样就不需要多加一个模式

Copy link
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
Owner

Choose a reason for hiding this comment

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

Copy link
Author

Choose a reason for hiding this comment

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

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

Copy link
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
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
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
1 check passed
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