English
中文 
每个计算机系毕业的人，大都学过不少数学课，而且不少学校的计算机系的数学课，通常比一般的其他工科专业的数学要难一些，比如不上高等数学，而是学数学分析，不上线性代数而去上高等代数。但是，大部分毕业了后去做程序员的人，即使是所谓的名校计算机系毕业的，大都工作中也基本完全用不上学的那些数学，基本上，一半时间在CRUD，另一半时间在处理各类字符串、链表、Hash表，知道在面试中回答各种排序的时间复杂度是他们需要的数学的上线了。
而在念书的时候，虽然上大学之前，有不少内行的外行的，年老的年轻的人告诉你，数学很重要啊。但是，通常来说，各个学校的计算机系的同学么，爱好学习的，可能重视的也是《Thinking in Java》，《C++ Primer》之类的语言书，或者设计模式之类的架构书，抑或是算法与数据结构这些玩意儿；而像我这样天天偷懒放羊的，也不会把数学当作是什么重要的课程好好学习。所以，“数学真重要”，这句话，似乎对于大家来说，始终只是飘在天上的一句话，随风飘逝了。
于是，五年过去了，程序员们都有了不少的工作经验了，如果不是对工作毫无追求混吃等死的程序员的话，对于天天干活的语言，不论是Java还是C++应该都熟能生巧了，所谓的设计模式、重构、自动化测试等等也手到擒来了，大部分人的title上都加上了Senior了，牛一点的后面大概还跟上了一个Manager，然而，大家都开始考虑一个新的问题 — — “30岁以后怎么半？”。于是，转PM的转PM，考公务员的考公务员，像我这样仍然抱定 — — “你看人家美国Rohit都50了还不是天天写程序，别人想请还请不到的”的单纯想法的人越来越少了。然后，就算这些人，时不时也会觉得，自己天天干的超越CRUD的，所谓写点OO的框架，不也是很无聊的体力活么，写程序的人干两年谁都会干。于是，又有不少人下海创业了，多年以后，这些人中的大部分都会和我一样悲催的没有挣到前继续回来给大大小小的公司写程序。
其实，杯具往往发生在一开始，其实，要是咱们当年好好学习，才会发现，也许数学对于你当个不错的程序员来说，没那么重要，但是要再往上走一步，有一点点技术上的创新，就都是数学的事儿了。两年前，我在T公司，用Configurator处理某个程序的时候，开始有点儿意识到这一点了，于是，那阵子还花了不少时间重新翻了翻数理逻辑。今年，换了新工作后为了工作看点儿机器学习的东西的时候，终于发现，这全都是数学啊。当你要超越CRUD，做任何一点点有创新性的技术的时候（不说产品），最有机会遇到的问题，其实是数学问题。虽然从Spring到Hibernate到Rails之类的框架，或者Hadoop，HBase之类的分布式计算框架，也都是技术上的重大革新，但是这些框架类的程序，完善都是阶段性的，一旦出现后，很快都会有相应的Best Practice，又会成为熟练工种的活。而真正针对问题域的解答，反是每天都可以有些新鲜的想法、思路和方案的，这些，往往有个数学的门槛。所以如果你真是挺喜欢写程序的，而且希望自己一直能写更好玩更难的程序，总有一天，你要过了这一道坎儿。
所以我很是同意不知道是谁说的，如果你只想当个good programmer，那么数学不重要；但是如果你想当个great programmer，那么数学很重要。在你手里只有锤子的时候，你看什么东西都会是个钉子，想想你如果没有学过算法和数据结构，可能你的大部分程序需要自己写排序的话，都会是傻傻地冒泡吧，反正对于大部分程序来说，在现在这么快的PC下，这点时间差别，大部分情况下，也就是让你等程序执行测试的时候，多个倒杯水的时间。但是很多新鲜，好玩，有挑战的问题，很多数学的概念没有的话，恐怕不是多等个倒水的时间了。而如果你过了这个门槛，你又会发现，一个崭新的世界，又到了你的面前。
回过头来，我说数学重要的话，那么重要的是哪些呢？大家常说的通常是离散数学，不过最近比较热门的机器学习这个方向，我目前看到的相关资料都大量依赖于线性代数和概率论，以及一点点微积分。所以，如果你和我一样，希望做点有追求的技术工作的话，开始花点时间学习数学吧。其实万事开头难，也许你和我一样，对着一堆公式符号，感到头晕眼花，但是如果真得按下心来，看上一个小时，这么坚持个一周，其实就会发现，这没啥难的，就当学门新的编程语言得了。
海之评：
学好数学，无疑是很重要的。学好数学和英语，未必是掌握好编程的充要条件，但一定是必要条件。
鼓励孩子学好数学，需要他们的早日自觉，更需要大人们的传帮带。孩子们上学时没有学好数学，往往是大人的责任，因为孩子们上学的时候大都不懂得这个道理。
当然，孩子们毕业后也可以自学。
IIS可以设置定时自动回收，默认回收是1740分钟，也就是29小时。IIS自动回收相当于服务器IIS重启，应用程序池内存清空，所有数据被清除，相当于IIS重启，在快速开发平台服务器端，为了减小数据库负担，内存中暂存了很多信息，不适合频繁的回收，因为回收会造成服务器端所有存在内存中的数据丢失，如果没有及时保存到数据库中，可能导致程序出现问题。而如果系统使用高峰时期，并不适合回收，回收可能导致几十秒IIS无响应，对于正在工作的人员来说，是一种很不好的体验，会以为是网络或者掉线等问题。因此，基于以上的分析，我们需要设置IIS在指定的时间内定时回收。
快速开发平台服务端需要正确的配置IIS(Internet Information Service)才能保证服务端可靠、稳定的运行，以给客户提供更好的用户体验。IIS为保护服务器资源，有一个应用程序池的回收功能，并且已经默认设置1740分钟回收一次（29小时），为了更好的设置该属性，我们有必要对IIS回收功能设置进行掌握，并根据应用的实际情况配合调整，以达到系统运行的最佳效果。
IIS应用程序池回收，找到相应的应用程序池并点击高级设置，就可以看到回收的相关设置（本文以windows2008R2下的IIS7为例，Windows2012类似）。
(图1)
发生配置更改时禁止回收：如果为True,应用程序池在发生配置更改时将不会回收。
固定时间间隔（分钟）：超过设置的时间后，应用程序池回收，为0意味着应用程序池不会按固定间隔回收。系统默认设置的时间是1740（29小时）。
禁用重叠回收：如果为true，将发生应用程序池回收，以便在创建另一个工作进程之前退出现有工作进程。
请求限制：应用程序池在回收之前可以处理的最大请求数。如果值为0，则表示应用程序池可以处理的请求数没有限制。
生成回收事件日志条目：每发生一次指定的回收事件时便产生一个事件日志条目，里面的明细设置不一一介绍。
根据平台服务端配置情况看，IIS默认设置的1740分钟回收进程的策略并不合理，因为每1740分钟回收，在过程中可能就处于用户使用系统的高峰时段，为避免可能在高峰时段引起非可控问题，我们建议在每周六深夜（例如晚上1点，2点）进行IIS回收。
如果我们在IIS应用程序池的高级设置中，进行回收设置，那么只有两种方式进行，一种是固定时间间隔，一种是手动回收。固定时间间隔设置，并不太好在深夜设置，以保证每周周六深夜执行回收。我们推荐采用windows “任务计划程序”配置一个操作系统定时任务执行脚本程序来实现IIS回收，设置方便，也可以灵活调整。 要通过脚本执行IIS的功能，需要在IIS安装配置的时候，勾选上管理工具中的“IIS管理脚本和工具”（见下图）。
用vbs脚本及批处理文件，结合任务计划程序，保证在每周六深夜1点执行IIS回收。
|
Recyclepool.vbs 文件内容： appPoolName = WScript.Arguments(0) Set oWebAdmin = GetObject("winmgmts:root\WebAdministration") Set oAppPool = oWebAdmin.Get("ApplicationPool.Name='" + appPoolName + "'") oAppPool.Recycle set fso=createobject("scripting.filesystemobject") if (fso.fileexists("d:\appPool\recycleIISPool.log")) then '1-forreading，2-forwriting，8-appending set file=fso.opentextfile("d:\appPool\recycleIISPool.log",8,ture) else set file=fso.createtextfile( "d:\appPool\recycleIISPool.log",8,ture) end if 'write(x)写入x个字符，writeline写入换行，writeblanklines(n)写入N个空行 file.writeline now&" 应用程序池“"&appPoolName &"”已经回收成功。" file.close |
|
Recyclepool.bat文件内容： cscript D:\appPool\recyclepool.vbs platweb |
用vbs脚本及批处理文件，结合任务计划程序，保证在每周六深夜1点执行IIS回收。
成功用windows计划任务解决IIS定时回收问题。
公司的网站经常出现不能正常访问的情况，查找IIS的错误日志（C:\WINDOWS\system32\LogFiles\HTTPERR\httperr1.log）后发现，日志文件中大部分记录的信息都是：Timer_ConnectionIdle。
站点代码（站点用C#开发）中添加的记录错误日志的文件中出现的错误如下：
at System.Threading.Thread.AbortInternal()
at System.Threading.Thread.Abort(Object stateInfo)
at System.Web.HttpResponse.End()
at System.Web.HttpResponse.Redirect(String url, Boolean endResponse)
at System.Web.HttpResponse.Redirect(String url)
Thread was being aborted.
========================================================================================
System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open()
at CAccessDataClass.Open()
刚开始的解决办法都是重启IIS服务，网站恢复正常运行。
可后来问题频繁出现，甚至有时一天出现10几次以上，并且发现当w3wp.exe进程占用内存过多时，网站就会无法访问。
通过查找资料得出如下结论：
w3wp.exe进程是IIS中网站使用的应用程序池对应的进程。只要网站被访问就会在web服务器上启动一个网站的应用程序池对应的进程。
IIS6.0应用程序池回收和工作进程的相关介绍如下：
应用程序池是将一个或多个应用程序链接到一个或多个工作进程集合的配置。因为应用程序池中的应用程序与其他应用程序被工作进程边界分隔，所以某个应用程序池中的应用程序不会受到其他应用程序池中应用程序所产生的问题的影响。
为Web程序配置应用程序池需要以下步骤：1)创建应用程序池，右键单击“应用程序池”，“新建/应用程序池”，命名为KefuAppPool;2)为Web程序指定应用程序池，在网站虚拟目录属性“应用程序设置”里面的“应用程序池(N)”里选择KefuAppPool;3)应用程序池自动回收方式的设置。回收方式有如下几种：
a.根据运行时间
系统默认是1740分钟,也就是29个小时,这个不是很好控制,建议不用。
b.请求数目
这个要看具体的情况了。如果只有10个请求，可是有5个都在请求那个比较占资源的页面(可能是统计年度报表之类)，这个时候就会出现进程当掉的情况，如果请求有1000个可是一个也没运行比较占资源的页面，这个时候进程肯定是很正常的，所以根据请求的数目来决定也不一定符合实际需要。
c.计划的时间
这个其实很好，不过具体什么时间回收好呢?通常我们都是设置在凌晨两三点钟，这个时候回收是有必要的，不过针对出现随时可能出现是高内存占用并不是很适用。
d.内存(虚拟内存或已使用的内存)
这个针对出现内存问题引起的进程当掉实在太合适了，不过设置多大的值比较好是一个很重要的问题，值不能太小了，否则如果访问量都很大超过这个值的时候也会自动回收，这个就很没必要了。一定要多多观察进程的实际占用情况再做决定。
下面重点谈谈对工作进程回收应用程序池的理解。
默认情况下，WWW服务建立“重叠回收”，即继续运行要终止的工作进程，直到启动新的工作进程后为止。 在重叠回收方案中，要回收的进程继续处理请求，同时 WWW 服务创建一个替代工作进程。在停止旧工作进程之前启动新的工作进程，然后将请求定向到新的进程。此设计可以防止服务中断，因为旧进程关闭前仍然保持与 HTTP.sys 的通信以处理请求。因为可重叠关闭或启动的关闭超时值是可以配置的，所以在工作进程仍在处理请求的同时可以终止该进程(如果它在时间限制内没有处理完请求的话)。
注意：当 WWW 服务回收某个工作进程时，它并不断开现有的 TCP/IP 连接。HTTP 协议堆栈 (HTTP.sys) 建立并维护 TCP/IP 连接。
IIS中的每个应用程序池由一个“工作进程”进行管理，也就是"W3wp.exe" 进程。如果有多个应用程序池中的程序运行，我们就能看到多个w3wp.exe。这点可以在任务管理器中看到，如下图所示，任务管理器中有两个w3wp.exe进程，恰好对应两个有应用程序在运行的应用程序池。
在命令提示符下运行iisapp -a，可以查看w3wp.exe和哪个应用程序池关联。
下图显示了手动执行应用程序池KefuAppPool的回收，在回收前，回收中和回收后应用程序池和工作进程情况。我们注意到：回收过程中增加了一个工作进程(PID=3896)，该工作进程(PID=3896)启动好后，旧的工作进程(PID=5716)才被停止，新工作进程(PID=3896)正式替代旧进程工作，这就很好的防止了应用程序池回收过程中服务被中断，保证了程序的连续运行。而其他两个应用程序池对应的工作进程 PID都没用变。该图很好的展示了应用程序池回收的过程。
应用程序池这个东西着实让管理服务器的人头疼，如果不设置好网站随时有可能罢工，甚至拖累服务器。因此特地找来此文章供大家参考。
另外说一点,如果网站访问量不是很大，晚上没什么人访问，可以尝试凌晨重启服务器，这样可以提高服务器的速度，为第二天的访问做准备。
IIS 6的核心在于工作进程隔离模式，而应用程序池则是定义工作进程如何进行工作，因此，可以说应用程序池是整个IIS 6的核心。
和IIS 5中只能使用单个应用程序池不同，工作在工作进程隔离模式的IIS 6可以创建多个应用程序池，不同的应用程序池之间是完全隔离的，某个应用程序池停止服务时不会影响到其他应用程序池。
在使用应用程序池之前，你应该确定你所需要的应用程序池数量。可能有很多朋友会认为，既然不同的应用程序池之间是完全隔离的，那么我只需要为每个Web站点创建一个应用程序池就可以了。这个办法在IIS服务器上具有较少的Web站点数量时可以使用，但是如果IIS服务器上具有很多Web站点数量，那么这个办法就不适用了，因为不同的应用程序池在被访问时都会创建各自的工作进程，当大量的工作进程并发工作时会消耗大量的系统资源和CPU利用率，反而会降低服务器性能。你应该根据Web站点的重要性、隔离性、所运行代码的安全性和稳定性等来对IIS服务器上所具有的Web站点进行划分，然后根据情况来决定所需要的应用程序池数量。对于那些非常重要的Web站点、需要单独隔离的Web站点、所运行代码稳定性和安全性并不可靠的Web站点配置为使用各自独立的应用程序池，而将其他普通的Web站点配置为使用一个公共的应用程序池。
默认情况下，在安装IIS时会创建一个默认网站并创建一个名为DefaultAppPool的应用程序池为其使用;默认配置下的应用程序池已经可以很好的进行工作，建议你只有在特别需要时才对应用程序池进行配置。
配置应用程序池属性
在IIS管理控制台中展开应用程序池文件夹，然后右击对应的应用程序池，点击属性，你可以在应用程序池的属性中进行以下配置：
回收
在回收标签，你可以设置工作进程的回收方式：
回收工作进程(分钟)：在工作进程运行多少分钟后回收工作进程，默认启用，并且设置为1740分钟(29小时);
回收工作进程(请求数目)：在工作进程处理多少 个HTTP请求后终止此工作进程，默认禁用，如果启用则默认值为35000;
在下列时间回收工作进程：在指定的时间回收工作进程，默认禁用;如需启用，勾选后点击添加按钮添加回收的时间即可，使用24小时制定义回收的时间;
消耗太多内存时回收工作进程：
最大虚拟内存(兆)：当工作进程使用的虚拟内存达到设置的值时回收工作进程，默认禁用，如果启用则默认值为500 M;建议设置为不超过虚拟内存总数的70%;
最大使用的内存(兆)：当工作进程使用的物理内存达到设置的值时回收工作进程，默认禁用，如果启用则默认值为192 M;建议设置为不超过物理内存总数的60%;
另外需要注意的是，应用程序池具有以下两种工作进程回收方式，不过这两种回收方式均不会造成Web服务的中断：
默认情况下，应用程序池使用重叠回收方式。在这种方式下，当应用程序池要关闭某个工作进程时，会先创建一个工作进程，直到新的工作进程成功创建后才关闭旧的工作进程;
应用程序池也可以先关闭旧的工作进程，然后再创建新的工作进程。
如果Web 应用程序不支持多实例运行，那么你必须配置应用程序池禁止使用重叠回收方式。此配置无法在IIS管理控制台中进行修改，只能通过在 metabase.xml中修改对应应用程序池的DisallowOverlappingRotation metabase属性为true进行。
性能
在性能标签你可以设置工作进程的运行方式：
在空闲此段时间后关闭工作进程(分钟)：当工作进程空闲多少分钟后关闭此工作进程，这降低了空闲工作进程对系统资源和CPU性能的消耗，默认启用并且设置为20分钟;
核心请求队列限制为(请求次数)：当HTTP.sys接收到某个客户端发送的HTTP请求时，如果处理此请求的对应应用程序池的工作进程还处于忙状态，则HTTP.sys将接收到的请求保存在对应应用程序池的请求队列中，直到工作进程空闲为止。此选项即用于设置此应用程序池的请求队列所能容纳的请求数量，默认情况下每个应用程序池的请求队列限制为保留1000个请求，如果超出则向客户端返回503错误，你可以根据需要适当进行修改，最大可以设置为65535。但是如果设置太大则会消耗大量的系统资源 ，而设置太小会导致客户端访问时频繁出现503错误。
启用CPU监视：监视此应用程序池的CPU使用率，默认未启用;如果某个应用程序池占用的CPU利用率过多，那么可以通过配置此选项来限制此应用程序池;
最大CPU使用率(百分比)：所设置的应用程序池所能使用的最大CPU使用率;启用CPU监视时默认值为100;
刷新CPU使用率(分钟)：刷新CPU使用率的间隔时间;启用CPU监视时默认值为5;
CPU使用率超过最大使用率时执行的操作：当此应用程序池的CPU使用率超过所设置的最大CPU使用率时所进行的操作，启用CPU监视时默认为无，此时IIS只是在事件日志中进行记录而不进行其他操作;如果选择为关闭，那么IIS将关闭此应用程序池中的所有工作进程;
Web园：在Web园中你可以配置此应用程序池所使用的最大工作进程数，默认为1，最大可以设置为4000000; 配置使用多个工作进程可以提高该应用程序池处理请求的性能，但是在设置为使用多个工作进程之前，请考虑以下两点：
每一个工作进程都会消耗系统资源和CPU占用率;太多的工作进程会导致系统资源和CPU利用率的急剧消耗;
每一个工作进程都具有自己的状态数据，如果Web应用程序依赖于工作进程保存状态数据，那么可能不支持使用多个工作进程。
运行状况
在运行状况标签你可以配置应用程序池监视工作进程的运行状况，
启用Ping：默认情况下应用程序池配置为每隔30秒Ping工作进程，当工作进程没有进行响应时，则认为此工作进程出现故障并默认配置为关闭此工作进程。你可以修改Ping的时间间隔，但是太长的Ping间隔可能会导致Web服务的中断，而太短的Ping间隔又会消耗更多的系统资源和CPU利用率，因此建议你保留默认配置;
启用快速失败保护：如果Web应用程序代码编写有问题，它可能会导致工作进程持续出现问题。默认情况下应用程序池配置为启用快速失败保护，当工作进程在配置的时间段(默认为5分钟)内发生的失败次数超过了配置的值(默认为5次)，则禁用此应用程序池。
启动时间限制：IIS等待属于此应用程序池的工作进程启动的时间，当工作进程启用时间超出此设置值时，IIS会在事件日志中进行记录;
关闭时间限制：当IIS检测到某个工作进程出现故障时，将此工作进程标记为关闭，此选项指定了IIS等待工作进程自动关闭的时间限制，如果超出此时间限制后工作进程尚未关闭，则IIS强行关闭工作进程。
标识
在标识标签，你可以配置工作进程所运行的用户账户。在IIS 5或者当IIS 6运行在IIS 5隔离模式时，工作进程运行在本地系统账户，而运行在工作进程隔离模式下的IIS 6的工作进程运行在网络服务账户下，这降低了系统被攻击的可能性。
你可以配置工作进程运行在预定义的本地系统、本地服务或网络服务账户下，也可以配置为使用某个自定义的用户账户。建议使用默认的网络服务账户;不过如果为了更高的安全性，可以配置使用自定义的用户账户，不过建议你只是将此自定义用户加入到IIS_WPG用户组中，因此IIS_WPG用户组包含了可以启动和运行工作进程的最小权限。
1)在任务管理器中增加显示pid字段;2)在命令提示符下运行iisapp -a。注意，第一次运行，会提示没有js支持，点击确定。然后再次运行就可以了。这样就可以看到pid对应的应用程序池。如上图左侧所示，应用程序池 KefuAppPool和PID=3232的w3wp.exe相关联，应用程序池ReportServer和PID=3572的w3wp.exe相关联.
