许多复杂的应用需要将性能放在第一位，因为 高性能会取悦用户，提高搜索引擎排名 和 提高转化率。这篇文章中，会以一个复杂的产品展示页面为例，讲述如何将响应时间从120ms缩减了90%，到20ms。
首先，我们来看一个示例的产品页面，注意到它展示的数据类型。我们使用关系型数据库，所以所有信息都是标准化的，并且在不同的数据表中存储。因此，这个页面的大部分信息是基于商品的ID。为了渲染页面，我们需要通过商品ID查找不同表（这些查询不需要基于上次查询的结果）。我们的初始设计并没有用到ID的标准化结构，并且是顺序查找每张表。
items = Item.by_ids(ids)
seller_ids = Enum.map(items, &(&1.user_id))
user_stats = UserStats.user_stats_map(seller_ids)
favorites = Favorite.favorites_map(seller_ids)
stores = User.stores_map(seller_ids)
# more queries...
Enum.map(items, fn item ->
%{
item: item,
user_stats: Map.get(user_stats, item.selller_id),
is_favorite: Map.get(favorites, item.id),
store: Map.get(stores, item.seller_id),
# more Map.gets
}
end
)
这种做法的通常性能不会太糟，但是当其中一个查询比较慢时，其后的查询就会被拖累。在性能测试中我们发现这个endpoint的速度并不令人满意。
为了解决这个问题，我们咨询了 Chris McCord。他给了我们架构上的建议来优化这段代码。我们使用了 Task.Supervisor 来并行的执行这些查询。
首先，我们将 Task.Supervisor添加到 supervision tree 来保证我们能优雅的处理子进程的崩溃和结果。
children = [
# other children
supervisor(Task.Supervisor, [[name: TptApi.TaskSupervisor]]),
]
Supervisor.start_link(children, opts)
现在我们就可以自信的使用 Task.Supervisor.async生成进程了，让我们能够并行化原来的查询序列。
items = Item.by_ids(ids)
seller_ids = Enum.map(items, &(&1.user_id))
[]
|> get_user_stats(seller_ids)
|> get_favorites(seller_ids)
|> get_stores_by_user(seller_ids)
|> # more queries
|> Task.yield_many()
|> Enum.reduce(%{}, fn ({task, reply}, acc) ->
case reply do
{:ok, result} -> Map.merge(acc, result)
end
end)
|> generate_product_results(items)
上述代码信息量比较大，我们一行行看
[]
|> get_user_stats(seller_ids)
它首先创建了一个空列表，然后pipe到get_user_stats函数中去。 get_user_stats则会创建一个新的Task来查询数据库，并且将Task传到空列表中。下面是get_user_stats：
def get_user_stats(tasks, seller_ids)
[Task.Supervisor.async(TptApi.TaskSupervisor, fn ->
%{user_stats: UserStats.user_stats_map(seller_ids)},
end) | tasks]
end
每个pipeline中的函数功能近似，都是创建一个Task，将其添加到list，接着传递给下面。我们来看下紧接着的pipeline:
[]
|> get_user_stats(seller_ids)
|> get_favorites(seller_ids)
get_favorites创建一个新的Task并且添加到现有的Tasks列表中去。
def get_favorites(tasks, seller_ids)
[Task.Supervisor.async(TptApi.TaskSupervisor, fn ->
%{favorites: Favorite.favorites_map(seller_ids)},
end) | tasks]
end
我们在辅助函数中重复 [Task.async | tasks] ，我们还想添加错误处理和监测功能到每个Task中去。我们把重复的功能抽象到一个独立的扶助函数中去。
一旦查询数据表的Task被分发，我们需要等待所有的Task完成查询（注意：这意味着查询总时间仍然受到最慢的那个限制）。Task.yield_many 是一个优秀的解决方案，它将等待所有Task完成才继续pipeline。
一旦所有查询完成之后，我们使用Enum.reduce来汇总结果：
|> Enum.reduce(%{}, fn ({task, reply}, acc) ->
case reply do
{:ok, result} -> Map.merge(acc, result)
end
end)
查看 *Task.yield_many example * 文档来获取更多信息。
最终，我们将保存所有查询数据的 Map 给到 generate_product_results(items) ，这个函数将做一些其他小的处理来显示数据。
这种方法能让我们轻松监测Task，监测能让我们更好的发现和处理应用的性能瓶颈。这是 Grafana 的图像：
每条曲线对应了一个异步查询时间，因此，总时间约为最高的那条曲线。假如查询是序列化同步的话，那么总时间将会是所有曲线的叠加。
所有的这些性能优化都让应用提升了速度，不信你看：
此外，还有人根据这篇文章写了个库，赶紧看看吧！
