[原创贴] 静态页生成问题（找错，排错）
前些日子，由于公司站群要重新架构，于是技术总监建议将几十个公司门户站点都换成静态页，进行静态页生成，降低服务器压力，便于SEO搜索引擎优化。
网站架构初期，由于要纳入很多功能要素，而且又只是一个人去设计数据库，所以给后期制作带来了不小的麻烦，下面我就静态页生成功能模块的问题，简单的说一下近期找错、排错的过程
1.webservice的应用问题
网站的架构模式是几十个站共用一个数据库，由一个公共的后台界面进行管理，并且对编辑进行了权限设置，不同级别的编辑人员看到的管理界面也是不同的，当然后台生成静态页并放入前台的网站目录下，这就用到了webservice，因为后台域名与网站前段的域名是不一样的，生成后的静态页是要生成到网站域名目录下的，所以我们生成静态页的第一个问题就出在了这里。代码块的过程是在后台点击生成按钮，然后获得数据集合，然后再遍历集合，循环调用webservice，也就是说，有多少个页面，就要调用多少次webservice，这就造成了频繁调用webservice引起的一些列问题：System.OutOfMemoryException 异常；操作已超时等等，最后我们发现这个问题后，就直接在后台调用一次webservice，传值过去，在前台网站获得参数，得到集合，进行循环，效果确实显著，不会报异常，内存也不会溢出~
2.反射问题
当时的代码核心（网站架构者），为了方便程序员管理模板和后期维护，利用反射机制对要替换的标签进行处理，其实说白了就是替换的函数名是什么，标签名就是什么。这确实在编写上给我们技术人员带来了方便，但是严重的问题也出在这里，在每生成一个静态页的时候，程序就要去解析标签，我们公司教育网站网页上的模块比较多，一个页有将近十多个标签需要替换，这也就意味着每次处理一个标签，反射就要实例化一次那个含有替换函数的类，而且当时的情况是，程序运行到那个类的时候，很多属性里面的值是赋好的，比如文章数据库里悲催的content字段。。。这个内容字段是ntext类型，存储文章内容，所以，整个过程就是，循环第一个页第一个标签的时候，反射机制解析标签名，参数名，然后实例化替换函数的类并给类里的属性赋值，然后再去访问数据库，得到需要的集合，再遍历。。。几千个页下来，数据库不挂就怪了，而且服务器内存也扛不住了（注：服务器8G内存，70多个网站，数据库也在上面）最后，我们在做过比较测试后，毅然决然的提出扔掉webservice和反射，用普通的replace去替换标签内容，至于静态页如何生成在网站目录下，我们用了值得怀念的iframe，因为后台有权限控制，每个人看得到的界面和管理的数据都是不一样的，所以不会产生影响或是冲突。
3.sql语句问题
当我们这些虾兵蟹将认为程序没有任何问题的时候，挂到服务器上，数据库实例悲催的挂掉的那一刻，我们凌乱了，甚至有些想吃人的感觉，这次的问题出在sql语句，因为个人习惯问题，经常在查询的时候直接写成“select * from。。。。”，这次明白了，这么**的不好，隐患太大了！还是那个悲催的content字段！差个列表也要读一遍那个超长字符串的数据，服务器数据库肯定是扛不住的，区区几千条，刚生成20多条直接卡死，最后我们检查了整个项目的数据访问层的sql语句，将其更正。
4.总监想方设法的省钱问题。。。
（硬件问题）
我并不是在抱怨什么，可是如果说硬件设施跟不上，代码写的再好也是扯淡！我们将上面的三个问题解决后，在服务器上运行依然是20多条卡死，这次我真的没有辄了，于是我们请教了技术总监，当他带着怀疑和不屑的态度进行测试后，告诉我们，是该申请个服务器的时候了。。。
经历了这次排错，我对生成静态页有了不少的了解，也学到了不少平常用不到的知识，总之咱们做程序员的，要做的就是将自己的代码写到最好，其余的事情让事实去说话，多余的咱不说，只做事！
（以上只是本人的经验之谈，有些地方如果写的不对，希望各位老师，前辈多多指点，好让我这个菜鸟即时的改正，谢谢）
网站架构初期，由于要纳入很多功能要素，而且又只是一个人去设计数据库，所以给后期制作带来了不小的麻烦，下面我就静态页生成功能模块的问题，简单的说一下近期找错、排错的过程
1.webservice的应用问题
网站的架构模式是几十个站共用一个数据库，由一个公共的后台界面进行管理，并且对编辑进行了权限设置，不同级别的编辑人员看到的管理界面也是不同的，当然后台生成静态页并放入前台的网站目录下，这就用到了webservice，因为后台域名与网站前段的域名是不一样的，生成后的静态页是要生成到网站域名目录下的，所以我们生成静态页的第一个问题就出在了这里。代码块的过程是在后台点击生成按钮，然后获得数据集合，然后再遍历集合，循环调用webservice，也就是说，有多少个页面，就要调用多少次webservice，这就造成了频繁调用webservice引起的一些列问题：System.OutOfMemoryException 异常；操作已超时等等，最后我们发现这个问题后，就直接在后台调用一次webservice，传值过去，在前台网站获得参数，得到集合，进行循环，效果确实显著，不会报异常，内存也不会溢出~
2.反射问题
当时的代码核心（网站架构者），为了方便程序员管理模板和后期维护，利用反射机制对要替换的标签进行处理，其实说白了就是替换的函数名是什么，标签名就是什么。这确实在编写上给我们技术人员带来了方便，但是严重的问题也出在这里，在每生成一个静态页的时候，程序就要去解析标签，我们公司教育网站网页上的模块比较多，一个页有将近十多个标签需要替换，这也就意味着每次处理一个标签，反射就要实例化一次那个含有替换函数的类，而且当时的情况是，程序运行到那个类的时候，很多属性里面的值是赋好的，比如文章数据库里悲催的content字段。。。这个内容字段是ntext类型，存储文章内容，所以，整个过程就是，循环第一个页第一个标签的时候，反射机制解析标签名，参数名，然后实例化替换函数的类并给类里的属性赋值，然后再去访问数据库，得到需要的集合，再遍历。。。几千个页下来，数据库不挂就怪了，而且服务器内存也扛不住了（注：服务器8G内存，70多个网站，数据库也在上面）最后，我们在做过比较测试后，毅然决然的提出扔掉webservice和反射，用普通的replace去替换标签内容，至于静态页如何生成在网站目录下，我们用了值得怀念的iframe，因为后台有权限控制，每个人看得到的界面和管理的数据都是不一样的，所以不会产生影响或是冲突。
3.sql语句问题
当我们这些虾兵蟹将认为程序没有任何问题的时候，挂到服务器上，数据库实例悲催的挂掉的那一刻，我们凌乱了，甚至有些想吃人的感觉，这次的问题出在sql语句，因为个人习惯问题，经常在查询的时候直接写成“select * from。。。。”，这次明白了，这么**的不好，隐患太大了！还是那个悲催的content字段！差个列表也要读一遍那个超长字符串的数据，服务器数据库肯定是扛不住的，区区几千条，刚生成20多条直接卡死，最后我们检查了整个项目的数据访问层的sql语句，将其更正。
4.总监想方设法的省钱问题。。。
（硬件问题） 我并不是在抱怨什么，可是如果说硬件设施跟不上，代码写的再好也是扯淡！我们将上面的三个问题解决后，在服务器上运行依然是20多条卡死，这次我真的没有辄了，于是我们请教了技术总监，当他带着怀疑和不屑的态度进行测试后，告诉我们，是该申请个服务器的时候了。。。
经历了这次排错，我对生成静态页有了不少的了解，也学到了不少平常用不到的知识，总之咱们做程序员的，要做的就是将自己的代码写到最好，其余的事情让事实去说话，多余的咱不说，只做事！
（以上只是本人的经验之谈，有些地方如果写的不对，希望各位老师，前辈多多指点，好让我这个菜鸟即时的改正，谢谢）
