As mentioned
earlier, the UMS was designed to work with workers running on either threads or
fibers. Windows fibers have less overhead associated with them than threads do,
and multiple fibers can run on a single thread.
You can configure SQL Server to run in fiber mode by setting the Lightweight Pooling option to 1. Although using less overhead and a “lightweight” mechanism sounds like a good idea, you should evaluate the use of fi bers carefully.
Certain components of SQL Server don’t
work, or don’t work well, when SQL Server runs in fiber mode. These components
include SQLMail and SQLXML. Other components, such as heterogeneous and CLR
queries, are not supported at all in fiber mode because they need certain
thread-specific facilities provided by Windows.
Although it is possible for SQL
Server to switch to thread mode to process requests that need it, the overhead
might be greater than the overhead of using threads exclusively. Fiber mode was
actually intended just for special niche situations in which SQL Server reaches
a limit in scalability due to spending too much time switching between thread
contexts or switching between user mode and kernel mode. In most environments, the
performance benefit gained by fibers is quite small compared to the benefits you
can get by tuning in other areas. If you’re certain you have a situation that
could benefit from fibers, be sure to test thoroughly before you set the option
on a production server.
