The Razor execution code wasn't designed to be executed in parallel. With parallel execution, there're a few places in the standard .net code when data from HttpContext.Items collection is accessed simultaneously.
That causes some issues, for some of which we had workarounds, for others we didn't. Most reproducible issues were:
1) Simultaneous insertion to an internal hash table was causing an endless loop with 100% CPU usage for the process until it was killed.
2) Access violation exception raised in unmanaged code that was killing the worker processs.
We spend some time trying to address the seconds problem, without much success. There're also other possible behaviours we haven't reproduced, so we reached a conclusion
it is better to turn off parallelization, greatly simplifying the cost. Though palatalization was giving us a better average response time, we had to sacrifice it because of stability issues.
Those issues were reproducible on the Release build as well, the functions didn't have to be the same, just having multiple functions on the same level (or in the same placeholder) would reproduce the issue given enough tries.
That causes some issues, for some of which we had workarounds, for others we didn't. Most reproducible issues were:
1) Simultaneous insertion to an internal hash table was causing an endless loop with 100% CPU usage for the process until it was killed.
2) Access violation exception raised in unmanaged code that was killing the worker processs.
We spend some time trying to address the seconds problem, without much success. There're also other possible behaviours we haven't reproduced, so we reached a conclusion
it is better to turn off parallelization, greatly simplifying the cost. Though palatalization was giving us a better average response time, we had to sacrifice it because of stability issues.
Those issues were reproducible on the Release build as well, the functions didn't have to be the same, just having multiple functions on the same level (or in the same placeholder) would reproduce the issue given enough tries.
Just wondering if i need to tweak my production deploy based on this.Up to you, applying the fix will do no harm. Though the probability of the issue's occurrence is low.