提高 SharePoint 页面访问速度之应用池预加载
之前我的一篇文章给大家粗略的讲了一下关于 IIS应用池回收给 SharePoint 带来的访问速度的提升,
详见 http://horse87.blog.51cto.com/2633686/1895153
前几天和几位MVP一起又讨论学习了一下关于IIS应用池的回收问题,今天来给大家再铺开来讲一讲。
简单来说,我么服务器IIS中的应用程序池,可以看做是一个网站的资源边界,当网站要与系统资源发生交互的时候,实际上会通过应用程序池,再由池子去请求系统资源,分配给网站,一个网站所能使用到的系统资源可以通过池子来进行控制。
我们大家可以这样理解,网站本身是静态存在的,但是应用池是动态的。 池子里面包括了:网站所占用的进程,内存虚拟地址,会话状态等,这些内容都是保存在池子里面。通过应用池可以对一个网站进行合理的资源管控。比如,当一个网站的CPU使用达到了某个峰值,内存使用达到了某个峰值,或者到了某个请求数,就把这个应用池进行回收。
我们其实可以稍微屡一下思路,当我们访问一个网站的时候,实际上是去访问了一个IIS的网站集,这个时候IIS会通知这个池子,“现在有人来 访问你了”,然后池子会启动一个W3WP的进程,由这个进程来负责处理用户与网站的交互。在IIS ASP.NET应用程序里面, 应用程序池会要求定期做回收,要做回收的目的,其实就是为了防止一个池子过多的占用系统资源。
有时候代码没有写好,长时间不回收池子,是会导致网站进入假死状态的。因此,IIS应用池回收是一定要做的。但是回收了,也意味着之前这个池子缓存的内容,以及内存中的状态,都会被清理掉,应用程序池回收,相当于是给电脑来了一次重启,或者说是重启了IIS。
说到电脑重启,大家都知道,重启之后刚启动起来,那个速度也是很慢的,过阵子等系统后台进程都启动起来了,就好了。IIS应用程序池回收也是这个道理。为什么有时候第一次访问SharePoint会很慢,及时因为SP所在的IIS池子刚刚经过回收,W3WP进程还没有启动起来,所以第一次访问,会有一个启动W3WP进程的过程,相当于要给SharePoint重新开机一次。
SharePoint这个应用程序比较大,有很多个池子,如果按照Technet上的建议,每一个SP里面的service application 都创建一个独立的池子,那这个数量可想而知。所以有时候大家早上第一次访问,会非常的慢,就是因为后台正从休眠状态中苏醒过来,初始化W3WP这个进程。
从IIS7开始,微软就推出了集中优化的方案,用来解决应用池回收的问题。
首先,应用程序池回首之后为什么会访问慢,是因为要初始化W3WP这个进程,让它干活,所以默认情况下,一个池子回收之后,如果没人访问,W3WP是不会启动的,除非有人访问它,唤醒池子,才会启动W3WP,之后如果再有人访问,那么速度就要快一些了。
微软为了解决这个问题,推出了应用程序池和网站预加载功能。什么叫预加载呢?简单的来说,其实就是去感知应用程序池的回收,每当感知到这个池子进行了回收,那么系统会自动启动一个W3WP进程,这样相对于以前来说,就已经有很大的提高了。
话不多说,直接上图。
打开SharePoint IIS, 选择应用池,选中其中你想配置的一个池,我这里以80主站点为例,右键,高级设置
第一步,选择启动模式,为 alwaysrunning
第二步,设置IIS网站的预加载,选中主站点,选择右侧的高级设置
预加载选项,选为 启用 即可。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
我们来一起说说HTTPS中间人***与证书校验
一、前言 随着安全的普及,https通信应用越发广泛,但是由于对https不熟悉导致开发人员频繁错误的使用https,例如最常见的是未校验https证书从而导致“中间人***”,并且由于修复方案也一直是个坑,导致修复这个问题时踩各种坑,故谨以此文简单的介绍相关问题。 本文第一节主要讲述https的握手过程,第二节主要讲述常见的“https中间人***”场景,第三节主要介绍证书校验修复方案,各位看官可根据自己口味浏览。 二、HTTPS握手过程 首先来看下https的工作原理,上图大致介绍了https的握手流程,后续我们通过抓包看下每个握手包到底干了些什么神奇的事。 注:本文所有内容以TLS_RSA_WITH_AES_128_CBC_SHA加密组件作为基础进行说明,其他加密组件以及TLS版本会存在一定差异,例如TLS1.3针对移动客户端有了很大的改动,现在的ECDHE等密钥交换算法与RSA作为密钥交换算法也完全不一样,所以有些地方和大家实际操作会存在一定出入。 1.TCP三次握手 我访问的支付宝的官网www.alipay.com抓取的数据。 2.Client Hello...
- 下一篇
基于etcd+confd通过nginx对docker服务混合注册发现详解
先简单说下业务逻辑,etcd是一个分部式k/v存储系统,confd是一个对etcd的key或者目录做变化监控的软件,并配有相关语法,可以将变化的k/v处理后形成配置文件,nginx不用多说了,做docker容器的负载均衡流量调度。 在业务过程中,docker容器健康起来后,会通过接口向etcd注册相关k/v信息,confd检测到etcd的k/v变化后,立即触发程序通过模板形成新的nginx配置文件,先做离线语法测试,如果没问题就覆盖原配置,进而reload,测试不通过就不覆盖原配置,整个过程是安全可控的。在容器注册到nginx的upstream后,nginx会对容器做健康检查发现,如果正常,则分发流量过去。对应的业务流程图如下: 根据业务情况,要解决如下几个问题: 1、nginx负载均衡的混合注册,使得nginx可以混合负载多个业务; 2、不同机房如何在同一etcd集群上进行注册,如何规划; 3、confd更新频率如何周期可控制,k/v每有变化实时触发reload太敏感,况且每个容器要注册多个k/v,在整体注册完之前,是不需要reload的; 4、confd启动时如何关联多个...
相关文章
文章评论
共有0条评论来说两句吧...