s*****n
发帖数: 5488 | 1 书本上的例子，当年excel for mac做了一个复杂的优化，争论了好久，最后一对比，
最后结果比不优化快几ms.
所以，大公司里面除非数据量超大，一般就是一个数组 或者list，双重循环搞定。
及时有些地方需要优化，可以单独把这部分用C实现, 例如B tree读取，数值计算。剩
下的部分用C# java实现。甚至用R, shell。
毕竟80%的计算出现的20% 的path中。这样一个个小孤岛，用 C, C++的区别能有多大呢? |
a9
发帖数: 21638 | 2 java吃内存太大了。
呢?
【在 s*****n 的大作中提到】
: 书本上的例子，当年excel for mac做了一个复杂的优化，争论了好久，最后一对比，
: 最后结果比不优化快几ms.
: 所以，大公司里面除非数据量超大，一般就是一个数组 或者list，双重循环搞定。
: 及时有些地方需要优化，可以单独把这部分用C实现, 例如B tree读取，数值计算。剩
: 下的部分用C# java实现。甚至用R, shell。
: 毕竟80%的计算出现的20% 的path中。这样一个个小孤岛，用 C, C++的区别能有多大呢?
|
t*****n
发帖数: 4908 | 3 纸上谈兵吧？
呢?
【在 s*****n 的大作中提到】
: 书本上的例子，当年excel for mac做了一个复杂的优化，争论了好久，最后一对比，
: 最后结果比不优化快几ms.
: 所以，大公司里面除非数据量超大，一般就是一个数组 或者list，双重循环搞定。
: 及时有些地方需要优化，可以单独把这部分用C实现, 例如B tree读取，数值计算。剩
: 下的部分用C# java实现。甚至用R, shell。
: 毕竟80%的计算出现的20% 的path中。这样一个个小孤岛，用 C, C++的区别能有多大呢?
|
T******7
发帖数: 1419 | |
N***m
发帖数: 4460 | 5 一个字，嫩~
【在 T******7 的大作中提到】
: 感觉楼主没什么工作经验。
|
k**********g
发帖数: 989 | 6
This is the recommended initial approach. Prototype as quick as possible (
getting it to run correctly in the shortest amount of writing time.)
But once a profiler tells you the bottlenecks, do you have the proper skills
to do the optimizations which you have promised?
呢?
This is a misunderstanding. The principle is that bottlenecks are usually by
a small fraction of code. By being a bottleneck, it is implied that the
implicated code accounts for a disproportionately large fraction of total
execution time. Given these premises, it is then a fallacy to argue that a
small fraction of code can only have a small impact on total performance.
【在 s*****n 的大作中提到】
: 书本上的例子，当年excel for mac做了一个复杂的优化，争论了好久，最后一对比，
: 最后结果比不优化快几ms.
: 所以，大公司里面除非数据量超大，一般就是一个数组 或者list，双重循环搞定。
: 及时有些地方需要优化，可以单独把这部分用C实现, 例如B tree读取，数值计算。剩
: 下的部分用C# java实现。甚至用R, shell。
: 毕竟80%的计算出现的20% 的path中。这样一个个小孤岛，用 C, C++的区别能有多大呢?
|
C***S
发帖数: 1159 | 7 这不哲学上早有定论了吗：“premature optimization is the root of all evil”。
一边写程序一边想＋＋a还是a++的，都是刚毕业的。 |
r*******n
发帖数: 3020 | 8 担心语言的速度很多时候多余，
但是算法还是要追求效率
呢?
【在 s*****n 的大作中提到】
: 书本上的例子，当年excel for mac做了一个复杂的优化，争论了好久，最后一对比，
: 最后结果比不优化快几ms.
: 所以，大公司里面除非数据量超大，一般就是一个数组 或者list，双重循环搞定。
: 及时有些地方需要优化，可以单独把这部分用C实现, 例如B tree读取，数值计算。剩
: 下的部分用C# java实现。甚至用R, shell。
: 毕竟80%的计算出现的20% 的path中。这样一个个小孤岛，用 C, C++的区别能有多大呢?
|
d**********x
发帖数: 4083 | 9 这个倒是不用想，能++a全都++a了
换个例子吧
【在 C***S 的大作中提到】
: 这不哲学上早有定论了吗：“premature optimization is the root of all evil”。
: 一边写程序一边想＋＋a还是a++的，都是刚毕业的。
|
g*****g
发帖数: 34805 | 10 最大的原因是Java在JIT下也就比C++慢个一倍，不是慢十倍。应用开发能用上这一倍差
距的就很有限了。 |
|
|
M**u
发帖数: 10158 | 11 Java是很好的语言，可惜现在大量的Java程序员实在水平不行
呢?
【在 s*****n 的大作中提到】
: 书本上的例子，当年excel for mac做了一个复杂的优化，争论了好久，最后一对比，
: 最后结果比不优化快几ms.
: 所以，大公司里面除非数据量超大，一般就是一个数组 或者list，双重循环搞定。
: 及时有些地方需要优化，可以单独把这部分用C实现, 例如B tree读取，数值计算。剩
: 下的部分用C# java实现。甚至用R, shell。
: 毕竟80%的计算出现的20% 的path中。这样一个个小孤岛，用 C, C++的区别能有多大呢?
|
a9
发帖数: 21638 | 12 套用一句车版名言：只有肉人，没有肉车
比，
。剩
【在 M**u 的大作中提到】
: Java是很好的语言，可惜现在大量的Java程序员实在水平不行
:
: 呢?
|
d********u
发帖数: 5383 | 13 bingo
【在 T******7 的大作中提到】
: 感觉楼主没什么工作经验。
|
x**n
发帖数: 461 | 14 楼主虽然没什么经验，但至少比楼上的一堆白痴强。 |
k**********g
发帖数: 989 | 15
呢?
慢，有时是ＯＯＰ的结果。（当然不全都是。）不解释。
快的，复杂的，很可能隔年的自己都看不懂。
最好是周游列国，尝尽甜酸苦辣，然後来个大忽悠
【在 s*****n 的大作中提到】
: 书本上的例子，当年excel for mac做了一个复杂的优化，争论了好久，最后一对比，
: 最后结果比不优化快几ms.
: 所以，大公司里面除非数据量超大，一般就是一个数组 或者list，双重循环搞定。
: 及时有些地方需要优化，可以单独把这部分用C实现, 例如B tree读取，数值计算。剩
: 下的部分用C# java实现。甚至用R, shell。
: 毕竟80%的计算出现的20% 的path中。这样一个个小孤岛，用 C, C++的区别能有多大呢?
|
z*******3
发帖数: 13709 | 16 用singleton优化啊
spring这个东西流行不是没有原因的
【在 a9 的大作中提到】
: java吃内存太大了。
:
: 呢?
|
z*******3
发帖数: 13709 | 17 摩尔定律生效的话，大概也就是一年吧，同等价格，硬件效率提升一倍
另外，java也可以用工具搞成native，但是这样就抹杀了跨平台的特性
不值得这么做，还有就是，其实执行起来，效率提升相当有限
http://en.wikipedia.org/wiki/AOT_compiler
没有必要，绝大多数时候，jit足够了
【在 g*****g 的大作中提到】
: 最大的原因是Java在JIT下也就比C++慢个一倍，不是慢十倍。应用开发能用上这一倍差
: 距的就很有限了。
|
z*******3
发帖数: 13709 | 18 20年前，人们还担心new这个关键字执行效率太慢
到最近，google搞的guice干脆就默认是每一次都去new
因为new这个东西执行的效率已经不低了
大概new1000个也就是5ms左右？
有兴趣的在本机上自己试试
然后如果你尝试复用代码的话
反而需要一定的知识基础，因为可能会造成内存泄漏
所以推荐的话
guice就推荐你每次都new
spring就默认是复用，但是你要明白你在做什么
ejb介于两者之间 |
d**********x
发帖数: 4083 | 19 恩，1000个也就是5ms左右
未经优化的内存池直接可以让你的程序仆街
你这里面有一句话说得非常有道理，就是“你要明白你在做什么”，不仅仅是spring如
此，一个基本合格的程序员在做任何事情的时候，都要明白自己在做什么
【在 z*******3 的大作中提到】
: 20年前，人们还担心new这个关键字执行效率太慢
: 到最近，google搞的guice干脆就默认是每一次都去new
: 因为new这个东西执行的效率已经不低了
: 大概new1000个也就是5ms左右？
: 有兴趣的在本机上自己试试
: 然后如果你尝试复用代码的话
: 反而需要一定的知识基础，因为可能会造成内存泄漏
: 所以推荐的话
: guice就推荐你每次都new
: spring就默认是复用，但是你要明白你在做什么
|
n******t
发帖数: 4406 | 20 .............
我只知道一个简单的事实：
要想不懂大脑又能写出好用的程序，是没有可能的。
【在 z*******3 的大作中提到】
: 20年前，人们还担心new这个关键字执行效率太慢
: 到最近，google搞的guice干脆就默认是每一次都去new
: 因为new这个东西执行的效率已经不低了
: 大概new1000个也就是5ms左右？
: 有兴趣的在本机上自己试试
: 然后如果你尝试复用代码的话
: 反而需要一定的知识基础，因为可能会造成内存泄漏
: 所以推荐的话
: guice就推荐你每次都new
: spring就默认是复用，但是你要明白你在做什么
|
|
|
z*******3
发帖数: 13709 | 21 我居然看到了台湾人的用语
我刚试了下，new 10^4＋1个对象才用了5ms
我这还是一般的laptop，server就不用说了
内存优化最简单的就是new完gc掉
我记得谁刚在java版说过，他们优化内存的方式就是把spring缺省的singleton改成
prototype
这样就不会让spring在启动时候把所有的service全部常驻内存，动态取舍对象
不用的就gc掉，这样反而节省内存，spring这种singleton反而浪费
然后gc的话可能会有pause问题，这个可以通过调整虚拟机参数来搞定
实在不行，上pauseless的jvm，不过这种产品没有多少人买
以前听说sun要收购它，后来不了了之，大多数时候jvm足够用了
【在 d**********x 的大作中提到】
: 恩，1000个也就是5ms左右
: 未经优化的内存池直接可以让你的程序仆街
: 你这里面有一句话说得非常有道理，就是“你要明白你在做什么”，不仅仅是spring如
: 此，一个基本合格的程序员在做任何事情的时候，都要明白自己在做什么
|
d**********x
发帖数: 4083 | 22 你确定你知道我在说什么。。。？
spring如
【在 z*******3 的大作中提到】
: 我居然看到了台湾人的用语
: 我刚试了下，new 10^4＋1个对象才用了5ms
: 我这还是一般的laptop，server就不用说了
: 内存优化最简单的就是new完gc掉
: 我记得谁刚在java版说过，他们优化内存的方式就是把spring缺省的singleton改成
: prototype
: 这样就不会让spring在启动时候把所有的service全部常驻内存，动态取舍对象
: 不用的就gc掉，这样反而节省内存，spring这种singleton反而浪费
: 然后gc的话可能会有pause问题，这个可以通过调整虚拟机参数来搞定
: 实在不行，上pauseless的jvm，不过这种产品没有多少人买
|
g*****g
发帖数: 34805 | 23 JVM 上大量new本身不是问题，但GC的时候对性能有影响。所以大系统优化的时候有时
候会使用对象池。
但这些都是高级技巧，不是功能开发时需要考虑的问题，在优化的时候也很少用到。基
本上是调完JVM还不行的时候用的。
【在 z*******3 的大作中提到】
: 20年前，人们还担心new这个关键字执行效率太慢
: 到最近，google搞的guice干脆就默认是每一次都去new
: 因为new这个东西执行的效率已经不低了
: 大概new1000个也就是5ms左右？
: 有兴趣的在本机上自己试试
: 然后如果你尝试复用代码的话
: 反而需要一定的知识基础，因为可能会造成内存泄漏
: 所以推荐的话
: guice就推荐你每次都new
: spring就默认是复用，但是你要明白你在做什么
|
z*******3
发帖数: 13709 | 24 我在说，最简单的优化其实就是最原始的方式
有时候想多了没有必要，当然愿意思考是好事
【在 d**********x 的大作中提到】
: 你确定你知道我在说什么。。。？
:
: spring如
|
g*****g
发帖数: 34805 | 25 这个没错，但不是非写回字才需要大脑。
【在 n******t 的大作中提到】
: .............
: 我只知道一个简单的事实：
: 要想不懂大脑又能写出好用的程序，是没有可能的。
|
z*******3
发帖数: 13709 | 26 所以主要问题是出在gc时候，而不是new的时候
也就是new的时间已经可以忽略了
不过如果调整参数都不行的话，那就加内存吧
老板应该不至于连这个都抠吧，也没几个钱
【在 g*****g 的大作中提到】
: JVM 上大量new本身不是问题，但GC的时候对性能有影响。所以大系统优化的时候有时
: 候会使用对象池。
: 但这些都是高级技巧，不是功能开发时需要考虑的问题，在优化的时候也很少用到。基
: 本上是调完JVM还不行的时候用的。
|
z*******3
发帖数: 13709 | 27 俺也知道一个简单的事实
就是摩尔定律生效的前提下
你思考的速度可能跟不上硬件进化的速度
当然你非要搞cutting edge东东，那木有办法
只有天空才是你的极限
我比较懒，喜欢让别人帮忙思考
【在 n******t 的大作中提到】
: .............
: 我只知道一个简单的事实：
: 要想不懂大脑又能写出好用的程序，是没有可能的。
|
d**********x
发帖数: 4083 | 28 oops
你确定你知道new的时候发生了什么事情？new/delete的吞吐量优化相对利用率优化来
说要简单太多了
当程序内存跑飞了的时候，你是不是也要建议用户“加内存吧”？
不是所有的程序都跑在服务器上。。。
有时
。基
【在 z*******3 的大作中提到】
: 所以主要问题是出在gc时候，而不是new的时候
: 也就是new的时间已经可以忽略了
: 不过如果调整参数都不行的话，那就加内存吧
: 老板应该不至于连这个都抠吧，也没几个钱
|
z*******3
发帖数: 13709 | 29 我不知道new时候发生了啥事
真心不知道，只计算了一下时间就不管了
【在 d**********x 的大作中提到】
: oops
: 你确定你知道new的时候发生了什么事情？new/delete的吞吐量优化相对利用率优化来
: 说要简单太多了
: 当程序内存跑飞了的时候，你是不是也要建议用户“加内存吧”？
: 不是所有的程序都跑在服务器上。。。
:
: 有时
: 。基
|
d**********x
发帖数: 4083 | 30 恩，其实你也没必要知道
多数人基本遇不到需要优化内存分配器的情形
化来
【在 z*******3 的大作中提到】
: 我不知道new时候发生了啥事
: 真心不知道，只计算了一下时间就不管了
|
|
|
g*****g
发帖数: 34805 | 31 即使不在server上。从desktop到mobile，内存增长的速度可比程序发展需要的涨得快。
PC上desktop app开发的首选语言是C#。最大的mobile平台的首选语言是Java，都是有
VM的。
这就是个趋势，绝大多数应用层开发，最后都会转向基于VM的语言，需要手工内存管理
的应用只会越来越少。这年头，连相机家电都开始跑Android。
【在 d**********x 的大作中提到】
: oops
: 你确定你知道new的时候发生了什么事情？new/delete的吞吐量优化相对利用率优化来
: 说要简单太多了
: 当程序内存跑飞了的时候，你是不是也要建议用户“加内存吧”？
: 不是所有的程序都跑在服务器上。。。
:
: 有时
: 。基
|
d**********x
发帖数: 4083 | 32 当然，一半说到一起了，就是绝大多数人，也许是99%的人终其一生都不会遇到需要关
心内存利用率的情形
另一方面说岔了，不是说要手工管理内存，而是要对内存使用率有基本概念，这点无论
在c/c++还是jvm里面都一样。多数c++程序员一样不会明白为什么明明只new了1g的东西
，内存就爆了，java程序员除此之外可能还要多一层苦恼就是需要修改jvm来对内存用
量调优。
我的point是在于程序员应该对自己做的每一件事情尽量清醒，明白自己在做什么，可
能有什么副作用，这样在遇到状况的时候就不至于抓瞎。
快。
化来
【在 g*****g 的大作中提到】
: 即使不在server上。从desktop到mobile，内存增长的速度可比程序发展需要的涨得快。
: PC上desktop app开发的首选语言是C#。最大的mobile平台的首选语言是Java，都是有
: VM的。
: 这就是个趋势，绝大多数应用层开发，最后都会转向基于VM的语言，需要手工内存管理
: 的应用只会越来越少。这年头，连相机家电都开始跑Android。
|
g*****g
发帖数: 34805 | 33 这个你就错了，GC基本上都是generational，内存通常不会因为segmentation而不够。
这也是GC的好处之一。
【在 d**********x 的大作中提到】
: 当然，一半说到一起了，就是绝大多数人，也许是99%的人终其一生都不会遇到需要关
: 心内存利用率的情形
: 另一方面说岔了，不是说要手工管理内存，而是要对内存使用率有基本概念，这点无论
: 在c/c++还是jvm里面都一样。多数c++程序员一样不会明白为什么明明只new了1g的东西
: ，内存就爆了，java程序员除此之外可能还要多一层苦恼就是需要修改jvm来对内存用
: 量调优。
: 我的point是在于程序员应该对自己做的每一件事情尽量清醒，明白自己在做什么，可
: 能有什么副作用，这样在遇到状况的时候就不至于抓瞎。
:
: 快。
|
d**********x
发帖数: 4083 | 34 那是因为对象的生存时间有限
当大量对象被new出来同时存在的时候，我很难想象有一种普适的算法能够应对一切分
配模式
要关
无论
东西
存用
，可
【在 g*****g 的大作中提到】
: 这个你就错了，GC基本上都是generational，内存通常不会因为segmentation而不够。
: 这也是GC的好处之一。
|
d***q
发帖数: 1119 | 35 99%的人通常不需要去关心这些问题。这也是gc的初衷。
剩下那1% 相信也不会无聊去讨论这个问题。
【在 d**********x 的大作中提到】
: 那是因为对象的生存时间有限
: 当大量对象被new出来同时存在的时候，我很难想象有一种普适的算法能够应对一切分
: 配模式
:
: 要关
: 无论
: 东西
: 存用
: ，可
|
L***n
发帖数: 6727 | 36 现在new的效率相当不错，十年前我还用自己设计的一个memory pool
来代替new，现在以前的心血全白费啦，哈哈哈，所以说优化有时候是
自己找罪受，坐等compiler改进就行拉
【在 z*******3 的大作中提到】
: 20年前，人们还担心new这个关键字执行效率太慢
: 到最近，google搞的guice干脆就默认是每一次都去new
: 因为new这个东西执行的效率已经不低了
: 大概new1000个也就是5ms左右？
: 有兴趣的在本机上自己试试
: 然后如果你尝试复用代码的话
: 反而需要一定的知识基础，因为可能会造成内存泄漏
: 所以推荐的话
: guice就推荐你每次都new
: spring就默认是复用，但是你要明白你在做什么
|
L***n
发帖数: 6727 | 37 在stackoverflow看到过一句，优化都是cheating，总有一天
要被抓到的...
【在 z*******3 的大作中提到】
: 我在说，最简单的优化其实就是最原始的方式
: 有时候想多了没有必要，当然愿意思考是好事
|
g*****g
发帖数: 34805 | 38 这个GC性能瓶颈在于CPU，内存容易加，加CPU并不容易，基本上只能加机器。
高并发低延迟的系统，很多请求一定时间不能处理就timeout，所以问题在于GC如果
stop world会导致timeout。加内存并不能解决问题，反而可能使问题更严重。可以调
GC算法来减轻这个问题，还不行的时候Object pool是需要的。
【在 z*******3 的大作中提到】
: 所以主要问题是出在gc时候，而不是new的时候
: 也就是new的时间已经可以忽略了
: 不过如果调整参数都不行的话，那就加内存吧
: 老板应该不至于连这个都抠吧，也没几个钱
|
g*****g
发帖数: 34805 | 39 这种leak确实存在，但比较好找，通常是一个Service Bean里面的List, Map之类的。
Profiling一次就全找出来了。如果你对GC算法有点认识，就应该知道GC都是使用多种
混合的算法。
没有一种普适的算法能够对付一切没错，诸如hotspot就定义了Eden，Survivor,
Tenured三个区来放不同代，每个区的GC算法都是不一样的，而且还可以调。
【在 d**********x 的大作中提到】
: 那是因为对象的生存时间有限
: 当大量对象被new出来同时存在的时候，我很难想象有一种普适的算法能够应对一切分
: 配模式
:
: 要关
: 无论
: 东西
: 存用
: ，可
|
m*******l
发帖数: 12782 | 40 错了
【在 g*****g 的大作中提到】
: 这种leak确实存在，但比较好找，通常是一个Service Bean里面的List, Map之类的。
: Profiling一次就全找出来了。如果你对GC算法有点认识，就应该知道GC都是使用多种
: 混合的算法。
: 没有一种普适的算法能够对付一切没错，诸如hotspot就定义了Eden，Survivor,
: Tenured三个区来放不同代，每个区的GC算法都是不一样的，而且还可以调。
|
|
|
g*****g
发帖数: 34805 | 41 这个只能说明你连java的profiler都没用过了，经验太少，没法沟通。
【在 m*******l 的大作中提到】
: 错了
|
m*******l
发帖数: 12782 | 42 你啊, 哈哈, 不说了,
看的懂的自然看的懂.
【在 g*****g 的大作中提到】
: 这个只能说明你连java的profiler都没用过了，经验太少，没法沟通。
|
d**********x
发帖数: 4083 | 43 有现成的库是好事……
【在 g*****g 的大作中提到】
: 这种leak确实存在，但比较好找，通常是一个Service Bean里面的List, Map之类的。
: Profiling一次就全找出来了。如果你对GC算法有点认识，就应该知道GC都是使用多种
: 混合的算法。
: 没有一种普适的算法能够对付一切没错，诸如hotspot就定义了Eden，Survivor,
: Tenured三个区来放不同代，每个区的GC算法都是不一样的，而且还可以调。
|
g*****g
发帖数: 34805 | 44 你不懂我说啥何必来装呢。我要是真错了，指出来我也就学习了。
这德行。。LOL
【在 m*******l 的大作中提到】
: 你啊, 哈哈, 不说了,
: 看的懂的自然看的懂.
|
z*******3
发帖数: 13709 | 45 只有并发数很大，而且对于响应时间有明确要求的服务器才有这种要求
可以减少heap size，还有调整gc的goal
针对并发数很大，可以通过加机器来解决
针对响应时间有明确要求，可以通过azul的jvm来解决
还有可以通过用paas来搞定，把烦恼丢给服务提供商
paas这些提供商不少也是通过购买azul的jvm来搞定
让我来选
如果已经有了机器，加机器是首选
如果没有机器，用open shift，让red hat去痛苦
如果我有很多钱，把azul给买过来，然后开源它的jvm
哦也
【在 g*****g 的大作中提到】
: 这个GC性能瓶颈在于CPU，内存容易加，加CPU并不容易，基本上只能加机器。
: 高并发低延迟的系统，很多请求一定时间不能处理就timeout，所以问题在于GC如果
: stop world会导致timeout。加内存并不能解决问题，反而可能使问题更严重。可以调
: GC算法来减轻这个问题，还不行的时候Object pool是需要的。
|
z*******3
发帖数: 13709 | 46 刚看了一下gc的策略
说要尽量让所有的对象在一次gc周期内被gc掉
所以new完用完就扔掉最符合这个要求
倒是singleton了一堆又常驻内存的话
用这个策略怕是搞不定了
投机取巧容易还回去，还是做傻人比较好
【在 L***n 的大作中提到】
: 在stackoverflow看到过一句，优化都是cheating，总有一天
: 要被抓到的...
|
h********3
发帖数: 2075 | 47 搞Java的人的看法可能恰恰相反，只有没有工作经验的人才会那么计较java和c/c++的
速度差别。有工作经验的人关心的更多是java带来的开发成本上的方便。做优化的人，
更关注的也是算法复杂度上的优化，而不是这点差别。
【在 T******7 的大作中提到】
: 感觉楼主没什么工作经验。
|
h********3
发帖数: 2075 | 48 对。如果不是实时性要求很高的系统，应该关心的是如何把O(n^2)降低到O(n)或者O(
nlogn)这样的算法复杂度。
做过大数据分析的就知道，如果是O(n^3)以上的算法，跑10000以上的数据都要好几个
小时。而如果降低到O(n^2)，只要十几秒钟。几个小时到十几秒，这种优化才叫真正的
优化。而不是为了那一两秒而折腾。
【在 r*******n 的大作中提到】
: 担心语言的速度很多时候多余，
: 但是算法还是要追求效率
:
: 呢?
|
h********3
发帖数: 2075 | 49 呵呵，我们做大数据分析的时候经常遇到你说的内存撑爆的问题。不过，我们用Java的
根本不会去修改什么JVM。简单一点，就是增加内存，换64位的机器。反正现在机器便
宜。现在我们跑个算法，用十几个G的内存很正常的。如果十几个G都不够的话，那就要
考虑你优化你的空间复杂度了。比如说，你用的内存对象这些，是否应该存到数据库中
等等。
【在 d**********x 的大作中提到】
: 当然，一半说到一起了，就是绝大多数人，也许是99%的人终其一生都不会遇到需要关
: 心内存利用率的情形
: 另一方面说岔了，不是说要手工管理内存，而是要对内存使用率有基本概念，这点无论
: 在c/c++还是jvm里面都一样。多数c++程序员一样不会明白为什么明明只new了1g的东西
: ，内存就爆了，java程序员除此之外可能还要多一层苦恼就是需要修改jvm来对内存用
: 量调优。
: 我的point是在于程序员应该对自己做的每一件事情尽量清醒，明白自己在做什么，可
: 能有什么副作用，这样在遇到状况的时候就不至于抓瞎。
:
: 快。
|
d**********x
发帖数: 4083 | 50 it depends on your area.
i do not want to mention my 老本行 again..
【在 h********3 的大作中提到】
: 搞Java的人的看法可能恰恰相反，只有没有工作经验的人才会那么计较java和c/c++的
: 速度差别。有工作经验的人关心的更多是java带来的开发成本上的方便。做优化的人，
: 更关注的也是算法复杂度上的优化，而不是这点差别。
|
|
|
d**********x
发帖数: 4083 | 51 对啊，这说明你属于不需要关心"内存利用率"的那一部分啊。
我上面老早就说了，不是所有的程序都跑在服务端，不是所有的机器你都能随便加内存
的，不是吗
要关
无论
东西
存用
，可
【在 h********3 的大作中提到】
: 呵呵，我们做大数据分析的时候经常遇到你说的内存撑爆的问题。不过，我们用Java的
: 根本不会去修改什么JVM。简单一点，就是增加内存，换64位的机器。反正现在机器便
: 宜。现在我们跑个算法，用十几个G的内存很正常的。如果十几个G都不够的话，那就要
: 考虑你优化你的空间复杂度了。比如说，你用的内存对象这些，是否应该存到数据库中
: 等等。
|
g*****g
发帖数: 34805 | 52 什么东西都有个成本问题。你说的这些办法会增加成本。所以用object pool的优化在
这种情况下还是有用的。本身也不是什么很难的做法。
【在 z*******3 的大作中提到】
: 只有并发数很大，而且对于响应时间有明确要求的服务器才有这种要求
: 可以减少heap size，还有调整gc的goal
: 针对并发数很大，可以通过加机器来解决
: 针对响应时间有明确要求，可以通过azul的jvm来解决
: 还有可以通过用paas来搞定，把烦恼丢给服务提供商
: paas这些提供商不少也是通过购买azul的jvm来搞定
: 让我来选
: 如果已经有了机器，加机器是首选
: 如果没有机器，用open shift，让red hat去痛苦
: 如果我有很多钱，把azul给买过来，然后开源它的jvm
|
z*******3
发帖数: 13709 | 53 完全不增加成本是不可能的
其实最大的开销除了码农的工资以外，大多数来自软件的成本
weblogic这种吞金兽，只要能搞定开源，这个钱已经节省到很理想了
再省就木有必要了，对于硬件，我们一般都是不省的
比如给员工买mac机开发阿，是吧，比起软件的licenses fee
硬件的钱实在是小儿科了，硬件的贬值是非常快的
感谢摩尔定律，感谢那些学物理的
更不要说硬件本身也有一个折旧的问题
所以硬件钱，不省
【在 g*****g 的大作中提到】
: 什么东西都有个成本问题。你说的这些办法会增加成本。所以用object pool的优化在
: 这种情况下还是有用的。本身也不是什么很难的做法。
|
z*******3
发帖数: 13709 | 54 另外，只要你愿意给钱，很多事情都好办
real time java不是没有，而且应用在军工领域
这是几个例子
http://stackoverflow.com/questions/4051966/which-real-time-rtsj
如果你觉得你的应用真的那么对时间那么敏感
你可以考虑出钱搞搞rts java
但是这个需要特定的操作系统予以支持
不是随便一个os就能跑
rts java的主页
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-13
还有就是real time java也有几个不同产品可以选择
包括ibm就提供相应的websphere rt
还有介于real time和一般jvm之间的有jrockit
这个是soft real time jvm，这个就是以前bea的jvm
当年搞java发家致富的公司的jvm基本上都在这里了
不过这种太过于讲究效率的一般都没啥市场
大部分人都不搭理这种东东
因为免费的普通的足够用了 |
n******t
发帖数: 4406 | 55 这种说法，一看就是没做过大型项目的人。
这世界上大部分程序效率底下根本不是因为O什么什么导致的。
【在 h********3 的大作中提到】
: 对。如果不是实时性要求很高的系统，应该关心的是如何把O(n^2)降低到O(n)或者O(
: nlogn)这样的算法复杂度。
: 做过大数据分析的就知道，如果是O(n^3)以上的算法，跑10000以上的数据都要好几个
: 小时。而如果降低到O(n^2)，只要十几秒钟。几个小时到十几秒，这种优化才叫真正的
: 优化。而不是为了那一两秒而折腾。
|
n******t
发帖数: 4406 | 56 晕，你知道CPU bounded的任务在大部分应用中占多少比例么？
你知道memory 访问速度这么十年提高了多少么？
你知道磁碟的访问速度这么十年提高了多少么？
你知道公司加一堆机器，相应的管理的成本需要加多少么？
【在 z*******3 的大作中提到】
: 完全不增加成本是不可能的
: 其实最大的开销除了码农的工资以外，大多数来自软件的成本
: weblogic这种吞金兽，只要能搞定开源，这个钱已经节省到很理想了
: 再省就木有必要了，对于硬件，我们一般都是不省的
: 比如给员工买mac机开发阿，是吧，比起软件的licenses fee
: 硬件的钱实在是小儿科了，硬件的贬值是非常快的
: 感谢摩尔定律，感谢那些学物理的
: 更不要说硬件本身也有一个折旧的问题
: 所以硬件钱，不省
|
z*******3
发帖数: 13709 | 57 我没觉得有多难，要不，你zkss？
【在 n******t 的大作中提到】
: 晕，你知道CPU bounded的任务在大部分应用中占多少比例么？
: 你知道memory 访问速度这么十年提高了多少么？
: 你知道磁碟的访问速度这么十年提高了多少么？
: 你知道公司加一堆机器，相应的管理的成本需要加多少么？
|
n******t
发帖数: 4406 | 58 你只要知道这些，就不会认为摩尔定律能拿来像你这么用了。lol
也不会认为花钱买几台机器，就能解决应用程序的效率问题了。
【在 z*******3 的大作中提到】
: 我没觉得有多难，要不，你zkss？
|
c**0
发帖数: 535 | 59 楼主真乃码工之耻！
【在 s*****n 的大作中提到】
: 书本上的例子，当年excel for mac做了一个复杂的优化，争论了好久，最后一对比，
: 最后结果比不优化快几ms.
: 所以，大公司里面除非数据量超大，一般就是一个数组 或者list，双重循环搞定。
: 及时有些地方需要优化，可以单独把这部分用C实现, 例如B tree读取，数值计算。剩
: 下的部分用C# java实现。甚至用R, shell。
: 毕竟80%的计算出现的20% 的path中。这样一个个小孤岛，用 C, C++的区别能有多大呢?
|
z*******3
发帖数: 13709 | 60 你做过最大的有多大？
我现在手头这个，2亿人在用，不知道够不够大
并发数至少是million，全年99.99%的有效率，低于这个比例就要赔钱
对于系统的优化也只做到调整jvm参数的地步
没有建立object pool，我是真心觉得加几台机器没什么大不了的
现在机器便宜得跟什么一样，一个公司要是连硬件都买不起
那实在是有些寒酸，要不你给说个“大型项目”八
然后把你在其中遇到的问题给展开说说，别老说些虚的，来些实在的
【在 n******t 的大作中提到】
: 这种说法，一看就是没做过大型项目的人。
: 这世界上大部分程序效率底下根本不是因为O什么什么导致的。
|
|
|
z*******3
发帖数: 13709 | 61 很简单阿，还可以对软件分层，逐层优化
最简单就是把front end和back end分离
然后针对front end的负载加机器，尽量在front end把request给解决掉
这样就不用再去back end了，用最简单的减少层之间io的方式来降低负载
有的是办法，机器也是真便宜，这是在server side，又不是什么mobile
那么在乎那点小钱干嘛
【在 n******t 的大作中提到】
: 你只要知道这些，就不会认为摩尔定律能拿来像你这么用了。lol
: 也不会认为花钱买几台机器，就能解决应用程序的效率问题了。
|
n******t
发帖数: 4406 | 62 你的东西我不了解。并发1m不算啥，要看你干什么。
我指的是认为算法复杂度真的matters so much的人，
明显是没有做过大型项目的。
【在 z*******3 的大作中提到】
: 你做过最大的有多大？
: 我现在手头这个，2亿人在用，不知道够不够大
: 并发数至少是million，全年99.99%的有效率，低于这个比例就要赔钱
: 对于系统的优化也只做到调整jvm参数的地步
: 没有建立object pool，我是真心觉得加几台机器没什么大不了的
: 现在机器便宜得跟什么一样，一个公司要是连硬件都买不起
: 那实在是有些寒酸，要不你给说个“大型项目”八
: 然后把你在其中遇到的问题给展开说说，别老说些虚的，来些实在的
|
d**********x
发帖数: 4083 | 63 说白了就是很多人只在自己的领域里面用自己的经验说话
mitbbs上另外一个很不好的风气就是大家都有意无意地显示出“我做的领域是最牛逼的
”这种气场
其实这里也没几个人能真的到牛逼哄哄大手一挥带几个小弟做出一个震惊世界的项目的
境地，干嘛不各让一步多多学习呢。。。我一直觉得开放才是码农进步的根本啊。
【在 n******t 的大作中提到】
: 你只要知道这些，就不会认为摩尔定律能拿来像你这么用了。lol
: 也不会认为花钱买几台机器，就能解决应用程序的效率问题了。
|
d**********x
发帖数: 4083 | 64 it matters
but it always always has been done by some smart guys in early stage...>_<
【在 n******t 的大作中提到】
: 你的东西我不了解。并发1m不算啥，要看你干什么。
: 我指的是认为算法复杂度真的matters so much的人，
: 明显是没有做过大型项目的。
|
z*******3
发帖数: 13709 | 65 我觉得你应该展开说说你在大型项目中遇到的问题
然后你是如何解决和克服的
别人再看看对于你这种问题是否有其它方式予以解决
动不动就是“你就只知道这个”就没什么意思了
你要是觉得自己知道，那就说吧，我很有兴趣知道
做case study是最有趣的了
【在 n******t 的大作中提到】
: 你的东西我不了解。并发1m不算啥，要看你干什么。
: 我指的是认为算法复杂度真的matters so much的人，
: 明显是没有做过大型项目的。
|
l*********s
发帖数: 5409 | 66 what is your very famous and popular project?
【在 z*******3 的大作中提到】
: 你做过最大的有多大？
: 我现在手头这个，2亿人在用，不知道够不够大
: 并发数至少是million，全年99.99%的有效率，低于这个比例就要赔钱
: 对于系统的优化也只做到调整jvm参数的地步
: 没有建立object pool，我是真心觉得加几台机器没什么大不了的
: 现在机器便宜得跟什么一样，一个公司要是连硬件都买不起
: 那实在是有些寒酸，要不你给说个“大型项目”八
: 然后把你在其中遇到的问题给展开说说，别老说些虚的，来些实在的
|
n******t
发帖数: 4406 | 67 你这个说的和你之前讲的貌似没有太大的关系。
我要讲的就是，硬件的速度没有大部分人认为的提高速度那么快。
纯粹CPU bounded的task，比例非常小。
CPU 快了，memory没有快很多，磁盘也没有快很多，如果你要真的
像用上CPU快的部分，你更需要对你的资源有清楚的了解。
【在 z*******3 的大作中提到】
: 很简单阿，还可以对软件分层，逐层优化
: 最简单就是把front end和back end分离
: 然后针对front end的负载加机器，尽量在front end把request给解决掉
: 这样就不用再去back end了，用最简单的减少层之间io的方式来降低负载
: 有的是办法，机器也是真便宜，这是在server side，又不是什么mobile
: 那么在乎那点小钱干嘛
|
d**********x
发帖数: 4083 | 68 好吧，举个例子。
一个内存受限的系统，总共给10M的内存，要求将新浪首页完整渲染出来，全功能浏览
，包括javascript支持。平台仅提供socket和基本的类windows api
solution嘛，我当时想的是让客户给机器多加点内存，可惜不行啊。
【在 z*******3 的大作中提到】
: 我觉得你应该展开说说你在大型项目中遇到的问题
: 然后你是如何解决和克服的
: 别人再看看对于你这种问题是否有其它方式予以解决
: 动不动就是“你就只知道这个”就没什么意思了
: 你要是觉得自己知道，那就说吧，我很有兴趣知道
: 做case study是最有趣的了
|
n******t
发帖数: 4406 | 69 对，我说的就是这个意思，复杂度能从O(n^2) 编程O(n)的，
早就有人做掉的。你用啥语言都是这样的。
【在 d**********x 的大作中提到】
: it matters
: but it always always has been done by some smart guys in early stage...>_<
|
z*******3
发帖数: 13709 | 70 看你要怎么定义这个famous和popular了
如果想说要是像excel那样路人皆知，那还真没有
但是你说要让某个范围内，一定比例的人的某个行为
都经过我开发的程序，这个还是有的
不过讨论这个不好玩，要讨论问题，为什么发生了这种问题
然后如何解决的，从中有什么收获，这才是有价值的讨论
【在 l*********s 的大作中提到】
: what is your very famous and popular project?
|
|
|
l*********s
发帖数: 5409 | 71 the problem is that O() notation is a limiting theory and not really
practical.
I think most of the time, it just gives a false sense of confidence ( which
isn't too bad as we are lazy and don't care efficiency that much :-))
【在 d**********x 的大作中提到】
: it matters
: but it always always has been done by some smart guys in early stage...>_<
|
z*******3
发帖数: 13709 | 72 我要说的是，机器并没有你想得那么贵
实际上大多数公司最贵的支出一直都是码农的工资
其次是软件的license fee，最后才是硬件的折旧
相比之下，加机器是最便宜的方式
而且简单的结构可以使得更少人维护更大的系统
所以减少了码农的数量，而码农工资是最贵的
所以减少了码农也就自然减少了支出
【在 n******t 的大作中提到】
: 你这个说的和你之前讲的貌似没有太大的关系。
: 我要讲的就是，硬件的速度没有大部分人认为的提高速度那么快。
: 纯粹CPU bounded的task，比例非常小。
: CPU 快了，memory没有快很多，磁盘也没有快很多，如果你要真的
: 像用上CPU快的部分，你更需要对你的资源有清楚的了解。
|
n******t
发帖数: 4406 | 73 首先，大部分桌面应用，内存分配都不是随意的。
也不是IO都能给你一个人用的。这个时候随便改动
硬件配置和要求是会影响用户体验的。你可以想一下，
如果80的桌面应用(浏览器，播放器，QQ，都用Java
写是什么个效果).
对于专用的项目，一般来一旦你有遇到性能上的不足，
很多时候买机器是没有用的。当然这个应用可能本省
就对性能要求不高，或者天生就scale，那没有问题。
你可以买机器。随便举个例子，对于stock 交易系统，
如果你发现吞吐不够，你怎么办？买好机器？很多时候
没用，因为根本不是 CPU bounded的任务，再买机器？
那就更糟糕，这些机器之间的通信也有开销，除非你
提高设计水平，买机器是没有用的。
【在 z*******3 的大作中提到】
: 我觉得你应该展开说说你在大型项目中遇到的问题
: 然后你是如何解决和克服的
: 别人再看看对于你这种问题是否有其它方式予以解决
: 动不动就是“你就只知道这个”就没什么意思了
: 你要是觉得自己知道，那就说吧，我很有兴趣知道
: 做case study是最有趣的了
|
z*******3
发帖数: 13709 | 74 你这是server吗？
古德霸说的瓶颈是server上的问题
你这是mobile吧，才10m内存
mobile我是比较没做过，真心不知道
【在 d**********x 的大作中提到】
: 好吧，举个例子。
: 一个内存受限的系统，总共给10M的内存，要求将新浪首页完整渲染出来，全功能浏览
: ，包括javascript支持。平台仅提供socket和基本的类windows api
: solution嘛，我当时想的是让客户给机器多加点内存，可惜不行啊。
|
z*******3
发帖数: 13709 | 75 我们在讨论server side的问题
你先看清楚为什么会出现那个问题
定位问题先
server跟desktop不是一回事，这倒是真的
如果是desktop，我觉得只要不玩3d游戏，内存一般是够的
我现在4g内存，平常用不到500m，剩下的真心浪费
另外对于4g这么大的内存来说，java一般最大的memory heap是四分之一
也就是1g，所以对于绝大多数应用来说，这个应该够折腾了
3d游戏另说，还有就是对于client side的软件
gc的pause其实没那么可怕，停一下就停一下嘛，又不是什么导弹拦截装置
关于项目如何优化，那当然要看问题
先定位问题，再讨论如何解决
没有人说过用买机器能够解决所有问题
我说了好多种解决问题的方式
古德霸挑了一个买机器的弊端来说
【在 n******t 的大作中提到】
: 首先，大部分桌面应用，内存分配都不是随意的。
: 也不是IO都能给你一个人用的。这个时候随便改动
: 硬件配置和要求是会影响用户体验的。你可以想一下，
: 如果80的桌面应用(浏览器，播放器，QQ，都用Java
: 写是什么个效果).
: 对于专用的项目，一般来一旦你有遇到性能上的不足，
: 很多时候买机器是没有用的。当然这个应用可能本省
: 就对性能要求不高，或者天生就scale，那没有问题。
: 你可以买机器。随便举个例子，对于stock 交易系统，
: 如果你发现吞吐不够，你怎么办？买好机器？很多时候
|
n******t
发帖数: 4406 | 76 我当然知道机器不贵。
但是一般就我所知，公司如果盈利，遇到了performance的问题，
如果不影响客户，是不会管的。也就是说要提速，一定是对
revenue造成很serious的影响了。这个时候，一个平庸的设计，
一般来说，是没法通过买机器来实现提速的。
当然不是说，所有系统都要做到完美无暇，但是很多人和公司
都过高估计了硬件提升的速度。
【在 z*******3 的大作中提到】
: 我要说的是，机器并没有你想得那么贵
: 实际上大多数公司最贵的支出一直都是码农的工资
: 其次是软件的license fee，最后才是硬件的折旧
: 相比之下，加机器是最便宜的方式
: 而且简单的结构可以使得更少人维护更大的系统
: 所以减少了码农的数量，而码农工资是最贵的
: 所以减少了码农也就自然减少了支出
|
z*******3
发帖数: 13709 | 77 我就assume其它都做得不错的前提下
如果结构有问题，那这就两论了
结构错，麻烦大了，项目多半要挂
【在 n******t 的大作中提到】
: 我当然知道机器不贵。
: 但是一般就我所知，公司如果盈利，遇到了performance的问题，
: 如果不影响客户，是不会管的。也就是说要提速，一定是对
: revenue造成很serious的影响了。这个时候，一个平庸的设计，
: 一般来说，是没法通过买机器来实现提速的。
: 当然不是说，所有系统都要做到完美无暇，但是很多人和公司
: 都过高估计了硬件提升的速度。
|
l*********s
发帖数: 5409 | 78 我很有兴趣知道。2000年全世界的internet用户是3.6亿， 2亿用户绝对是超级流行的
app了。 。
【在 z*******3 的大作中提到】
: 看你要怎么定义这个famous和popular了
: 如果想说要是像excel那样路人皆知，那还真没有
: 但是你说要让某个范围内，一定比例的人的某个行为
: 都经过我开发的程序，这个还是有的
: 不过讨论这个不好玩，要讨论问题，为什么发生了这种问题
: 然后如何解决的，从中有什么收获，这才是有价值的讨论
|
z*******3
发帖数: 13709 | 79 怎么会是app呢？
我不做安桌的
我们做的给你一个类比
就比如某个银行的back end
全年365天24小时不间断运行
这个很正常吧？这种东西
不是app
另外2000年的数据就不要说了，12年前了
【在 l*********s 的大作中提到】
: 我很有兴趣知道。2000年全世界的internet用户是3.6亿， 2亿用户绝对是超级流行的
: app了。 。
|
l*********s
发帖数: 5409 | 80 Ok.
【在 z*******3 的大作中提到】
: 怎么会是app呢？
: 我不做安桌的
: 我们做的给你一个类比
: 就比如某个银行的back end
: 全年365天24小时不间断运行
: 这个很正常吧？这种东西
: 不是app
: 另外2000年的数据就不要说了，12年前了
|
|
|
d**********x
发帖数: 4083 | 81 这也是一个好理由。
一个比较贴边的例子：
碰巧昨天刚和人讨论过in-place mergesort的问题
这东西做到了O(1) space，O(nlogn) time，结果实际上还是比同阶的heapsort差很多
which
_<
【在 l*********s 的大作中提到】
: the problem is that O() notation is a limiting theory and not really
: practical.
: I think most of the time, it just gives a false sense of confidence ( which
: isn't too bad as we are lazy and don't care efficiency that much :-))
:
|
n******t
发帖数: 4406 | 82 算法复杂度在简单的case里面比较一目了然。
复杂的情况下，时间复杂度都会受空间复杂度影响的。
Suffix tree就是个比较好的例子。
而且很多时候，需要的对象集是比较特殊的状况，
通用的算法复杂度也是没用的。
【在 d**********x 的大作中提到】
: 这也是一个好理由。
: 一个比较贴边的例子：
: 碰巧昨天刚和人讨论过in-place mergesort的问题
: 这东西做到了O(1) space，O(nlogn) time，结果实际上还是比同阶的heapsort差很多
:
: which
: _<
|
i*****o
发帖数: 1714 | 83 顶这个。大家能互相学习最好了，实在非要吵就请吵的幽默点吧。
★ 发自iPhone App: ChineseWeb 7.7
【在 d**********x 的大作中提到】
: 说白了就是很多人只在自己的领域里面用自己的经验说话
: mitbbs上另外一个很不好的风气就是大家都有意无意地显示出“我做的领域是最牛逼的
: ”这种气场
: 其实这里也没几个人能真的到牛逼哄哄大手一挥带几个小弟做出一个震惊世界的项目的
: 境地，干嘛不各让一步多多学习呢。。。我一直觉得开放才是码农进步的根本啊。
|
l*********s
发帖数: 5409 | 84 yeah, you don't even need complex situations. Bjarne Stroustrup once showed
a benchmark of insertion/deletion on vector vs list: surprisingly, the
former wins even when N is ~ 10^6.
【在 n******t 的大作中提到】
: 算法复杂度在简单的case里面比较一目了然。
: 复杂的情况下，时间复杂度都会受空间复杂度影响的。
: Suffix tree就是个比较好的例子。
: 而且很多时候，需要的对象集是比较特殊的状况，
: 通用的算法复杂度也是没用的。
|
s********i
发帖数: 145 | 85
为什么？碎片吗？愿闻其祥。。。
【在 d**********x 的大作中提到】
: 当然，一半说到一起了，就是绝大多数人，也许是99%的人终其一生都不会遇到需要关
: 心内存利用率的情形
: 另一方面说岔了，不是说要手工管理内存，而是要对内存使用率有基本概念，这点无论
: 在c/c++还是jvm里面都一样。多数c++程序员一样不会明白为什么明明只new了1g的东西
: ，内存就爆了，java程序员除此之外可能还要多一层苦恼就是需要修改jvm来对内存用
: 量调优。
: 我的point是在于程序员应该对自己做的每一件事情尽量清醒，明白自己在做什么，可
: 能有什么副作用，这样在遇到状况的时候就不至于抓瞎。
:
: 快。
|
h********3
发帖数: 2075 | 86 一看这种说法的，就知道是没有接触过真正大数据的人，还停留在以前的业务管理系统
的开发层面上。以前国内圈子混过的人，谁没做过业务管理系统这些的。依此就推测别
人没有做过的大型项目就实在太无知了。
【在 n******t 的大作中提到】
: 这种说法，一看就是没做过大型项目的人。
: 这世界上大部分程序效率底下根本不是因为O什么什么导致的。
|
m********5
发帖数: 17667 | 87 ...
Well, maybe some "big" projects in your mind are not that critical at all.
The 算法复杂度 really matters a lot. But usually this has already been taken
care of at the project designing phase.
At the implementation phase, even the particular compiler matters a lot! How
could the language choice become a trivial 杞人忧天?!
I also believe under certain scenario and in some fields they might not be
that important. Still you have to be arrogant enough to claim something,
which has been studied so intensively in CS, is completely nonsense, just
because there is no practical examples in the small puddle where you have
been spending your lifetime. In many fields, all the things mentioned above
are very critical. And companies pay loads of money to whom can optimize
them.
Honestly, I have no idea why most of you are so obsessed about which
language is the best. To me, it is more like arguing which screw driver is
the best: slot, Phillips, Frearson, square-socket, hex-socket, ...? WTF?!
you need different tool to attack different problem! None of the "big"
projects in real world can deliver tangible result in a reasonable time
schedule, if the team is forced to just use one language to develop.
In deed, many so-called new languages are reinventing some of the wheels.
Sometimes it is painful to see their advocators make a big fuss about it,
nevertheless, we have to admit that the languages are evolving to fit into
real world better than ever and the new comers can always ease your life in
some particular circumstance. Sorry to be so hash, if the truth I described
offends some of your people reluctant to learn more tricks.
【在 n******t 的大作中提到】
: 你的东西我不了解。并发1m不算啥，要看你干什么。
: 我指的是认为算法复杂度真的matters so much的人，
: 明显是没有做过大型项目的。
|
z*******3
发帖数: 13709 | 88 就这么说吧
我觉得项目开始之初，是最需要经验的时候
好坏就在一念之间
你信不信？你用了某一个语言，然后另外一家公司用了另外一个语言开发
最后结局就是截然不同
同样是小公司，规模差不多，但是结局就是不一样
因为系统，尤其是这种天天用的系统，非产品
一开始是打地基的阶段，你一开始用了什么
将来可能就一直用什么，你想换一个语言
一般就意味着要把地基重新修一遍
不是那么容易换的，哪怕是都用java写
用ibm的，跟用red hat的，写出来的就是不一样
哪怕都用java，你都没有办法随意地切换平台
因为公司会给你下私货，也就是我这种神经病喜欢跟各个公司过不去
倒腾标准，除了我以外，买买提上几乎所有的id，就我观察
都没有这个习惯，所以哪怕是都用java，你都会被套在一个公司上
更何况是不同语言写的系统
所以如果你真有大项目经验
你应该明白，一开始决定用什么工具，这个是非常重要的一步
因为你做的是server side软件，不是mobile，也不是desktop这种
更新版本之后，之前那个丢掉不用了，server side没有这种事
基本上一家公司从起步到发展到壮大，code只会越来越多
而legacy code基本上会跟你一辈子，大多数时候legacy code你连看都看不过来
更不要说去重构了，就算你有力气重构，测试等同事也不会配合你
领导更不会赞同你，所以除非万不得已，否则不会有机会让你推倒重来
而一般推倒重来就意味着项目失败
别忘了，这个星球上一半以上的项目
是失败的
而项目失败了你也没什么兴趣呆下去了
船都沉了你还不跑？等什么？
所以老油条往往都是干一段时间就知道了
一看，不行了，赶快跑
java版不是讨论过jsf嘛，那个贴里面不少人说了他们自己的例子
都是一看势头不对，呆了一两年，走了走了走了
树倒猢狲搡 |
s*****n
发帖数: 5488 | 89 所以fb选了php:P
【在 z*******3 的大作中提到】
: 就这么说吧
: 我觉得项目开始之初，是最需要经验的时候
: 好坏就在一念之间
: 你信不信？你用了某一个语言，然后另外一家公司用了另外一个语言开发
: 最后结局就是截然不同
: 同样是小公司，规模差不多，但是结局就是不一样
: 因为系统，尤其是这种天天用的系统，非产品
: 一开始是打地基的阶段，你一开始用了什么
: 将来可能就一直用什么，你想换一个语言
: 一般就意味着要把地基重新修一遍
|
m*******l
发帖数: 12782 | 90 不一定, 有时候开始的时候作者考虑的是开始的适用的senario
后来变大了,就不适合了,但是大家又懒的改底层的东西
有人要改 ,你又要担心一改动全身,还是不改了...
【在 d**********x 的大作中提到】
: it matters
: but it always always has been done by some smart guys in early stage...>_<
|
|
|
m*******l
发帖数: 12782 | 91 这个看什么情况了,一般10^6这么大的还是list吧
我记得有详细的研究,1000还是多少是个界限
showed
【在 l*********s 的大作中提到】
: yeah, you don't even need complex situations. Bjarne Stroustrup once showed
: a benchmark of insertion/deletion on vector vs list: surprisingly, the
: former wins even when N is ~ 10^6.
:
|
m*******l
发帖数: 12782 | 92 adapter
【在 z*******3 的大作中提到】
: 就这么说吧
: 我觉得项目开始之初，是最需要经验的时候
: 好坏就在一念之间
: 你信不信？你用了某一个语言，然后另外一家公司用了另外一个语言开发
: 最后结局就是截然不同
: 同样是小公司，规模差不多，但是结局就是不一样
: 因为系统，尤其是这种天天用的系统，非产品
: 一开始是打地基的阶段，你一开始用了什么
: 将来可能就一直用什么，你想换一个语言
: 一般就意味着要把地基重新修一遍
|
L***n
发帖数: 6727 | 93 顶，赞大手一挥，形象
【在 d**********x 的大作中提到】
: 说白了就是很多人只在自己的领域里面用自己的经验说话
: mitbbs上另外一个很不好的风气就是大家都有意无意地显示出“我做的领域是最牛逼的
: ”这种气场
: 其实这里也没几个人能真的到牛逼哄哄大手一挥带几个小弟做出一个震惊世界的项目的
: 境地，干嘛不各让一步多多学习呢。。。我一直觉得开放才是码农进步的根本啊。
|
L***n
发帖数: 6727 | 94 手机也不止这么点内存啊，是不是用微波炉上网的啊
【在 d**********x 的大作中提到】
: 好吧，举个例子。
: 一个内存受限的系统，总共给10M的内存，要求将新浪首页完整渲染出来，全功能浏览
: ，包括javascript支持。平台仅提供socket和基本的类windows api
: solution嘛，我当时想的是让客户给机器多加点内存，可惜不行啊。
|
d**********x
发帖数: 4083 | 95 恩，比如说chrome和ff的分配模式都是很类似的
大量不定长的小对象分配，夹杂着相对少量的大对象分配
解决方案我没有仔细看，但是ptmalloc肯定是不行的，类似tcmalloc的多策略分配方式
应该是较优的
这种东西如果用java来做我拍脑袋觉得overhead会很大，因为Object会占用额外的存储
空间
而特地优化过的内存池，在分配小对象，比如1-8个byte的小对象的时候，至少我知道
一种做法，可以做到近似0 overhead (本质上是8/pagesize左右）
要关
无论
东西
存用
，可
【在 s********i 的大作中提到】
:
: 为什么？碎片吗？愿闻其祥。。。
|
d**********x
发帖数: 4083 | 96 山寨机
浏览
【在 L***n 的大作中提到】
: 手机也不止这么点内存啊，是不是用微波炉上网的啊
|
P****i
发帖数: 12972 | 97 很多就是半桶水，在那里晃荡。
【在 d**********x 的大作中提到】
: 说白了就是很多人只在自己的领域里面用自己的经验说话
: mitbbs上另外一个很不好的风气就是大家都有意无意地显示出“我做的领域是最牛逼的
: ”这种气场
: 其实这里也没几个人能真的到牛逼哄哄大手一挥带几个小弟做出一个震惊世界的项目的
: 境地，干嘛不各让一步多多学习呢。。。我一直觉得开放才是码农进步的根本啊。
|
t****t
发帖数: 6806 | 98 你要知道, 芯片里每加一点内存都是成本. 面积就是成本. 能10M解决的, 就不用20M.
同样功能的东西, 你卖同样多的钱. 成本低了, 钱就是自己的. 更不用说面积大了功率
也会跟着上去.
做硬件的人思路和做软件是不一样的. 软件第一次有小毛病, 改改就行了. 硬件有小毛
病, 那就是重新流片, 代价大多了.
【在 L***n 的大作中提到】
: 手机也不止这么点内存啊，是不是用微波炉上网的啊
|
m*******l
发帖数: 12782 | 99 这个就是trade off 啊
成本和收益的比较啊
你要是产品能卖的快,卖的多,如果找普通鬼工的话,
比找贵的好的鬼工做的好,卖的贵,卖的少,
怎么算
【在 t****t 的大作中提到】
: 你要知道, 芯片里每加一点内存都是成本. 面积就是成本. 能10M解决的, 就不用20M.
: 同样功能的东西, 你卖同样多的钱. 成本低了, 钱就是自己的. 更不用说面积大了功率
: 也会跟着上去.
: 做硬件的人思路和做软件是不一样的. 软件第一次有小毛病, 改改就行了. 硬件有小毛
: 病, 那就是重新流片, 代价大多了.
|
t****t
发帖数: 6806 | 100 顶这个. 做服务器的看不起做客户端的, 说我只要加硬件就好了, 便宜着呢, 却忽视了
硬件并不是真的免费的. 做客户端的看不起做服务器的, 说尼玛写个hellow world要几
百行, 真崧, 却忽视了人家的hello world可以并发一万台机器.
说实话IT行业发展到这个地步, 每个方向的挑战是不一样的. 隔行如隔山, 真的要隔山
打牛, 这里的人实力还不到.
【在 d**********x 的大作中提到】
: 说白了就是很多人只在自己的领域里面用自己的经验说话
: mitbbs上另外一个很不好的风气就是大家都有意无意地显示出“我做的领域是最牛逼的
: ”这种气场
: 其实这里也没几个人能真的到牛逼哄哄大手一挥带几个小弟做出一个震惊世界的项目的
: 境地，干嘛不各让一步多多学习呢。。。我一直觉得开放才是码农进步的根本啊。
|
|
|
a9
发帖数: 21638 | 101 像thrust看的这么清的真不多啊。
也就做银行证券的这些人，不拿钱当事儿，雇无数人放无数服务器搞java.
逼的
目的
【在 t****t 的大作中提到】
: 顶这个. 做服务器的看不起做客户端的, 说我只要加硬件就好了, 便宜着呢, 却忽视了
: 硬件并不是真的免费的. 做客户端的看不起做服务器的, 说尼玛写个hellow world要几
: 百行, 真崧, 却忽视了人家的hello world可以并发一万台机器.
: 说实话IT行业发展到这个地步, 每个方向的挑战是不一样的. 隔行如隔山, 真的要隔山
: 打牛, 这里的人实力还不到.
|
t****t
发帖数: 6806 | 102 硅工不一样, 做一次好东西生产几百万个, 不会随便改的, 当然要精打细算. 如果乱改
, 成本太高受不了.
比如说A做了一个芯片, 他做得很快, 硅工的成本不高, 卖10块钱一个, 生产100万个,
成本5块钱. B做了一个芯片, 他做得比较好, 成本4块钱, 卖9块5. 大家马上买B的产品
. A要改, 来不及了. 改动是有成本的.
【在 m*******l 的大作中提到】
: 这个就是trade off 啊
: 成本和收益的比较啊
: 你要是产品能卖的快,卖的多,如果找普通鬼工的话,
: 比找贵的好的鬼工做的好,卖的贵,卖的少,
: 怎么算
|
m*******l
发帖数: 12782 | 103 其实我想说的是马公...
马公的产品一种是卖很多拷贝的,例如问斗死
一种是只卖几家的,或者一个坑,根据客户改一个,卖一个的那种
这些要求要产品快,成本低
,
【在 t****t 的大作中提到】
: 硅工不一样, 做一次好东西生产几百万个, 不会随便改的, 当然要精打细算. 如果乱改
: , 成本太高受不了.
: 比如说A做了一个芯片, 他做得很快, 硅工的成本不高, 卖10块钱一个, 生产100万个,
: 成本5块钱. B做了一个芯片, 他做得比较好, 成本4块钱, 卖9块5. 大家马上买B的产品
: . A要改, 来不及了. 改动是有成本的.
|
a9
发帖数: 21638 | 104 这不就是thrust说的吗，屁股决定脑袋。
乱改
产品
【在 m*******l 的大作中提到】
: 其实我想说的是马公...
: 马公的产品一种是卖很多拷贝的,例如问斗死
: 一种是只卖几家的,或者一个坑,根据客户改一个,卖一个的那种
: 这些要求要产品快,成本低
:
: ,
|
m*******l
发帖数: 12782 | 105 他说的是真正的硅工,
我说的是一部分马工是那样的,一部分不需要啊
【在 a9 的大作中提到】
: 这不就是thrust说的吗，屁股决定脑袋。
:
: 乱改
: 产品
|
t****t
发帖数: 6806 | 106 我知道你的意思. 问题是现在两种码工互相鄙视攻击, 觉得老子才是真码工, 尔等都是
没做过大项目的.
【在 m*******l 的大作中提到】
: 其实我想说的是马公...
: 马公的产品一种是卖很多拷贝的,例如问斗死
: 一种是只卖几家的,或者一个坑,根据客户改一个,卖一个的那种
: 这些要求要产品快,成本低
:
: ,
|
t****t
发帖数: 6806 | 107 码工和硅工还是不一样, 即使是做windows那样的, 还是可以经常打个补丁, 补丁摞补
丁也没有关系. 硅工上哪儿打补丁去? 顶多刷个把firmware, 能做的也很有限.
【在 m*******l 的大作中提到】
: 他说的是真正的硅工,
: 我说的是一部分马工是那样的,一部分不需要啊
|
m*******l
发帖数: 12782 | 108 确实不太一样,但是有时候补丁还是有限,
例如上面我说的哪个,要动,就要影响很多的地方,这个布丁就不好打了.
【在 t****t 的大作中提到】
: 码工和硅工还是不一样, 即使是做windows那样的, 还是可以经常打个补丁, 补丁摞补
: 丁也没有关系. 硅工上哪儿打补丁去? 顶多刷个把firmware, 能做的也很有限.
|
z****e
发帖数: 54598 | 109 php便宜
但是问题在于php只能用来做web
如果客户端html的发展不跟上
有明显的局限
不过对于买买提这种破bbs那是足够了
【在 s*****n 的大作中提到】
: 所以fb选了php:P
|
z****e
发帖数: 54598 | 110 这是理论，这会带来一系列的问题
比如接口是否存在
有些proprietary software是不提供某些语言的接口
这也很正常
然后倒腾这个接口本身也是一个很痛苦的过程
期间ide可能无法帮忙
因为很少有人这么做
这里面就有各种折腾
而且adapter是单机上的东西
一般这种情况下做integration比较合适
用eai就不需要折腾接口，或者说找一个共用的软件
比如数据库，或者一个公开的协议，比如http
会方便很多，而且decoupling
但是这样做必然会带来一个层次分离之后的效率问题
【在 m*******l 的大作中提到】
: adapter
|
|
|
g*****g
发帖数: 34805 | 111 CPU bounded的server应用其实很常见，大型项目基本上都会发现瓶颈在关系数据库服
务器上，
这个有可能是IO，也有可能是CPU。加CPU就会增加license cost，单台服务的CPU增加
也有上限。所以数据库并不是随便加CPU的，CPU bounded不罕见。
【在 n******t 的大作中提到】
: 你这个说的和你之前讲的貌似没有太大的关系。
: 我要讲的就是，硬件的速度没有大部分人认为的提高速度那么快。
: 纯粹CPU bounded的task，比例非常小。
: CPU 快了，memory没有快很多，磁盘也没有快很多，如果你要真的
: 像用上CPU快的部分，你更需要对你的资源有清楚的了解。
|
g*****g
发帖数: 34805 | 112 这个还是看应用在哪里了。04，05年左右，Google把整个index都放进内存以后，开发
的方向发生了很大的变化。Google都能把index放进内存，你的suffix tree在服务器端
一般不是问题。
【在 n******t 的大作中提到】
: 算法复杂度在简单的case里面比较一目了然。
: 复杂的情况下，时间复杂度都会受空间复杂度影响的。
: Suffix tree就是个比较好的例子。
: 而且很多时候，需要的对象集是比较特殊的状况，
: 通用的算法复杂度也是没用的。
|
g*****g
发帖数: 34805 | 113 LOL，外行又来乱评论了。你写过这种应用吗？你知道不用Java用那些语言成本更低吗？
【在 a9 的大作中提到】
: 像thrust看的这么清的真不多啊。
: 也就做银行证券的这些人，不拿钱当事儿，雇无数人放无数服务器搞java.
:
: 逼的
: 目的
|
g*****g
发帖数: 34805 | 114 你说得不错，问题是java根本不用来做这些。嫌弃java慢又从何说起。
要比，自然要比C++和Java都能做的应用层，否则完全鸡同鸭讲。
【在 t****t 的大作中提到】
: 码工和硅工还是不一样, 即使是做windows那样的, 还是可以经常打个补丁, 补丁摞补
: 丁也没有关系. 硅工上哪儿打补丁去? 顶多刷个把firmware, 能做的也很有限.
|
t****t
发帖数: 6806 | 115 你没看明白我说的是什么. 我顶的是devilphoenix的贴, 就是两拨做不同工作的码工互
相看不上. 这跟java还是C++没关系, 我也没打算比较java和c++.
【在 g*****g 的大作中提到】
: 你说得不错，问题是java根本不用来做这些。嫌弃java慢又从何说起。
: 要比，自然要比C++和Java都能做的应用层，否则完全鸡同鸭讲。
|
n******t
发帖数: 4406 | 116 我不知道什么叫做业务管理系统，好像貌似也没做过。
【在 h********3 的大作中提到】
: 一看这种说法的，就知道是没有接触过真正大数据的人，还停留在以前的业务管理系统
: 的开发层面上。以前国内圈子混过的人，谁没做过业务管理系统这些的。依此就推测别
: 人没有做过的大型项目就实在太无知了。
|
n******t
发帖数: 4406 | 117 what you are saying are commone-sense, in another words, redundant.
taken
How
【在 m********5 的大作中提到】
: ...
: Well, maybe some "big" projects in your mind are not that critical at all.
: The 算法复杂度 really matters a lot. But usually this has already been taken
: care of at the project designing phase.
: At the implementation phase, even the particular compiler matters a lot! How
: could the language choice become a trivial 杞人忧天?!
: I also believe under certain scenario and in some fields they might not be
: that important. Still you have to be arrogant enough to claim something,
: which has been studied so intensively in CS, is completely nonsense, just
: because there is no practical examples in the small puddle where you have
|
m********5
发帖数: 17667 | 118 Finally someone admit your people just talk nonsense here ...
At least someone need to remind your guys with this common-sense ...
So You are welcome!
【在 n******t 的大作中提到】
: what you are saying are commone-sense, in another words, redundant.
:
: taken
: How
|
w**z
发帖数: 8232 | 119 不是什么app 都可以靠加内存解决问题的。一个full gc 就能把整个site 搞down 。当
然你做数据分析无所谓，gc pause 几秒，估计你都不知道。如果是需要实时响应的app
,就完了。
【在 h********3 的大作中提到】
: 呵呵，我们做大数据分析的时候经常遇到你说的内存撑爆的问题。不过，我们用Java的
: 根本不会去修改什么JVM。简单一点，就是增加内存，换64位的机器。反正现在机器便
: 宜。现在我们跑个算法，用十几个G的内存很正常的。如果十几个G都不够的话，那就要
: 考虑你优化你的空间复杂度了。比如说，你用的内存对象这些，是否应该存到数据库中
: 等等。
|
g*****g
发帖数: 34805 | 120 稍微像样的网站，都不会是一个结点。一个GC当掉网站是不可能的。
对latency要求极高的GC是不行。不过这种系统比较少。基本上是
Major stock exchange这种级别的东西。
app
【在 w**z 的大作中提到】
: 不是什么app 都可以靠加内存解决问题的。一个full gc 就能把整个site 搞down 。当
: 然你做数据分析无所谓，gc pause 几秒，估计你都不知道。如果是需要实时响应的app
: ,就完了。
|
|
|
c****e
发帖数: 1453 | 121 举一个自己碰到的例子，backend storage system, 因为code的问题，small object太
多，GC开销占到了CPU的70%，有很多request drop, timeout,结果frontend更多的
retry,
最后滩了。有时候是一个instance倒下了， 但是load没有变，会加重别的instance的
负担，这是castrophic地。最后大家都一个一个的完蛋，
当然，这不是GC的问题， 而是看怎么用，怎么profile解决问题。但是系统有个极限，
是会发生最后一根稻草的情况。Throttling， auto-sharding这样东西越是到关键的时
候越是添乱。
【在 g*****g 的大作中提到】
: 稍微像样的网站，都不会是一个结点。一个GC当掉网站是不可能的。
: 对latency要求极高的GC是不行。不过这种系统比较少。基本上是
: Major stock exchange这种级别的东西。
:
: app
|
w**z
发帖数: 8232 | 122 that is exactly what happened. when response slows, users started to click
refresh, cascade through the whole cluster since we were close at the limit
even before that full gc. Of course we should have done better job
throttling.
we learned the lesson. by the way, we set heap size way too big, 40G. my
point is that big heap might not be a good choice to scale a java app. GC
is the killer to watch out .
【在 c****e 的大作中提到】
: 举一个自己碰到的例子，backend storage system, 因为code的问题，small object太
: 多，GC开销占到了CPU的70%，有很多request drop, timeout,结果frontend更多的
: retry,
: 最后滩了。有时候是一个instance倒下了， 但是load没有变，会加重别的instance的
: 负担，这是castrophic地。最后大家都一个一个的完蛋，
: 当然，这不是GC的问题， 而是看怎么用，怎么profile解决问题。但是系统有个极限，
: 是会发生最后一根稻草的情况。Throttling， auto-sharding这样东西越是到关键的时
: 候越是添乱。
|
d**********x
发帖数: 4083 | 123 说起来我也遇到过over scale的问题
大体上就是傻傻的程序员不知道系统里面到底发生了什么事情，就知道加机器，结果把
整个系统加瘫了。。。
【在 c****e 的大作中提到】
: 举一个自己碰到的例子，backend storage system, 因为code的问题，small object太
: 多，GC开销占到了CPU的70%，有很多request drop, timeout,结果frontend更多的
: retry,
: 最后滩了。有时候是一个instance倒下了， 但是load没有变，会加重别的instance的
: 负担，这是castrophic地。最后大家都一个一个的完蛋，
: 当然，这不是GC的问题， 而是看怎么用，怎么profile解决问题。但是系统有个极限，
: 是会发生最后一根稻草的情况。Throttling， auto-sharding这样东西越是到关键的时
: 候越是添乱。
|
X****r
发帖数: 3557 | 124 所以对于production的系统来说，monitoring极为重要，要能够随时方便的知道
系统的各部分的情况，比如CPU使用率，内存，IO等，以及和具体应用有关的参数。
【在 d**********x 的大作中提到】
: 说起来我也遇到过over scale的问题
: 大体上就是傻傻的程序员不知道系统里面到底发生了什么事情，就知道加机器，结果把
: 整个系统加瘫了。。。
|
w**z
发帖数: 8232 | 125 monitoring + alerting.
don't know about c++, Java comes with JMX which is great.
【在 X****r 的大作中提到】
: 所以对于production的系统来说，monitoring极为重要，要能够随时方便的知道
: 系统的各部分的情况，比如CPU使用率，内存，IO等，以及和具体应用有关的参数。
|
g*****g
发帖数: 34805 | 126 All valid points. I want to add a few in large scale server app development.
1. Set timeout and keep your timeout short. Java by default has no timeout
in blocking IO, which is always wrong on server side. Make sure you set that
. You also want to know where your 99% response time should be, and you want
to cut off not far from there. It's better to fail fast. If you are using
SOA, you need to be even more defensive since the latency can add up. For
some service, it's OK to return a default/last value.
2. Performance test and profile your app. You don't want to get to
bottleneck in your production. But you always want to know where the
bottleneck is so you can prepare. Performance testing is a must.
3. Go cloud if that's plausible. An autoscale policy can bring up more
instances for the cluster before the cluster is overloaded. The cost is much
lower than having your website down completely.
4. For ultra resiliency, test your production. Test environment can be never
100% the same as production. You want to kill a few real instances in your
production to know how reliable it is in normal operation, how well the
failover works. Or you'll get killed in a bad day. |
l*********s
发帖数: 5409 | 127 how to test the expected response time and performance ? Many thanks.
development.
that
want
【在 g*****g 的大作中提到】
: All valid points. I want to add a few in large scale server app development.
: 1. Set timeout and keep your timeout short. Java by default has no timeout
: in blocking IO, which is always wrong on server side. Make sure you set that
: . You also want to know where your 99% response time should be, and you want
: to cut off not far from there. It's better to fail fast. If you are using
: SOA, you need to be even more defensive since the latency can add up. For
: some service, it's OK to return a default/last value.
: 2. Performance test and profile your app. You don't want to get to
: bottleneck in your production. But you always want to know where the
: bottleneck is so you can prepare. Performance testing is a must.
|
g*****g
发帖数: 34805 | 128 Expected response time should be defined by SLA. You can simulate load using
tools like JMeter etc to see what's your system's bottleneck, and think
what does it take to resolve it.
【在 l*********s 的大作中提到】
: how to test the expected response time and performance ? Many thanks.
:
: development.
: that
: want
|
n******t
发帖数: 4406 | 129 不会写程序的，写monitoring tool把production system搞挂的例子不少。
【在 X****r 的大作中提到】
: 所以对于production的系统来说，monitoring极为重要，要能够随时方便的知道
: 系统的各部分的情况，比如CPU使用率，内存，IO等，以及和具体应用有关的参数。
|
z****e
发帖数: 54598 | 130 我的天哪
这种工具都有人自己去写
【在 n******t 的大作中提到】
: 不会写程序的，写monitoring tool把production system搞挂的例子不少。
|
|
|
z****e
发帖数: 54598 | 131 加机器很少会加瘫
加内存会加瘫
因为每个机器都有自己的cpu，而每一个jvm的gc都是独立的
如果加机器瘫的话，不加就更瘫了
gc的时间长短跟内存heap大小有很大关系
最常见的方式是减少heap size
或者调整虚拟机的goal，强制要求gc在某一个范围内完成
另外对于大型的应用来说，ibm等大公司都提供rts jvm
而且一般来说这个费用算在websphere这种软件里面
所以会谈的话，不需要额外算钱就可以搞定
我们就在用weblogic的jrockit，但是仅在少数系统中使用
还有另外一种优化方式就是干脆在web层抛弃java
用php，然后通过eai方式集成java系统，这样可以从根本上解决jvm的gc问题
尤其是很多小的零碎的request，这种request就不要往jvm上招呼了
过于麻烦，把request挡在web层搞定，这也是google，facebook还有新浪
等大型网络应用所采取的策略
还有就是，对于多个cpu的server，ibm什么早就有了，实在不行
把单个cpu的server卖了，换多cpu的server，但就是这种server卖得不是那么好而已
而对于cpu和内存的使用，太多工具可以用了，如果真的仅仅是因为cpu或者内存不够
要搞定不要太容易，真正难monitor的是自己写的那些东西
因为都不规范
【在 d**********x 的大作中提到】
: 说起来我也遇到过over scale的问题
: 大体上就是傻傻的程序员不知道系统里面到底发生了什么事情，就知道加机器，结果把
: 整个系统加瘫了。。。
|
z****e
发帖数: 54598 | 132 关于同一个浏览器的refresh
这个在servlet的service方法里面有一个缓冲
所以当request重复发送的时候
会被这个缓冲挡住，也就是不会因此造成更重的负担
所以理论上不应该出现更多的request才对
除非有人重写了service方法
一般新手很少会重写service方法，因为他们压根不知道有这个方法的存在
倒是一些知道一点又不知道多少的程序猿喜欢重写这个方法
只要这个方法被重写，那么refresh每一次都会造成新的request
另外浏览器本身也会对这种重复刷新的操作做一定的处理
不见得每一次都会发送request过来
所以从你的描述来看，最大的原因是gc的时候内存heap太大
而不是代码的问题
limit
my
【在 w**z 的大作中提到】
: that is exactly what happened. when response slows, users started to click
: refresh, cascade through the whole cluster since we were close at the limit
: even before that full gc. Of course we should have done better job
: throttling.
: we learned the lesson. by the way, we set heap size way too big, 40G. my
: point is that big heap might not be a good choice to scale a java app. GC
: is the killer to watch out .
|
d**********x
发帖数: 4083 | 133 嘿嘿，嘿嘿嘿
事实就是加瘫了，而且不加不会瘫
你可以说这是一个系统设计缺陷，当年没有考虑到会scale到这个程度
但是我想借此说明的是当程序员自以为这里调调那里调调就可以解决问题，而不是对系
统有了解的时候，系统就离瘫不远了
果把
【在 z****e 的大作中提到】
: 加机器很少会加瘫
: 加内存会加瘫
: 因为每个机器都有自己的cpu，而每一个jvm的gc都是独立的
: 如果加机器瘫的话，不加就更瘫了
: gc的时间长短跟内存heap大小有很大关系
: 最常见的方式是减少heap size
: 或者调整虚拟机的goal，强制要求gc在某一个范围内完成
: 另外对于大型的应用来说，ibm等大公司都提供rts jvm
: 而且一般来说这个费用算在websphere这种软件里面
: 所以会谈的话，不需要额外算钱就可以搞定
|
n******t
发帖数: 4406 | 134 为啥不自己写？？？还有你如果不了解系统，你用别人的工具一样会把系统搞死。
所以我觉得很多人只写过几种类型的系统就觉得所有系统都是这样的。
【在 z****e 的大作中提到】
: 我的天哪
: 这种工具都有人自己去写
|
l*********s
发帖数: 5409 | 135 囧！
【在 z****e 的大作中提到】
: 我的天哪
: 这种工具都有人自己去写
|
l*********s
发帖数: 5409 | 136 >__<
【在 n******t 的大作中提到】
: 不会写程序的，写monitoring tool把production system搞挂的例子不少。
|
w**z
发帖数: 8232 | 137 俺们web 层用php, 呵呵。
【在 z****e 的大作中提到】
: 关于同一个浏览器的refresh
: 这个在servlet的service方法里面有一个缓冲
: 所以当request重复发送的时候
: 会被这个缓冲挡住，也就是不会因此造成更重的负担
: 所以理论上不应该出现更多的request才对
: 除非有人重写了service方法
: 一般新手很少会重写service方法，因为他们压根不知道有这个方法的存在
: 倒是一些知道一点又不知道多少的程序猿喜欢重写这个方法
: 只要这个方法被重写，那么refresh每一次都会造成新的request
: 另外浏览器本身也会对这种重复刷新的操作做一定的处理
|
d********g
发帖数: 10550 | 138 好多公司招人专门做internal tools，当然是自己写了
【在 z****e 的大作中提到】
: 我的天哪
: 这种工具都有人自己去写
|
z****e
发帖数: 54598 | 139 自己写的代码还有什么不懂的
只有用别人的东西才会有问题
自己写的都不懂那还了得
【在 d**********x 的大作中提到】
: 嘿嘿，嘿嘿嘿
: 事实就是加瘫了，而且不加不会瘫
: 你可以说这是一个系统设计缺陷，当年没有考虑到会scale到这个程度
: 但是我想借此说明的是当程序员自以为这里调调那里调调就可以解决问题，而不是对系
: 统有了解的时候，系统就离瘫不远了
:
: 果把
|
z****e
发帖数: 54598 | 140 说的是monitoring工具
你用monitoring工具都能把系统搞死？
我不觉得所有系统都是一样的
但是我觉得一些最基本的monitoring还要自己去写，那就牛逼了
你看个内存和cpu的使用还要自己去写？我不信
【在 n******t 的大作中提到】
: 为啥不自己写？？？还有你如果不了解系统，你用别人的工具一样会把系统搞死。
: 所以我觉得很多人只写过几种类型的系统就觉得所有系统都是这样的。
|
|
|
S***s
发帖数: 104 | 141 Ops need tools to monitor server farm.
They need configurable dashboard view etc.
Developer only need simple tool like jconsole to trouble shooting one
instance.
【在 z****e 的大作中提到】
: 说的是monitoring工具
: 你用monitoring工具都能把系统搞死？
: 我不觉得所有系统都是一样的
: 但是我觉得一些最基本的monitoring还要自己去写，那就牛逼了
: 你看个内存和cpu的使用还要自己去写？我不信
|
z****e
发帖数: 54598 | 142 这里调整那里调整是建立在结构合理的基础之上
结构都错了，那还谈什么
这种问题一般我不会碰到
倒是鼓吹说小系统用这个，大系统用那个的人
极有可能遇到
【在 d**********x 的大作中提到】
: 嘿嘿，嘿嘿嘿
: 事实就是加瘫了，而且不加不会瘫
: 你可以说这是一个系统设计缺陷，当年没有考虑到会scale到这个程度
: 但是我想借此说明的是当程序员自以为这里调调那里调调就可以解决问题，而不是对系
: 统有了解的时候，系统就离瘫不远了
:
: 果把
|
d**********x
发帖数: 4083 | 143 结构合理啊
并发访问量能达到amazon.com的量级，我觉得结构还是没有什么不合理的
要我再强调一遍吗？我只是给某些自大的不重视细节的人提个醒。你要是觉得和你有关
系，那就有关系，你要是觉得和你没关系，就没关系，没必要一个帖子回两遍还不着边
际的
【在 z****e 的大作中提到】
: 这里调整那里调整是建立在结构合理的基础之上
: 结构都错了，那还谈什么
: 这种问题一般我不会碰到
: 倒是鼓吹说小系统用这个，大系统用那个的人
: 极有可能遇到
|
z****e
发帖数: 54598 | 144 “当年没有考虑到会scale到这个程度”
然后现在说
“结构合理啊”
阁下的结构合理就是能跑就行了是吧？
不奇怪，很多人的结构合理也就是这么个标准
【在 d**********x 的大作中提到】
: 结构合理啊
: 并发访问量能达到amazon.com的量级，我觉得结构还是没有什么不合理的
: 要我再强调一遍吗？我只是给某些自大的不重视细节的人提个醒。你要是觉得和你有关
: 系，那就有关系，你要是觉得和你没关系，就没关系，没必要一个帖子回两遍还不着边
: 际的
|
d**********x
发帖数: 4083 | 145 哦，怪我没说明白。
首先不overscale，是可以正常运作的，不会出问题，latency也不会增加
问题是有些神经紧张的、不了解系统的人一看下面要有traffic了就往上猛加机器，结
果加挂了
而且如果你对程序结构没问题的定义是能够应付任何状况，那只能说明你就是一……
当然我现在跟你说什么都是没有用的，你也是常有理，绝对牛
【在 z****e 的大作中提到】
: “当年没有考虑到会scale到这个程度”
: 然后现在说
: “结构合理啊”
: 阁下的结构合理就是能跑就行了是吧？
: 不奇怪，很多人的结构合理也就是这么个标准
|
z****e
发帖数: 54598 | 146 没有八
我没有把问题往极端了想
都是你说的，我稍加整理后发出来
也没有添油加醋
你看看什么让人兴奋的副词修饰
比如“神经紧张”，比如“猛加”
这都是你在用，然后说我常有理
这个实在是不敢当
至少我不会随便推测别人不懂
我总是assume别人懂
【在 d**********x 的大作中提到】
: 哦，怪我没说明白。
: 首先不overscale，是可以正常运作的，不会出问题，latency也不会增加
: 问题是有些神经紧张的、不了解系统的人一看下面要有traffic了就往上猛加机器，结
: 果加挂了
: 而且如果你对程序结构没问题的定义是能够应付任何状况，那只能说明你就是一……
: 当然我现在跟你说什么都是没有用的，你也是常有理，绝对牛
|
g*****g
发帖数: 34805 | 147 traffic都没上来，加机器就能加挂了，结构当然不合理。至少也是说明测试不充分。
【在 d**********x 的大作中提到】
: 哦，怪我没说明白。
: 首先不overscale，是可以正常运作的，不会出问题，latency也不会增加
: 问题是有些神经紧张的、不了解系统的人一看下面要有traffic了就往上猛加机器，结
: 果加挂了
: 而且如果你对程序结构没问题的定义是能够应付任何状况，那只能说明你就是一……
: 当然我现在跟你说什么都是没有用的，你也是常有理，绝对牛
|
c****e
发帖数: 1453 | 148 基本的monitor看起来简单，但是大系统还是自己开发的居多，配些Agent读counter只
是很小的一部分工作。其实基本的counter,log/tracing，alert这些还不是很麻烦。麻
烦的是diagnostic,这个也是monitoring绑在一起的。
比如Alert来了E2E latency 75th pecential涨了200%, 怎么才能快速找到问题？Real
time的log search, end to end tracing， dump analysis这些才是重点。而且数据大
了，快速的aggregation也很有挑战。
再发散一点，发现了问题，快速搞定才是王道。一般来说code to production还是比较
慢的。configuration做的比较好就可以很快的migrate.
回到monitoring把自己搞死，是完全可以想象的。如果self-monitoring做的不好，
monitoring agent本身消耗的资源太多，就会影响service本身的运行。比如有人issue
一些interactive的log query,这些会被break down到很多机器的agent上执行，如果这个
query非常消耗资源。。。
【在 z****e 的大作中提到】
: 说的是monitoring工具
: 你用monitoring工具都能把系统搞死？
: 我不觉得所有系统都是一样的
: 但是我觉得一些最基本的monitoring还要自己去写，那就牛逼了
: 你看个内存和cpu的使用还要自己去写？我不信
|
c****e
发帖数: 1453 | 149 Partition move引起的？ 我碰到过的加机器太猛出现的问题和auto-sharding有关系。
Controller一看cold的机器很多，就开始split partition, 然后由于design的问题，
partition move的时候lock了很多资源，太多partition一起动，就SB了。虽然最后也
能自己回来， 但是太长时间很多partition offline,对于前台来说，更挂了没区别。
虽然理论上任何问题都有很多解决方案，实际上由于资源，开发团队的种种限制，要出
一些看起来很傻的错误，太容易了。特别是系统开发的初期。
【在 d**********x 的大作中提到】
: 哦，怪我没说明白。
: 首先不overscale，是可以正常运作的，不会出问题，latency也不会增加
: 问题是有些神经紧张的、不了解系统的人一看下面要有traffic了就往上猛加机器，结
: 果加挂了
: 而且如果你对程序结构没问题的定义是能够应付任何状况，那只能说明你就是一……
: 当然我现在跟你说什么都是没有用的，你也是常有理，绝对牛
|
g*****g
发帖数: 34805 | 150 平均分配都是没经验的。一般的做法都是原来的不动，load balancer把新request 扔
到Load最低的结点即可。这说的是app server。
对于DB，加结点由于复制确实会影响性能，所以一般都要找人少的时候弄。
【在 c****e 的大作中提到】
: Partition move引起的？ 我碰到过的加机器太猛出现的问题和auto-sharding有关系。
: Controller一看cold的机器很多，就开始split partition, 然后由于design的问题，
: partition move的时候lock了很多资源，太多partition一起动，就SB了。虽然最后也
: 能自己回来， 但是太长时间很多partition offline,对于前台来说，更挂了没区别。
: 虽然理论上任何问题都有很多解决方案，实际上由于资源，开发团队的种种限制，要出
: 一些看起来很傻的错误，太容易了。特别是系统开发的初期。
|
|
|
c****e
发帖数: 1453 | 151 app server要简单一些。我们的是data store, partition会根据key的distribution
split.一旦开始partition split的过程，新的request根据不同的操作会被redirect旧
的或者新的node,但是旧数据的还是需要copy.主要是很多metadata server上的update
带了很多lock.
【在 g*****g 的大作中提到】
: 平均分配都是没经验的。一般的做法都是原来的不动，load balancer把新request 扔
: 到Load最低的结点即可。这说的是app server。
: 对于DB，加结点由于复制确实会影响性能，所以一般都要找人少的时候弄。
|
n******t
发帖数: 4406 | 152 你自己看看你当时发的贴有多二先,感觉写监控模块的情况着这辈子和下辈子都不会遇
到的样子。你还说你有大型系统的开发经验？？lol
~~~~~~~~~~~~~~~~~~~~
我貌似目前没有过。你这种人还真有可能。
【在 z****e 的大作中提到】
: 说的是monitoring工具
: 你用monitoring工具都能把系统搞死？
: 我不觉得所有系统都是一样的
: 但是我觉得一些最基本的monitoring还要自己去写，那就牛逼了
: 你看个内存和cpu的使用还要自己去写？我不信
|
g*****g
发帖数: 34805 | 153 大点的公司，这个模块是必然有的。但通常都是专门的team写的，同时有很多第三方的
类库专门干这个，特别是显示到dashboard上。做应用开发的，基本上只需要调用写的
API就行了。或者直接实现成MBean，通过JMX来获取数据。他没写过也不奇怪。
【在 n******t 的大作中提到】
: 你自己看看你当时发的贴有多二先,感觉写监控模块的情况着这辈子和下辈子都不会遇
: 到的样子。你还说你有大型系统的开发经验？？lol
:
: ~~~~~~~~~~~~~~~~~~~~
: 我貌似目前没有过。你这种人还真有可能。
|
w**z
发帖数: 8232 | 154 俺们用Ganglia +Nagios, 自己加mbean, 读jmx populate graph.
【在 g*****g 的大作中提到】
: 大点的公司，这个模块是必然有的。但通常都是专门的team写的，同时有很多第三方的
: 类库专门干这个，特别是显示到dashboard上。做应用开发的，基本上只需要调用写的
: API就行了。或者直接实现成MBean，通过JMX来获取数据。他没写过也不奇怪。
|
