当前页面遇到问题就立刻优化吗还是等到（模块/项目）接近完成了才开始优化？
一直get不到点
一开始架构肯定要搭建好啊，不然后面只能对硬件设施进行优化，
回答问题麻烦看清楚问题
首先当然是编码人员自身的意识-编写高质量的代码
在不影响进度的条件下可以优化代码逻辑。
然后先保证开发完成，跑起来再分析哪些是瓶颈，进行优化。
因为可能你现在绞尽脑汁优化的点占整体瓶颈的1%，优化从重点着手效率才最高。
最后，每一阶段的优化重点可能不一样，也要更具需求来分析解决瓶颈。因为你现在优化的点，可能在这一阶段根本用不到。
站在数据库角度来说：
一开始就知道是并发很大，那就需要从设计表结构开始，避开一些并发带来的设计，比如拆分一部分不常用字段到另外的表等，大架构基本方向对就可以。
至于其他的，就需要看具体需求，现在的设计基本是先完成功能，后优化！
我举个简单的例子，你过年回家，开始是想骑自行车回家，然后一直在思考用什么样的自行车，怎么骑才能快的。。。可是大家回家都是坐飞机回去的，所以，要看你优化的有没有意义，最后你都不采用现有方案，优化再好也没用。。。框架的时候就应该想好优化的问题。。。一点个人见解。。
题主的问题是当前页面遇到问题就立刻优化吗还是等到（模块/项目）接近完成了才开始优化？
我的答案是：遇到问题，解决问题
从重构开始。
你的问题其实算不上一个问题，就是想问马上改还是稍后再改，对吗？应对问题你肯定要有个方案，然后评估优先级，然后实施就是了，从这个角度来说没有任何问题是发现后马上改的。但是怎么评估优先级就要看具体情况了。
简单说：
高并发仅在特定应用上发生，影响范围被限制在某个模块内，不是核心功能，且不对其它功能产生直接影响，这个最后处理也没问题。
高并发仅在特定应用上发生，影响范围被限制在某个模块内，但是是核心功能，也对其它功能产生直接影响，方便的时候解决就行了。
高并发在2个或以上应用上发生，影响不限于某个模块内，尽快安排解决。
这也就是一般的情况，实际开发的时候你还要综合考虑外部压力之类的问题（比如客户死活让你下周上线）。
优化应从设计逻辑开始.
业务逻辑思路清晰就最好了,尤其是开始时候就和程序员从高并发角度做准备,整体可以给业务带来比较小的压力,或者功能比较好拆分,都能在项目开始阶段把问题解决掉.
当然这是最理想状态,通常做不到.
那么就要根据已有业务逻辑,尽可能将业务规划为容易拆分的模块,理想状况是,将来哪里成为瓶颈,哪里直接加台机器装上对应逻辑就解决.
这也是理想状态,没人先知先觉,但有经验的架构师可以预先处理掉大部分问题.
接着就是根据实际情况解决问题,这个就要看,实际业务上,究竟哪里是瓶颈.
一般说来,出问题的就几种情况:
1.程序员写的东西本身不过关,我见过有人在业务里递归查数据库的,还不限制层数,在本地跑的好好的,一上线,cpu爆表直接挂掉.
2.访问过多,这也可能是静态文件太多引起的,或者带宽被占满了.那么就需要考虑CDN或者把一些固定文件资源分配到专门服务器上面去.
3.数据库顶不住了.这个也非常常见,一般就是单表数据量太大引起的. 或者还不算大但查询很慢这类问题一般是索引不足或者过度索引造成的.处理完还要看看是否可以优化数据库配置,运维有时候只负责数据库跑起来,其余优化配置全不管.接着还不行就考虑加缓存,增加一层或者干脆换成 Nosql数据库,但这个就需要看具体业务逻辑才可以.
我遇到的问题,一般在这几个层面都可以解决的掉了.所以更高深的还在学习中.
抛开具体业务逻辑也只能说些比较空泛的了,所有抛开业务逻辑的优化,并发都是伪命题.
京公网安备 11010802040832号 | 京ICP备19059560号-6 