大家好，感谢邀请，今天来为大家分享一下怎么用asp网站源码分享的问题，以及和asp开源网站源码的一些困惑，大家要是还不太明白的话，也没有关系，因为接下来将为大家分享，希望可以帮助到大家，解决大家的问题，下面就开始吧！
最近我负责了一个门店ERP项目，并负责对该项目进行系统的维护。系统使用了Asp.netmvc+EntityFramework+WCF等相关技术，系统的部署，也做了负载均衡（一共有三台应用服务器）。随着系统用户量的增多，数据库记录数的剧增，系统经常出现一些卡顿问题，系统优化变得迫在眉睫。为了改变现状，我细细的研究现有系统的源码，提出了一些系统优化方案。
关于现有系统，经常出现的卡顿现象，归根结底都是因为使用我们系统的用户增多了，数据库记录的数量变大了，而代码层面的优化与服务器的优化没有跟上所致。
在讲系统优化之前，我想说说现有框架的一些优点。
我们整个框架的核心是使用了WCF的分布式服务体系。纵观现有系统的代码，我总结一下七个优点：
1、面向服务的架构体系，网站项目不需要配置数据库连接，所有服务的请求直接访问WCF服务（数据库链接配置在WCF服务中），做到了接口服务部署与站点的部署相分离，这样大大提高了网站部署的安全性。而传统的单体网站应用，数据库链接配置通常与站点紧密结合。
2、实现了一套自定义的分布式缓存技术。使用WCF+本地缓存实现了一套集中式缓存管理的技术，其实就相当于一台redis服务器，可谓是用心良苦，之所以这样做，可能是出于对.net+redis技术不成熟的担心。
3、在分库的请求上，做到了高可用。因为分库Id存放在WCF的消息头中，在每一次请求都带上，这样的好处是不用再请求内存或者数据库。如果请求内存，则分库Id容易丢失。如果请求数据库，则性能低下。
4、实现了一套基于AOP思想的日志管理系统，使用WCF的操作行为扩展（实现了IOperationBehavior接口），记录系统的操作日志和异常日志。
5、框架实现了一套数据库读写分离机制。数据库访问层使用了EntityFramework技术，通过数据库上下文工厂类DbContextFactory，传入一个数据库上下文类型(主库或从库)与数据库链接实现。
6、使用存储过程，减少了sql传输的网络带宽，提高了网站的吞吐量。对于一些复杂的数据列表使用了存储过程进行数据的展示，虽然存储过程的调试麻烦一些，还是利大于弊。
7、Lucene.net的使用，实现了一套快速全文检索机制。
下面是我总结了现有系统的八个优化建议：
1、引入Redis缓存技术。系统虽然自定义了一套缓存机制，到仅仅用在用户登录这块，其它核心业务几乎很少使用缓存技术，99.9%都是直接读数据库。建议做到能够读缓存的，绝不读数据库，减轻数据库的压力。这样可以极大提高系统的性能，增强用户体验。虽然我们可以在数据库层面做了读写分离，但这个只是减轻了数据库层面的的压力，网络请求所需要的时间还是比较长。
2、重新引入读写分离机制，减轻数据库的压力。（建议先做缓存优化，看看效果，如果效果好可以不做读写分离。如果不好，再引入读写分离机制）。
3、数据库的SQL优化，通过执行计划的分析、对表索引的进行优化等。
4、静态资源的压缩与CDN处理，一些静态资源，例如js，css，可以做分布式请求的，尽量做分布式请求，能够压缩的，尽量压缩，减少应用服务器压力，也可以节省应用服务器的带宽。
5、部分复杂的页面，请求调用服务次数过多，会导致数据库服务器与应用服务器的压力过大，建议有些服务可以合并的，尽量合并，减少不必须要的网络请求。
6、系统框架的DTO传输对象的概念比较模糊，不太注重，很多时候直接就返回整个实体列表的分页数据，这样会大大增加带宽，而带宽本身就非常昂贵和稀缺，在多人请求的情况下，会导致网站吞吐量下滑，从而导致页面加载变慢。
7、系统有很多类的代码行数过大，一个类上万行代码的情况也非常多，可读性差，也有优化空间。
8、IIS服务器的一些设置优化。可以参考博客园创始人dudu的一篇文章，让WindowsServer2008+IIS7+ASP.NET支持10万并发请求。
结语：上面是我对公司现有的一个旧系统问题的总结，以及优化的建议，不具有广泛公用性，毕竟每个企业的项目情况有所不同，所以仅仅做一个技术的分享交流。
关于本次怎么用asp网站源码分享和asp开源网站源码的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。