asterisk

Commit Graph

Author	SHA1	Message	Date
Joshua C. Colp	a12251ca88	pjsip: Move from threadpool to taskpool This change moves the PJSIP module from the threadpool API to the taskpool API. PJSIP-specific implementations for task usage have been removed and replaced with calls to the optimized taskpool implementations instead. The need for a pool of serializers has also been removed as taskpool inherently provides this. The default settings have also been changed to be more realistic for common usage. UpgradeNote: The threadpool_* options in pjsip.conf have now been deprecated though they continue to be read and used. They have been replaced with taskpool options that give greater control over the underlying taskpool used for PJSIP. An alembic upgrade script has been added to add these options to realtime as well.	9 months ago
Joshua C. Colp	0c49ba4478	taskpool: Add taskpool API, switch Stasis to using it. This change introduces a new API called taskpool. This is a pool of taskprocessors. It provides the following functionality: 1. Task pushing to a pool of taskprocessors 2. Synchronous tasks 3. Serializers for execution ordering of tasks 4. Growing/shrinking of number of taskprocessors in pool This functionality already exists through the combination of threadpool+taskprocessors but through investigating I determined that this carries substantial overhead for short to medium duration tasks. The threadpool uses a single queue of work, and for management of threads it involves additional tasks. I wrote taskpool to eliminate the extra overhead and management as much as possible. Instead of a single queue of work each taskprocessor has its own queue and at push time a selector chooses the taskprocessor to queue the task to. Each taskprocessor also has its own thread like normal. This spreads out the tasks immediately and reduces contention on shared resources. Using the included efficiency tests the number of tasks that can be executed per second in a taskpool is 6-12 times more than an equivalent threadpool+taskprocessor setup. Stasis has been moved over to using this new API as it is a heavy consumer of threadpool+taskprocessors and produces a lot of tasks. UpgradeNote: The threadpool_* options in stasis.conf have now been deprecated though they continue to be read and used. They have been replaced with taskpool options that give greater control over the underlying taskpool used for stasis. DeveloperNote: The taskpool API has been added for common usage of a pool of taskprocessors. It is suggested to use this API instead of the threadpool+taskprocessor approach.	12 months ago

Author

SHA1

Message

Date

Joshua C. Colp

a12251ca88

pjsip: Move from threadpool to taskpool

This change moves the PJSIP module from the threadpool API
to the taskpool API. PJSIP-specific implementations for
task usage have been removed and replaced with calls to
the optimized taskpool implementations instead. The need
for a pool of serializers has also been removed as
taskpool inherently provides this. The default settings
have also been changed to be more realistic for common
usage.

UpgradeNote: The threadpool_* options in pjsip.conf have now
been deprecated though they continue to be read and used.
They have been replaced with taskpool options that give greater
control over the underlying taskpool used for PJSIP. An alembic
upgrade script has been added to add these options to realtime
as well.

Joshua C. Colp

0c49ba4478

taskpool: Add taskpool API, switch Stasis to using it.

This change introduces a new API called taskpool. This is a pool
of taskprocessors. It provides the following functionality:

1. Task pushing to a pool of taskprocessors
2. Synchronous tasks
3. Serializers for execution ordering of tasks
4. Growing/shrinking of number of taskprocessors in pool

This functionality already exists through the combination of
threadpool+taskprocessors but through investigating I determined
that this carries substantial overhead for short to medium duration
tasks. The threadpool uses a single queue of work, and for management
of threads it involves additional tasks.

I wrote taskpool to eliminate the extra overhead and management
as much as possible. Instead of a single queue of work each
taskprocessor has its own queue and at push time a selector chooses
the taskprocessor to queue the task to. Each taskprocessor also
has its own thread like normal. This spreads out the tasks immediately
and reduces contention on shared resources.

Using the included efficiency tests the number of tasks that can be
executed per second in a taskpool is 6-12 times more than an equivalent
threadpool+taskprocessor setup.

Stasis has been moved over to using this new API as it is a heavy consumer
of threadpool+taskprocessors and produces a lot of tasks.

UpgradeNote: The threadpool_* options in stasis.conf have now been deprecated
though they continue to be read and used. They have been replaced with taskpool
options that give greater control over the underlying taskpool used for stasis.

DeveloperNote: The taskpool API has been added for common usage of a
pool of taskprocessors. It is suggested to use this API instead of the
threadpool+taskprocessor approach.

2 Commits (27f35ca2fdcccc610f5f790995fce229483e2fe9)