优化ITOO

 

 最近ITOO.NET下的整个平台下的基础.考评和权限已经都出来了，本来想在此评教中能够大展身手，可是却不然，在测试的时候，速度特别的慢，CPU明显高出了很多。问题暴露出来了是件好事，及时想办法改进。下面谈一下自己改进的办法。

  1.WEB前端优化

      在网上搜索了很多文章，关于WEB前端优化的问题。比如客户端缓存、最小HTTP请求、图片优化加载等等，可是对于评教来说，又有前台是用EasyUi框架，整个界面上并没有太多的图片。下面进行了一些JS上的简单优化。参考文章连接如下：雅虎的工程师团队给出的35个web开发最佳实践。

   

   2.js和CSS合并优化

     上述文章中提到过，JS和CSS文件能够合并，一旦合并就能够减少HTTP请求次数，提高网络加载速度和页面解析速度。压缩功能实现了对javascript脚本和CSS进行压缩的功能，它能够去除脚本或样式中不必要的空白和注释，同时能够优化脚本变量名的长度。

     在MVC4中可以通过Bundling类进行打包和压缩CSS.具体代码如下：

     

<span style="font-family:SimSun;font-size:18px;">namespace MvcApplication1{    public class BundleConfig    {        // 有关 Bundling 的详细信息，请访问 http://go.microsoft.com/fwlink/?LinkId=254725        public static void RegisterBundles(BundleCollection bundles)        {            //手动开启js/css压缩功能            BundleTable.EnableOptimizations = true;            //用户可以手动添加js绑定对象，取一个名字（虚拟路径），添加绑定的js文件路径即可            bundles.Add(new ScriptBundle("~/bundles/jsvalid").Include("~/scripts/1.js","~/scripts/2.js"));            //合并css文件            bundles.Add(new StyleBundle("").Include("", ""));                           }    }}</span>

  界面上加载的时候，只需要  @Scripts.Render("~/bundles/jsvalid")就可以了，这样就减少了js发送HTTP的请求

  3.页面缓存

     在评教系统中，因为需要调用不同的服务，而服务又是通过工厂创建出来的。后台的框架分层好多，不能每次访问的时候，都创建这么多对象吧！很耗时，这块可以优化一下。因为后台中用到了memcached，因此也想到了，将对象缓存到memcached中，下次直接取拿即可，类似单利模式。可是问题来了，web段面向的是服务端的接口，而Memcached只能存取可序列化的对象，接口又不能被序列化，所以此方案行不通。最后选取了.net中的cache，参考文章如下.Net中Cache应用。具体配置如下，采用属性注入方式：

<span style="font-family:SimSun;font-size:18px;">using ITOO.BasicSystemSettings.Contracts;using ITOO.BasicTeach.Contracts;using ITOO.ExamEvalStateEval.Contracts;using ITOO.ExamEvalStateEval.Contracts.Common;using System;using System.Collections.Generic;using System.Data.Entity;using System.Linq;using System.Runtime.Remoting.Messaging;using System.Web;using System.Web.Caching;namespace ITOO.ExamEvalStateEvalService.Client.Controllers{    public class BaseController : System.Web.Mvc.Controller    {        public int a { get; set; }        public IStudentService ss        {            get            {                            IStudentService db = HttpRuntime.Cache.Get("IStudentService") as ITOO.BasicSystemSettings.Contracts.IStudentService;                if (db == null)                {                    db = ITOO.BasicSystemSettings.Contracts.Common.ServiceFactory.GetStudentServiceLevel();                                      HttpRuntime.Cache.Insert("IStudentService", db, null,  DateTime.Now.AddMinutes(20), TimeSpan.Zero, CacheItemPriority.Low, null);                                  }                return db;            }        }        public IBasicOnClassStudentService ds        {            get            {                IBasicOnClassStudentService db = HttpRuntime.Cache.Get("IBasicOnClassStudentService") as IBasicOnClassStudentService;                if (db == null)                {                    db = ServiceFactory.GetBasicOnClassStudentService();                    HttpRuntime.Cache.Insert("IBasicOnClassStudentService", db, null, DateTime.Now.AddMinutes(20), TimeSpan.Zero, CacheItemPriority.Low, null);                }                return db;            }                    }               public IStateEvalService studentStateEval        {             get            {                IStateEvalService db = HttpRuntime.Cache.Get("IStateEvalService") as IStateEvalService;                if (db == null)                {                    db = EvalServiceFactory.GetStateEvalService();                    HttpRuntime.Cache.Insert("IStateEvalService", db, null, DateTime.Now.AddMinutes(20), TimeSpan.Zero, CacheItemPriority.Low, null);                }                return db;            }        }    }}</span>

  通过这种属性注入的方式，来缓存用到的对象，减少了服务器端的压力。

  4.框架优化

      以前没有认真的分析过框架，总以为整天上设计很好，分层很好，可是这次一测试，发现运行效率如此低。后台框架从整体上一共划分了四层。WCF——B——Dbsession——D，以前是因为没有融入Spring容器，所以假如了Dbsession的存在，可是现在整个ITOO的容器已经融入，所以现在看来Dbsession存在的意义就不大了。先前存在是让Dbsession作为一个D层的入口，减少了B层与D曾之间的关联度。现在如果用容器的话，直接全部注入即可。因此可以把Dbsession去掉，全部采用属性注入或者构造函数注入。

      并且B层和D层又细分了三层，抽的非常的细。现在看来，这块也可以优化一下，让B层和D层的设计上也减少一层，来优化整体设计。

      框架的优化正在设计中……………………………………………………………………………………………………

  5.WCF优化

     由于评教需要从基础系统这块调用大量的数据，所以在测试的时候，明显发现这两个服务占用内存很高，所以WCF这块关于大数据量的传输也需要优化一下，目前正在研究中…………………………………………

  6.EF导航属性的过错

     曾经看过一篇文章，关于EF导航属性的，有好处也有坏处。我们都知道，应用EF导航属性的话，查询起来会非常的方便，可是如果细心的话，会把导航属性对象中所设计到的关联全部查询出来，数据一多的话，查询起来会非常的缓慢。这块的优化，参考文章如下：MVC实用架构设计（三）——EF-Code First（4）：数据查询，因此后台查询的时候，还是用到导航属性，但是转换前台的POCO对象的时候，就采用.select选择器的操作。

        

   采用这种方式，优化了后台查询的效率

 

  7.视图优化

      在测试中还是发现基础这块提供评教的接口占用内存高，由于逻辑复杂，因此在后台采用了视图的操作，把需要的表之间的操作全部关联起来，满足了需要，很方便，提高了效率。

  8.数据库优化

     由于数据库学习的程度不是很好，基础有一站表30多万的数据，一下子跟评教提供，CPU一下子卡死了，因此在数据库这块也下了功夫。最简单的操作，是加上了索引。参考文章如下：SQL索引。另外想到了分表的技术，正在学习中，看来大数据问题确实是个大问题。

  9.总结

    通过这几步的优化，已经明显快了很多，但是关于WCF这块大数据的传输，还是很慢，看来还是WCF这块出了问题，需要接下来优化一下……………………………………………………