50プロジェクト概要：Linuxサーバのパフォーマンス・チューニング・プロジェクト上のJava Webプロジェクト

最近のオンライン電子ビジネスプロジェクト、それは非常にカードを発見した、ユーザ体験は要約を終了する前に、その後、長い時間のために投げ、そして徐々にその理由の原因と解決策を見つける、非常に悪いです。

一般情報：

　　1 - 利用アリECS、OSSおよび関連サービスのシリーズ;

　　2-総ユーザ1W +、日常生活の量500+

　　そのインターフェイス3-電力供給プロジェクト、APP、アプレット、3つのモジュール管理プラットフォーム、150+

　　4-プロジェクトは、SSMのフレームを使用します。

　　5プロジェクトサービスのTomcat、MySQLのデータベース、同じサーバー上のRedis。

パフォーマンスの問題：

　　1-インターフェイス反応は小さな負荷異常APPにつながるとに従ってアリドルイドモニタでデータを分析し、非常に遅い、インタフェースはしばしば、10秒+要求を必要とします

　　2- Navicatはオープンテーブル、クエリデータに、反応は非常に遅いです。

　　3 - 利用ローカルのLinuxサービスは非常に迅速に、クエリデータをデータベースを開きます

　　4 - 画像/動画のアップロードが非常に遅いです

分析

　　経験に基づいて、サービスの現在のユーザーの使用状況を完全にサポートしなければならないので、カトンは無理であり、ステップ解析による必要性のステップ

トラブルシューティング

最初のステップ：アリクラウドRCSのサーバー構成が合理的であることを確認してください。

サーバ元の構成：CPU：2コアと、メモリ16ジブ; 帯域幅：1Mbpsの、ビューのCPU、メモリ、帯域幅の使用、次のように

CPU、メモリ使用量が正常であるが、帯域幅を大幅に超える必要がある：監視結果によることが示された最大1Mbps。

解決策：更新設定、の帯域幅1Mbpsのはへのアップグレードは10Mbps以下のように、アップグレード後に、2Mbpsの程度、帯域幅の実用的なケースを：

ステップ2：データベース、ビジネスサービス、分離、単独のアリクラウドRDSサービス展開サーバー、RedisのRedisのサーバーのサービスもを単独で使用することができます（プロジェクトがキャッシュの要件に現在あるので、しかし、使用されていないが高いではありません）

第三段階：使用アリSLB負荷分散サービスは2つに増加したサーバ事業で構成されています。

至此，服务器配置和更新结束，已经基本满足当前项目需求，由原来一台ECS服务器包办，更新为两台ECS业务服务器、一台RDS数据库服务器，一台SLB负载均衡服务；

第四步：在SSM框架中引用Redis缓存，针对APP和小程序的读接口，进行缓存，从而减少数据库请求压力；其中在具体落实的时候，碰到了一些问题；

　　1-Redis缓存的Entity必须实现Serializable；

　　2-使用Springboot注解式缓存，方通不能调用同一个类中其他被注解缓存的方法；即A、B方法在同一个类，A方法实现了缓存，那么B方法调用A方法，会导致A方法缓存失效；只要将A、B放在不同的类即可；

　　3-@Cacheable中的key，对应Redis中的key，即value不同的@Cacheable，对应的key的命名规则须不一样，否则会导致缓存冲突；

　　4-使用了@Cacheable，根据实际业务情况，也应该在对应的相关方法上实现@CacheEvict(清除缓存)；

　　5-SpringBoot集成的Cahe是不支持针对每一个缓存定制有效时间，这个需要自己额外实现；

　　6-项目考虑后面那会用分布式，没有使用Ehcache(内存型缓存)；

　　7-目前Redis缓存就部署在一台服务器上，没有使用分布式，也没有使用主从复制；

        <!-- spring boot 的redis模块 -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </dependency>

    //使用缓存
    @Cacheable(value = CacheValueConst.APP_INCOME_OVERVIEW_INFO, key = "#root.caches[0].name+#shopId")
    public ShopIncomeOverviewVO getIncomeOverviewInfo(Long shopId) throws ServerSqlErrorException {
       ......
    }

    //清除缓存
    @Override
    @CacheEvict(value = CacheValueConst.APP_INCOME_OVERVIEW_INFO, key = "#root.caches[0].name+#entity.shopId")
    public void save(FinanceCommissionRecord entity) throws ServerSqlErrorException {
        .....
    }

第五步：优化SQL语句，主要做了以下几点：

　　1-对数据表中的部分字段折纸索引(这个在项目最开始就逐渐落实了)；

　　2-对于查询SQL，由select * from table，改为select id, name,code... fromtable；即返回需要的字段，不需要的字段不返回；其中对性能做了下对比测试，发现字段返回的数量对相应速度还是很有影响的，如下：

第六步：针对上传文件操作，切换上传方式

　　使用了阿里的OSS服务；由原来的OSS服务器上传文件，切换成前端OSS直传；区别在于，前者文件要先上传到业务服务器，再上传到OSS服务器，非常吃带宽；后者文件直接前端上传OSS返回URL，文件不经过业务服务器；这个优化对上传大文件(比如视频文件)影响是非常大的；OSS直传如何实现阿里官方文档有非常清晰的描述。

第七步：清理服务器磁盘

　　跟踪RCS服务器监控发现，服务器磁盘使用是87%；登陆Linux服务器，使用df -h和du -sh *，排查发现Tomcat日志文件catalina.out有28G(服务器一共40G)；删除catalina.out文件，并重启Tomcat服务，删除先后的磁盘使用情况如下(断崖式下降)：

第八步：考虑到项目即将上线优惠活动和秒杀活动，便开通了弹性伸缩服务ESS；对阶段性的并发进行集中处理；

第九步：对Tomcat进行性能调优(未进行，因为上面几步下来，性能已经极大的得到提升)

总结：

　　1-其实项目目前性能问题的主要原因是带宽不够(这个是比较低级的问题)；

　　2-考虑项目后面会迭代开发，顺势将缓存、SQL优化、服务器配置等相关的触手可及的优化也做了；