什么要平行？什么会让我变得更好？ （.net Web 业务应用程序、MVC+SL）
我正在开发一个Web应用程序框架，它使用MSSQL进行数据存储，主要只执行CRUD操作（但在任意复杂的结构上），为丰富的Silverlight管理提供WCF接口，并具有MVC3显示（以及一些基本形式，例如用户设置等）。
它非常擅长以用户友好的方式加载、显示、编辑和保存任何（相当）复杂的数据结构。
但是，我展望未来，并希望扩展我的能力（并且一路上学习新事物也会很有趣......） - 所以我决定（鉴于 C 的未来） #5...) 尝试获得一些并行/异步优化...现在，我什至还没有学习 TPL 和 PLinq，所以我也很高兴获得任何建议。
所以我的问题是，并行处理可能在哪些领域提供帮助，TPL 和 PLinq 在哪些方面可以帮助我？
我的直觉告诉我，我可以尝试以并行方式将数据结构的分支保存到数据库（这是我期望最大性能优化的地方），我可以执行一些复杂的操作（文件上传，邮件发送也许？）我可以在客户端并行构建复杂的 SL UI 视图吗？ （在视图上创建 60 个数据绑定字段可能会导致“闪烁”...）我可以在 MVC 中立即创建部分视图（菜单、类别树、搜索表单等）吗？
ps：如果这变成“告诉我有关并行事物的一切”主题，我很高兴将其设为社区维基......
I'm working on a web application framework, which uses MSSQL for data storage, mostly just does CRUD operations (but on arbitrarly complex structures), provides a WCF interface for rich Silverlight admin and has an MVC3 display (and some basic forms like user settings, etc).
It's getting quite good at being able to load, display, edit and save any (reasonably) complex data structure, in a user-friendly way.
But, I'm looking towards the future, and want to expand my capabilities (and it would be fun to learn new things along the way as well...) - so I've decided (in the light of what's coming for C#5...) to try to get some parallel/async optimalization... Now, I haven't even learned TPL and PLinq yet, so I'm happy for any advice there as well.
So my question is, what are possible areas where parallel processing maybe of help, and where does TPL and PLinq help me on that?
My guts tell me, I could try saving branches of a data structure in a parallel way to the database (this is where I'd expect the biggest peformance optimalization), I could perform some complex operations (file upload, mail sending maybe?) in a multithreaded enviroment, etc. Can I build complex SL UI views in parallel on the client? (Creating 60 data-bound fields on a view can cause "blinking"...) Can I create partial views (menus, category trees, search forms, etc) in MVC at once?
ps: If this turns into "Tell me everything about parallel stuffs" thread, I'm happy to make it community-wiki...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
请记住，无论如何，asp.net Web 应用程序本质上都是并行应用程序。请求可以并行处理，这一切都将由 ASP.NET 框架管理。因此有两种情况：
您有很多用户同时访问该网站。在这种情况下，服务器的并行处理能力可能已被充分利用。
您不会有大量用户同时访问该网站。在这种情况下，服务器可能完全有能力处理响应，而无需在适当的快速响应时间内进行并行处理。
任何时候，只要你开始考虑优化某些东西，只是因为它可能很有趣，或者只是因为你认为你应该让东西变得更快，那么你几乎肯定犯了过早优化的罪责。几乎可以肯定，您的努力最好花在丰富框架的功能上，而不是让可能足够快的解决方案变得更快一点（以显着增加复杂性为代价）。
回答 TPL 和 PLINQ 真正能在哪些方面提供帮助的问题。在我看来，这些技术的主要优点在于应用程序中确实存在大量长时间运行的阻塞进程的地方。例如，如果您多次调用外部 Web 服务，那么并行进行这些调用可能会带来显着的优势。我强烈质疑写入本地数据库 - 甚至本地网络上不同盒子上的数据库是否会被视为长时间运行的阻塞过程，以至于这种并行化具有任何重要价值。
您列出的几乎所有示例都属于让 PC 并行执行之前按顺序执行的操作的类别。您的服务器上有多少个 CPU - 当网站负载较大时，有多少个 CPU 真正空闲。使某些东西并行并不一定等于使其更快，除非所涉及的过程有一定的时间，而您的 PC 则无所事事地等待外部事件。
Remember that an asp.net web application is intrinsically a parallel application in any case. Requests can be serviced in parallel and this will all be managed by the asp.net framework. So there are two cases:
You have lots of users all hitting the site at once. In which case the parallel processing capability of the server is probably being used to capacity in any case.
You don't have lots of users all hitting the site at once. In which case the server is probably quite capable of dealing with the responses without parallel processing in a suitable fast response time.
Any time you start thinking about optimising something just because it might be fun, or because you just think you should make stuff faster then you are almost certainly guilty of premature optimization. Your efforts could almost certainly be better spent enriching the functionality of the framework, rather than making what is probably a plenty fast enough solution a little bit faster (at the cost of significantly increase complexity).
In answer to the question of where can TPL and PLINQ really help. In my opinion the main advantage of these technologies is in places in the application where you really do have a lot of long running blocking processes. For example if you have a situation where you call out several times to an external web service - it can be a significant advantage to make these calls in parallel. I would strongly question whether writing to a local database - or even a database on a different box on a local network would count as being a long running blocking process to the extent that this kind of parallelisation is of any significant value.
Pretty much all the examples you list fall in to the category of getting the PC to do something in parallel that it was previously doing in sequence. How many CPUs are on your server - how many are really free when the website is under load. Making something parallel does not necessarily equate to making it faster unless the process involved has some measure of time when you PC is sitting around doing nothing waiting for an external event.
第一个问题是询问用户/测试人员哪些部分看起来很慢。确定是什么拖慢了你的速度的唯一方法是使用像 dottrace 这样的分析器。结果有时令人惊讶。
如果您确实发现了什么，并行处理可能不是答案。您需要记住，拆分任务会产生开销，因此如果任务一开始就相当快，那么最终可能会变慢。您还必须考虑增加的复杂性，例如，如果一半任务成功，一半失败，会发生什么？ （尽管 TPL 和 PLINQ 在一定程度上隐藏了您）
玩得开心，但我想知道这是否是 1）解决问题的情况，以及 2）过早优化的情况。
First question is to ask the users / testers which bits seem slow. The only way to know for sure what's slowing you down is to use a profiler like dottrace. The results are sometimes surprising.
If you do find something, parallel processing may not be the answer. You need to remember that there is an overhead in splitting tasks up, so if the task is fairly quick in the first place, it could end up being slower. You also have to consider the added complexity, e.g. what happens if half a task succeeds, and half fails? (Although TPL and PLINQ hide you from this to an extend)
Have fun, but I wondering whether this is a case of 1) solution chasing a problem, and 2) premature optimization.