How to solve hardware rewrite or update?

If you had a working product that was slow and memory hungry.

What will decide between these two options and why?

  • The product will work just fine if you buy a "good" server with 5 digits and possibly 6 digits.
  • You have sources and resources to change it, and it will cost about the same option 1 to fix the problems, but will allow you to get the server in 4 digits.
+2


source to share


13 replies


I'll vote 2, simply because a year from now, when your product is used more, crunches more data and requires more resources, you won't want to buy a larger server anymore.



And there may come a time when it is impossible to get more equipment.

+8


source


I would take # 1 because I can guarantee that # 2 will actually take longer and cost at least 5x more than you think :-)



+3


source


Profile it and rewrite or upgrade slower partitions (bottlenecks). Don't rewrite your entire codebase. This approach should give you the best bang for the buck in your tasks.

+3


source


A couple of questions:

  • What happens if you need an even more powerful server over time because your application gets more users?
    • Could this happen?
  • How much does it cost to rewrite an application?

If the answer to the first question is that "the new server won't be powerful enough in one year," you will need to optimize your application.

If the answer to the question "how much does it cost" is really a lot ... Well, I let you guess what I find ;-) It all depends on the answer to the previous point.

Without knowing the answer to this question, it will be very difficult for you to help.


My suggestion would be: optimize whatever you can without rewriting - this will at least give you some time; you will be able to think slowly, then.

This will allow you to rewrite better, and the resulting application will be much better - and will probably scale better, which is very important if you think you will have more users.

So:

  • Optimization
  • Take time to think
  • Rewrite, think about optimization, scaling and maintenance.
+2


source


As you mean the cost is the same, the next thing to consider is the delivery time.

1 Possibly can be sold in a shorter time than 2 (if the cost of building 2 is 5 or 6 digits, it will be significant time).

It would also be helpful to get the project earlier.

Agitate this if you expect to improve the system in the future and it will have a long life, then improving the product can reduce maintenance costs.

+2


source


It should be number 2 because you only put off any problems until you run out of money.

What is this bottleneck? Quick fixes:

  • disk configuration (e.g. SCSI 15K RAID 10, faster controller)
  • More RAM (always useful for database boxes)
  • 64-bit OS / recompile
  • Add a processor (not for your code, maybe, but to run other tasks in the field)
+2


source


As usual, "it depends". Typically, a business owner will move towards maximizing profits, but only after careful risk and impact analysis. The correct decision is largely influenced by a number of factors:

  • What will minimize the cost? A 6-bit mainframe can be as costly as a 6-bit development effort to rewrite existing code.

  • How much needs to be improved? For most CPU and memory related applications, you cannot expect more than 5x speedup by simply throwing more hardware into the problem. For certain classes of problems, well-written data structures and algorithms can improve application execution times literally millions of times faster.

  • What minimizes the risk? Re-writing legacy code is a guaranteed, time-tested, proven way to write new bugs into existing software.

  • How much scalability is required? Some computation can be written so that small portions of the computation can be distributed across multiple servers, allowing you to scale the computation linearly by adding more hardware. This requires careful planning to write software in this way --- and if scalability was not part of the game plan from the start, then you will almost certainly need to rewrite your code.

There is no good answer to your question without knowing more about your individual situation.

+2


source


Since the price is the same for both (what about timing?) I would fix / develop (2) because you will have more control over your sw. On the other hand, since most programmers underestimate the development time and cost, it may be illusory to correct the situation in time.

+1


source


if the degradation in performance is directly proportional to the problem space, then rewriting may be your only option.

0


source


Hardware changes are of primary benefit. If you can really ride Moore's Law, it can be almost exponential for a while. Eventually you find yourself in a factor not related to Moore (for example, requirements for big, or for cooling) and go to linear.

Overwriting, if all goes well, will change behavior, not just performance. If your current software has geometric behavior (e.g. O (n ^ 2)), you will need geometrically better hardware as you grow. If you get linear behavior (like O (n)), you have a lot more room to grow.

0


source


If this is an internal application, go to option 1. The cost is the same for both options, but now you get your application. Meanwhile, equipment costs continue to decline; soon your 5-6 digit server will be a 4 digit server.

If it's something you're sending to users, option 2 sounds more plausible, but it depends on how fast you need to send versus how much your users are willing to spend on server hardware.

0


source


Depends on where the bottlenecks are. I would not make this decision without knowing it in the first place. Faster, better hardware might not solve your problem if the problem is due to poor design or poorly written queries, then where did you spend your entire budget?

0


source


Not black or white, one or two. I think you should optimize where you find low hanging fruit and buy hardware where optimization is tricky. You don't have to choose, but find a balance.

I prefer alternative 2, partly because I think it's fun, and partly because there might be other good side effects, such as better response times.

You should also consider your architecture, if you can distribute your application across many servers, then you can deal with two cheap servers rather than one really expensive one.

0


source







All Articles