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

Implement ThreadPool for Server Threading #145

Closed
scottoffen opened this issue Nov 7, 2016 · 3 comments
Closed

Implement ThreadPool for Server Threading #145

scottoffen opened this issue Nov 7, 2016 · 3 comments
Assignees
Milestone

Comments

@scottoffen
Copy link
Owner

scottoffen commented Nov 7, 2016

Move from managing threads internally to using a thread pool.

This might help with an issue some users are seeing with CPU spikes (#138)

@scottoffen scottoffen added this to the 4.0.0.x milestone Nov 7, 2016
@scottoffen scottoffen self-assigned this Nov 7, 2016
@scottoffen scottoffen changed the title Refactor Server Threading Implement ThreadPool for Server Threading Nov 18, 2016
@Costigan
Copy link

Costigan commented Nov 20, 2016

Here are some .diagsession files generated by VS 2015's profiling tool. In all cases, my app was loaded and some initialization done, but then the only messages it received were REST requests that were effectively pings. No work was done except for responding with an string constant.

My client measures the msec per request, and this number varies. I haven't seen any regularity to it yet. The first time I profiled it, the time was 20 msec/request. That corresponds to the attached file named Report20161119-cpu-fast.diagsession. The second run was 412 msec/request. That's in Report20161119-cpu-slow.diagsession. In both cases, the profiler's CPU usage tool was used to record the data. The final file (Report20161119-memory-two-runs.diagsession) is a memory tool recording. There are two memory snapshots. One was done after app initialization but before any REST messages had been sent. The second snapshot was done after I'd run my client twice. Each time, it sent 100 requests. The first of these client runs was at 3 msec/request. The second client run (batch of 100 requests) was at 73 msec/request. (That is, the client was called twice, issuing 100 requests each time while the server was run once with the memory tool attached.) You'll note that I'm not carefully warming up the server. When it's fast, it's fine. When it's slow, it's much slower than it should be, and it doesn't seem likely that jitting or some other startup cost is relevant.

Here are the files.
https://www.dropbox.com/sh/7hagia1b3mmoc1r/AAAGIW2wS9BfSdlHjehuJwnga?dl=0

(github requires the file to have one of a limited number of extensions, and I don't know whether it checks the file itself to ensure that the extension corresponds to the file contents, so I'm using dropbox.)

@scottoffen
Copy link
Owner Author

(github requires the file to have one of a limited number of extensions, and I don't know whether it checks the file itself to ensure that the extension corresponds to the file contents, so I'm using dropbox.)

I've noticed that about github and file extensions. I typically will just add a .txt extension so that it uploads just fine, and add a note to the comment about the extensions change.

@scottoffen
Copy link
Owner Author

scottoffen commented Nov 22, 2016

The master branch is now using a ThreadPool instead of managing it's own threads. You'll see that the Connections property has been deprecated. My preliminary tests look really good, but I wanted to see how yours look before I cut a new nuget.

scottoffen pushed a commit that referenced this issue Nov 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants