如果您有一个运行缓慢且内存不足的工作产品。
在这两个选项之间会决定做什么,为什么?
- 如果您购买 5 位甚至 6 位高的“优质”服务器,该产品将完美运行。
- 您拥有更改它的资源和资源,解决问题的成本与选项 1 大致相同,但可以让您获得 4 位数的服务器。
如果您有一个运行缓慢且内存不足的工作产品。
在这两个选项之间会决定做什么,为什么?
I vote 2, simply because a year from now, when your product is more heavily used, crunches more data, and requires more resources, you'll not be wanting to buy a bigger server yet again.
And there could come a time where where it isn't possible to get bigger hardware.
I'd take #1 because I can guarantee you that #2 would actually end up taking longer and costing at least 5 times more then you think :-)
Profile it and rewrite or update the slower sections (bottlenecks). Do not rewrite the entire code base. This approach should get you the best bang for the buck while solving your challenges.
几个问题:
如果第一个问题的答案是“新服务器在一年内还不够强大”,那么您将不得不优化您的应用程序。
如果对“它要花多少钱”的回答真的很高......好吧,我让你猜猜我在想什么;-) 一切都取决于对前一点的回答。
如果不知道该问题的答案,将很难为您提供帮助。
我的建议是:尽你所能优化,不要重写——这至少会给你一些时间;那么,您将能够不着急地思考。
这将允许您进行更好的重写,并且生成的应用程序会更好——并且可能会更好地扩展,如果您认为您将拥有更多用户,这一点非常重要。
所以 :
As you are implying that the cost is the same then a next thing to consider is the time to deliver.
1 Can probably be implement in a shorter time than 2 (If the cost of building 2 is 5 or 6 digits then it will be a significant time).
There would also be a benefit in getting the project in earlier.
Agaist this if you expect to enhance the system in future and it have a long life then improving the product could cut maintainence costs.
It has to be number 2 because you are only deferring any issues until you run out of money.
Saying that, what's the bottleneck? Quick fixes:
As is usually the case "it depends". Usually, a business owner will move in the direction of maximizing profit, but only after careful risk and impact analysis. The correct decision is influenced heavily by a number of factors:
What minimizes cost? A 6-digit mainframe may not be less expensive than the 6-digit development effort to re-write existing code.
How much improvement do you need? For most CPU and memory bound applications, you can't really expect a speedup of more than 5x simply by throwing more hardware at the problem. For certain classes of problems, well-written data structures and algorithms can improve the runtime of an application literally millions of times faster.
What minimizes risk? Re-writing legacy code is a guaranteed, time-tested, proven way to write new bugs into existing software.
How much scalability do you need? Some computations can be written in a way that small parts of the computation can be distributed across multiple servers, effectively allowing you to scale computations linearly by adding more hardware. It takes careful planning to write software in this way --- and if scalability wasn't part of the game plan from the very beginning, then almost certainly you'll need to re-write your code.
There's no good answer to your question without knowing more about your individual situation.
Since the price for both is the same (how about time ?) i would fix/develop (2) because you'll have more control over your sw. On the other hand since most programmers underestimate development time and costs this might it might be illusionary to fix the thing in time.
if the performance degrade is directly proportional to the problem space then rewrite might be your only option.
Hardware changes have a mostly linear benefit. If you can really ride the Moore law, the it can be almost exponential, for a while. Eventually you hit a non-Moore factor (like buget, or cooling requirements) and drop to linear.
Rewriting, if done well, will change the behavior, not just the performance. If your current software has geometric behavior (like O(n^2)), you'll need geometrically better hardware as you grow. If you get linear behavior (like O(n)), you'll have a lot more headroom to grow.
If this is an in-house application, then go with option 1. The costs are the same for both options, but you get your app in place now. Meanwhile, hardware costs keep going down; soon your 5-6 digit server is going to be a 4-digit server.
If it's something you ship to users, option 2 sounds more credible, but it depends on how quickly you need to ship, versus how much your users are willing to spend on server equipment.
Depends on where the bottlenecks are. I wouldn't make this decision without knowing that first. Faster, better equipment may not solve your problem if the problem is poor design or badly written queries and then where are you after having spent the whole budget?
Not black or white, one or two. I think you should optimize where you find low hanging fruits and buy hardware where the optimization is hard. You should not choose, but find the balance.
I tend to favor alternative 2, partly because I think it is fun, partly because there might be other good side effects, like better response times.
You should also consider your architecture if you can distribute your application on many servers, then you might cope with two cheap servers instead of one really expensive.