分享程序员开发的那些事...
更新时间：2023-11-27 22:00:28
最需要的功能，服务器-添加了侧异步支持，其中 ServiceStack 中的 HttpHandlers 现在从实现 IHttpAsyncHandler 的公共 HttpAsyncTaskHandler 基类继承.这允许您以多种方式从您的服务返回异步任务，如 http://bit.ly/1cOJ3hR
例如服务现在可以有一个对象、Task 或 async Task 返回类型，它们可以返回一个已启动或未启动的任务(我们将自己启动).此次过渡尽可能顺利，所有现有服务继续像以前一样工作并且所有测试均通过.
为了匹配新的服务器端异步故事，现在所有项目都已升级到 .NET 4.0，所有服务客户端都已更改为为所有异步操作返回 .NET 4.0 任务，以便它们可以在 C# 的异步/等待方法.一些异步操作示例:http://bit.ly/17ps94C
异步 API 还提供 OnDownloadProgress 回调，您可以利用该回调在您的 UI 中提供进度指示器，例如:http://bit.ly/19ALXUW
异步重载也被添加到 HTTP Utils用于调用外部第 3 方(即非 ServiceStack)HTTP 服务的 API.
不确定实际测量中得出的结论是异步对于维护高性能系统是必需的，因为良好的缓存策略将提供比异步更好的性能.有许多不使用异步的高性能服务和网站，例如*** 内置 100 万行屏蔽Python 每天处理 40 亿次观看，最近 Disqus 将他们如何让 Django(一个沉重的 Python Web 框架)发布到 通过利用 HTTP 缓存扩展到 80 亿次页面浏览.对于大多数多线程站点/服务(例如 .NET/Ruby/Python)，阻塞 IO 是常态，而不是异步 - 就像所有过早的优化一样，应该衡量它是否真的产生了任何最终用户/利用率的好处.
*** 本身是一个 ASP.NET MVC 网站，它使用标准的同步 MVC 控制器并采用良好的缓存策略，利用本地和分布式缓存并利用 ServiceStack 的 JSON 序列化程序.所以即使使用同步 MVC 控制器 *** 具有非常好的服务器利用率，可以处理 9500 万次/月的页面浏览量.*** Careers 2.0 使用了 ServiceStack 及其 RedisMQ 支持所有后台操作.
A buddy of mine told me in the past he had looked at ServiceStack. Said it looked good but that it had no async support so in his book, it's not an option to use this framework (no good if no async) and I have to sorta agree.
Unless ServiceStack has added async, not sure if this is a good choice for me.
It makes me wonder a) is *** truly using this if there is no async? b) if yes to a, then it obviously must be a highly customized version of it that probably DOES have async?
I am sure someone from *** can answer this post.
The most requested feature, Server-side async support has been added where HttpHandlers in ServiceStack now inherit from a common HttpAsyncTaskHandler base class that implements IHttpAsyncHandler. This lets you return an async Task from your Service in any number of ways as shown in http://bit.ly/1cOJ3hR
E.g. Services can now have either an object, Task or async Task return types that can return a started or non-started task (which we'll start ourselves). This transition went as smooth as it could where all existing services continuing to work as before and all tests passing.
In matching the new server-side async story and now that all projects have been upgraded to .NET 4.0, all Service Clients have been changed to return .NET 4.0 Task's for all async operations so they can be used in C#'s async/await methods. Some examples of Async in action: http://bit.ly/17ps94C
The Async API's also provide a OnDownloadProgress callback which you can tap into to provide a progress indicator in your UI, E.g: http://bit.ly/19ALXUW
Async overloads have also been added to HTTP Utils which provides a nice API for calling external 3rd Party (i.e. non-ServiceStack) HTTP Services.
Not sure what real-world measurements has led to the conclusion that Async is mandatory for maintaining a high-performance system, given a good caching strategy will provide better performance than Async can. There are a number of high-performance services and websites that doesn't use async, e.g. *** is built with 1M lines of blocking Python to handle 4 Billion views a day, more recently Disqus posts how they got Django (a heavy Python Web framework) to scale to 8 billion page views by leveraging HTTP Caching. For most multi-threaded sites/services (e.g. .NET/Ruby/Python), blocking IO is the norm, not async - which like all premature optimizations should be measured to calculate if it actually yields any end-user/utilization benefits.
*** itself is a ASP.NET MVC Website which uses the standard Synchronous MVC Controllers and employs a good caching strategy that utilizes both local and distributed caching and makes use of ServiceStack's JSON serializer. So even using synchronous MVC controllers *** has extremely good server utilization for handling 95M page views/month. *** Careers 2.0 is what uses ServiceStack and its RedisMQ support for all its BackOffice operations.