zoukankan      html  css  js  c++  java
  • 优化杂谈

    前言

    这是一个宏大的话题,本不太适合作为一篇文章的内容。

    实际上,在程序员这个行当,哪怕仅仅只是做一般性开发的java工程师,需要掌握的优化技能也是非常之多,而每个优化有关的主题,其实都可以写一本厚厚的书。

    本文最要的目的是对优化做一个最简单的说明,提醒读者:优化很重要,要有技巧,要认真持续不断地学习!

    虽然优化是吃饭一样想当然的事情,但是还是有些人不太了解,主要是那些新入行的工程师。

    限于篇幅,不会讨论具体的优化技术。本文只讨论一些技术之外的内容,希望引起工程师对于自己代码的重视。

    优秀的工程师和优秀的医生是一样的

    优秀的工程师常常要诊断问题,面临问题的时候,他们的表现和医生以上:

    • 望闻问切-从巨多的信息中发现病灶
    • 开药方-找到问题之后,采取对应的措施

     要成为一个优秀的工程师/医生,都必须付出无数的辛劳,对有关的技术必须千锤百炼。

    为了做好项目,优化应该从头开始

    团队接到项目之后,一开始就必须重视优化的事情,这个最重要。

    之后有关人了解需求,展开设计,并确立需要优化的内容!这个思想和中医差不多,好的设计项目应该从需求方面就开始预防可能的性能问题。
    从头开始,会简化优化的工作,也会提升优化的成效。
    不要到最后才考虑优化。所谓“一步错,步步错”,也是这个意思,有时候头没有开好,想要调整或者逆转就会格外费劲。
    至于是否“万劫不复”,则看开头的时候错得多不多!
    所以,每个项目都应该首先充分重视需求和设计。

    问题定位

    这是解决问题的第一步,又是又可能是最难的。

    我们的身边都有很多亲戚朋友,有许多的熟人。活得久了,就会发现医生的诊断水平千差万别,庸医居多,而良医和神医总是很少。何也?

    因为要成为良医/优秀的诊断工程师,有些条件是不可或缺:

    • 仁心/职业道德
    • 天赋
    • 努力
    • 机遇,足够的经验

    世间,总是庸医巨多,这是符合实情的,因为要满足以上4个条件,并不是那么容易。

    一个人/工程师如果总是关心自己的吃饭技术,对行业有所敬畏,那么必定会非常努力,非常认真地去学习,去实践!

    权衡和选择

    发现了问题/病灶之后,如何救治,则会面临许多现实的问题:

    • 要不要治疗
    • 应该用什么药

    因为这些都和各方金钱/时间/能力密切相关。

    如果是举手之劳,自然乐得卖个人情。如果要耗费许多的资源,那就需要好好斟酌。

    例如发现系统太慢,仅仅是因为服务器硬件的性能太差,那么要不要优化?钱谁来掏?还是说把系统的需求削减?

    不同的需求可能会有完全不同的设计(实现方案)

    这个也很容易理解,譬如甲方给100万建设桥梁,那么必定有巨多的选择。

    例子-文件服务器设计

    企业要求建立一个云文件服务,存储所有员工的文件,要有权限控制,要有一定的性能,要方便使用!

    于是让设计师A主导设计。

    第一次设计

    1.  存储:使用一般的操作系统文件方式
    2. 能够上传/下载就可以了

            用户反馈问题:有时候非常卡;有时候不小心网络断开了,还得重新上传;每次只能上传一个;用了一段时间之后,下载速度巨慢;

    第二次设计

            针对用户提出的问题,仔细分析了下可能导致出现问题的原因:

            1.有时候非常卡,通常是因为同时又许多人上传,已经超过了

            2.网络断开,这是不可避免

            3.用了一段时间之后,服务器已经有超过30000个大大小小的文件,占据的空间大约有200g左右

            针对以上问题,A的措施是:

    1. 增加流量监控功能
    2. 增加限制流量功能
    3. 增加断点续传
    4. 高速客户文件多了就是慢

    第三次设计

            用户过了一段时间又反馈问题:

    1.  还是非常慢,虽然有时候可以同时上传的人多了
    2. 断点续传的功能可以用
    3. 下载的问题没有解决,愈加严重

            用户告诉A,如果需要可以多购买几台云服务器,但是问题一定要解决。

            于是A采用了以下方案

    1.   让用户再购买两台服务器,一台做负载郡城,一台是把同样的程序再部署一台

    第四次设计

          过了一段时间,客户还是抱怨:

    1.    用户数量在缓慢稳定地增长
    2.   上传和下载还是很慢
    3.   同一时间可以得到服务的用户数量增加了

    ..    A不知道怎么办,就去找S,S改了改设计

        

    第n此设计

         客户反馈,最近不需要那么多用户能否访问,要求减少服务器!

         S:分布的文件怎么办?

         略。

        终于,系统已经可以完全满足用户要求,只要客户有适当的钱去升级带宽和增加新的服务器,当然这些新增的投资也是有一定额度,同时用户的数量也不是一直增加。

  • 相关阅读:
    支持向量机(二)
    kafka partiton迁移方法与原理
    park和unpark
    Replicated State Machine和WAL
    thrift源码分析
    thrift使用和源码分析
    kafka源码环境搭建
    kafka指定partiton生产
    gradle构建scala
    kafka consumer代码梳理
  • 原文地址:https://www.cnblogs.com/lzfhope/p/15595740.html
Copyright © 2011-2022 走看看