http_listener is getting slower over time on Windows about cpprestsdk

[wdx04]

The problem is caused by the concurrency runtime.
Add preprocessor definition CPPREST_FORCE_PPLX and recompile the library and the programs then the problem is gone.

[grahamreeds]

Surely though having to force pplx is a bug? There shouldn't be a memory
leak in either runtime?

Sent from my Nexus 5.
On 4 Jan 2016 2:43 a.m., "wdx04" [email protected] wrote:

Closed #46 #46.

—
Reply to this email directly or view it on GitHub
#46 (comment).

[wdx04]

From the blog article http://ib-krajewski.blogspot.hk/2015/09/casablanca-c-rest-framework-one-year.html

1. The only really big problem that hit us was the performance. The troublewas, that after a couple of thousands of file uploads or downloads, server performance tumbled into a free fall: the same basic polling which normally had taken 2-3% of the CPU time surged to 20-30% after that! That was a real show stopper at first. And of course it wasn't our code that showed up in the profiler, it was some of Casablanca internals!

   It took me about 2 weeks to investigate that, and maybe I'll write a more detailed post about it some time, but for now it suffices to say that Windows Concurrency Runtime (i.e. the native, task-based implementation of PPL) was left with an ever-growing internal list, which was sequentially scanned with each tick of the scheduler - at least in our environment of Windows 7 and Visual Studio 2013 plus an early Casablanca version (1.2.0).

   I reported it to Microsoft, and they reacted pretty quickly - the next release has been given a define (CPPREST_FORCE_PPLX) to disable Concurrency Runtime and switch over to Windows Threadpool based implementation of PPL. I got the latest version from the development branch, tested it, and voila! our performance problems vanished into thin air. We then waited for the next release (2.5.0) and when it came out, we upgraded our code to it and suddenly everything worked like a charm. BTW, for the Casablanca version for Visual Studio 2015 Windows Threadpool is the default setting (or so I was told)**.

[ChristophAlbert]

I noticed the problem of the high CPU load also with Websockets on Win32 (and VS2013), and the CPPREST_FORCE_PPLX symbol helps.
But I have a question: Does switching to Windows Threadpool have any disadvantage compared to Concurrency Runtime? Is there a reason the symbol isn't set by default?