我绝对更像是一名开发人员，而不是网络/部署专家。因此，虽然我对这些概念有相当好的整体理解（以及一些有关陷阱/限制的第一手经验），但我将依靠其他 SO 者来更彻底地审查我的输入。带着这个警告......
首先要注意的是：“网络农场”与“网络花园”不同。网络场通常是一系列（物理或虚拟）机器，通常每台机器都有唯一的 IP 地址，位于某种负载平衡器后面。大多数负载均衡器支持会话亲和性，这意味着给定用户在第一次访问该站点时将获得一台随机计算机，但在随后的每次访问中都会获得同一台计算机。因此，您的内存状态管理应该仍然可以正常工作，并且会话关联性将使给定会话很可能在其整个生命周期中使用相同的应用程序缓存。
我的理解是“网络花园”是特定于 IIS 的，本质上是在同一台机器上并行运行的网络服务器的“多个实例”。它的主要用途与网络场相同（支持更多数量的并发连接）。但是，据我所知，它不支持任何类型的会话关联。这意味着每个请求可能最终进入不同的逻辑应用程序，因此每个请求都可能使用不同的应用程序缓存。它还意味着您不能使用进程内会话处理 - 您必须使用 ASP 会话状态服务或 SQL 支持的会话配置。当我的客户转向网络花园模型时，这些都是困扰我的大事。
“首先，我并没有真正看到在 iis 服务器上分配负载的意义，因为根据我的经验，数据库查询通常是瓶颈”。 IIS 具有有限数量的可用工作线程（可配置，但仍然有限），因此只能服务有限数量的并发连接。即使每个请求都是相当快的操作，但在繁忙的网站上，有限的上限可能会导致用户体验缓慢。网络场/花园增加了并发请求的数量，即使它不能完美地解决 CPU 负载的均衡问题。
“这些事情很常见，还是我一开始就使用进程内存作为缓存是愚蠢的？”这实际上并不是一个“或”问题。是的，根据我的经验，网络农场非常常见（网络花园不太常见，但这可能只是我合作过的客户）。不管怎样，使用内存缓存并没有什么问题——它们是 ASP.NET 的一个组成部分。当然，有很多种方法会错误地使用它们并给自己带来问题 - 但这是一个更大的讨论，并且并不是真正特定于您的系统是否将部署在网络场上。
在我看来，您应该在设计系统时假设：
它们必须在网络场/花园上运行
您将具有会话亲和性
您不会具有应用程序级缓存亲和力
这当然不是分布式部署的详尽指南。但我希望它能让您更进一步了解一些农场/花园景观。
I am definitely more of a developer than a network/deployment guru. So while I have a reasonably good overall understanding of these concepts (and some firsthand experience with pitfalls/limitations), I'll rely on other SO'ers to more thoroughly vet my input. With that caveat...
First thing to be aware of: a "web farm" is different from a "web garden". A web farm is usually a series of (physical or virtual) machines, usually each with a unique IP address, behind some sort of load-balancer. Most load balancers support session-affinity, meaning a given user will get a random machine on their first hit to the site, but will get that same machine on every subsequent hit. Thus, your in-memory state-management should still work fine, and session affinity will make it very likely that a given session will use the same application cache throughout its lifespan.
My understanding is a "web garden" is specific to IIS, and is essentially "multiple instances" of the webserver running in parallel on the same machine. It serves the same primary purpose as a web farm (supporting a greater number of concurrent connections). However, to the best of my knowledge it does not support any sort of session affinity. That means each request could end up in a different logical application, and thus each could be working with a different application cache. It also means that you cannot use in-process session handling - you must go to an ASP Session State Service, or SQL-backed session configuration. Those were the big things that bit me when my client moved to a web-garden model.
"First i don't really see the point of distributing the load on the iis server as in my experience DB queries are most often the bottleneck". IIS has a finite number of worker threads available (configurable, but still finite), and can therefore only serve a finite number of simultaneous connections. Even if each request is a fairly quick operation, on busy websites, that finite ceiling can cause slow user experience. Web farms/gardens increases that number of simultaneous requests, even if it doesn't perfectly address leveling of CPU load.
"Are these sort of things common or was i stupid using the process memory as cache in the first place? " This isn't really an "or" question. Yes, in my experience, web farms are very common (web gardens less so, but that might just be the clients I've worked with). Regardless, there is nothing wrong with using memory caches - they're an integral part of ASP.NET. Of course, there's numerous ways to use them incorrectly and cause yourself problems - but that's a much larger discussion, and isn't really specific to whether or not your system will be deployed on a web farm.
IN MY OPINION, you should design your systems assuming:
they will have to run on a web farm/garden
you will have session-affinity
you will NOT have application-level-cache-affinity
This is certainly not an exhaustive guide to distributed deployment. But I hope it gets you a little closer to understanding some of the farm/garden landscape.
发布评论
评论（1）
我绝对更像是一名开发人员，而不是网络/部署专家。因此，虽然我对这些概念有相当好的整体理解（以及一些有关陷阱/限制的第一手经验），但我将依靠其他 SO 者来更彻底地审查我的输入。带着这个警告......
首先要注意的是：“网络农场”与“网络花园”不同。网络场通常是一系列（物理或虚拟）机器，通常每台机器都有唯一的 IP 地址，位于某种负载平衡器后面。大多数负载均衡器支持会话亲和性，这意味着给定用户在第一次访问该站点时将获得一台随机计算机，但在随后的每次访问中都会获得同一台计算机。因此，您的内存状态管理应该仍然可以正常工作，并且会话关联性将使给定会话很可能在其整个生命周期中使用相同的应用程序缓存。
我的理解是“网络花园”是特定于 IIS 的，本质上是在同一台机器上并行运行的网络服务器的“多个实例”。它的主要用途与网络场相同（支持更多数量的并发连接）。但是，据我所知，它不支持任何类型的会话关联。这意味着每个请求可能最终进入不同的逻辑应用程序，因此每个请求都可能使用不同的应用程序缓存。它还意味着您不能使用进程内会话处理 - 您必须使用 ASP 会话状态服务或 SQL 支持的会话配置。当我的客户转向网络花园模型时，这些都是困扰我的大事。
“首先，我并没有真正看到在 iis 服务器上分配负载的意义，因为根据我的经验，数据库查询通常是瓶颈”。 IIS 具有有限数量的可用工作线程（可配置，但仍然有限），因此只能服务有限数量的并发连接。即使每个请求都是相当快的操作，但在繁忙的网站上，有限的上限可能会导致用户体验缓慢。网络场/花园增加了并发请求的数量，即使它不能完美地解决 CPU 负载的均衡问题。
“这些事情很常见，还是我一开始就使用进程内存作为缓存是愚蠢的？”这实际上并不是一个“或”问题。是的，根据我的经验，网络农场非常常见（网络花园不太常见，但这可能只是我合作过的客户）。不管怎样，使用内存缓存并没有什么问题——它们是 ASP.NET 的一个组成部分。当然，有很多种方法会错误地使用它们并给自己带来问题 - 但这是一个更大的讨论，并且并不是真正特定于您的系统是否将部署在网络场上。
在我看来，您应该在设计系统时假设：
这当然不是分布式部署的详尽指南。但我希望它能让您更进一步了解一些农场/花园景观。
I am definitely more of a developer than a network/deployment guru. So while I have a reasonably good overall understanding of these concepts (and some firsthand experience with pitfalls/limitations), I'll rely on other SO'ers to more thoroughly vet my input. With that caveat...
First thing to be aware of: a "web farm" is different from a "web garden". A web farm is usually a series of (physical or virtual) machines, usually each with a unique IP address, behind some sort of load-balancer. Most load balancers support session-affinity, meaning a given user will get a random machine on their first hit to the site, but will get that same machine on every subsequent hit. Thus, your in-memory state-management should still work fine, and session affinity will make it very likely that a given session will use the same application cache throughout its lifespan.
My understanding is a "web garden" is specific to IIS, and is essentially "multiple instances" of the webserver running in parallel on the same machine. It serves the same primary purpose as a web farm (supporting a greater number of concurrent connections). However, to the best of my knowledge it does not support any sort of session affinity. That means each request could end up in a different logical application, and thus each could be working with a different application cache. It also means that you cannot use in-process session handling - you must go to an ASP Session State Service, or SQL-backed session configuration. Those were the big things that bit me when my client moved to a web-garden model.
"First i don't really see the point of distributing the load on the iis server as in my experience DB queries are most often the bottleneck". IIS has a finite number of worker threads available (configurable, but still finite), and can therefore only serve a finite number of simultaneous connections. Even if each request is a fairly quick operation, on busy websites, that finite ceiling can cause slow user experience. Web farms/gardens increases that number of simultaneous requests, even if it doesn't perfectly address leveling of CPU load.
"Are these sort of things common or was i stupid using the process memory as cache in the first place? " This isn't really an "or" question. Yes, in my experience, web farms are very common (web gardens less so, but that might just be the clients I've worked with). Regardless, there is nothing wrong with using memory caches - they're an integral part of ASP.NET. Of course, there's numerous ways to use them incorrectly and cause yourself problems - but that's a much larger discussion, and isn't really specific to whether or not your system will be deployed on a web farm.
IN MY OPINION, you should design your systems assuming:
This is certainly not an exhaustive guide to distributed deployment. But I hope it gets you a little closer to understanding some of the farm/garden landscape.