Spaghetti code performance and scalability compared to mvc / oop?

Question

I have a php application that contains about 50-55 code files. A file with a maximum amount of code has about 1200 lines of code (this includes spaces, tabs, and several line breaks ...), and the rest of the code files are relatively smaller than this.

The application code in almost every file is a combination of html, sql and php (what you call spaghetti), with the exception of a few files that contain files with pure php include ... for example, a file containing functions that are needed in many others places.

I am considering the appropriateness of reorganizing this application into an architecture like mvc.

Now I know that the mvc application offers many advantages, such as ease of maintenance, reuse and ease of further development, etc., but what about scalability and performance - especially in this case?

My assumption is that since this is a small application (I suppose that you think it is small enough?), I don’t assume that it’s difficult for you to work or add a few more functions (maximum) that just might mean a few add-ons to existing files or possibly add a maximum of 5-10 new files.

So, I think that I should not convert to mvc just for the sake of service.

As far as I understand, you can put each mvc component on a separate server to distribute the load, to have a different server serving html, database and logic, as well as do other optimization / caching to do this mvc and execute.

I think that although in a small spaghetti application we cannot have different servers for html, databases, etc., we can easily scale without sacrificing performance, having a load balancer in front of web servers, databae server, etc. d. (Suppose this is a situation where one server is not enough)

Moreover, spaghetti's own code should work better than mvc, since it does not have any overhead, such as a requirement, that includes either files or function calls from files located under folders belonging to another mvc component.

So, with all these things in mind, do you really think it is useful to reorganize a relatively small spaghetti application in mvc for scalability and performance?

Please do not tell me that refactoring will be useful in the future (I know this will help and consider whether we really need to add much more code to the existing code base), but please provide me with a clear answer to

1) Do I really need to convert this application to mvc architecture for scalability and performance?

2) Can a spaghetti application use this scale and execute at least 1 million requests per day, and half of which occurs during some peak time?

Answer 1

As far as I understand, you can put each mvc component on a separate server for load distribution

I never heard about it myself, but I came from the .NET world, where you ran all the managed code on the same server anyway (this is not like the Java world, where you often have a separate “application”, server and “Web” ").

The main reason you are likely to upgrade to MVC (as you mentioned) is the benefits of code management: separation of problems, reuse, etc .; no opportunity.

In theory, could you do this using object / component based technologies like Java or .Net, where the components interact with each other, but in procedural code? I do not think so!

So, with all these things in mind, do you really think it is useful to reorganize a relatively small spaghetti application in mvc for scalability and performance?

No - assuming scalability and performance, you refer to the quality of the system, which, I think, means what you had in mind.

If you give scalability and performance exclusively to the development context (people code how quickly and easily they can work in the system, how easily you can add developers to the project), then the answer is yes .

2) Can a spaghetti application use this scale and execute at least 1 million requests per day, and half of which occurs during some peak time?

Nothing is impossible - I love Gordons' comments on these lines, but, I am sure you will agree, this is probably not the best basis on which you could be.

Answer 2

No, you do not need to convert, because with an infinite budget, any application will scale indefinitely. Just add more servers. The question is, do you have an infinite budget? If you don’t have an infinite budget, find out which is cheaper: add more equipment or optimize the code.

So the real answer is: possible.

We cannot tell you what it takes to make your application reach your scalability goals. We do not know what it does, and you do not set hard limits for the desired performance. For example, how long can it take before it is submitted? Run ab or Siege and measure the status quo. Run the code profiler and identify bottlenecks. Find out if you are associated with IO, CPU or RAM. Do you use Opcode cache? Take all your conclusions and make a reasonable guess about the cost. Then decide how to optimize.

There will be a point at which the effort required to lay a few microseconds is higher than just adding better or more hardware. In practice, you are likely to use a blended strategy to find the most scalable and affordable solution for your needs.

Note that refactoring a large ball of dirt in a primitive OOP application does not necessarily mean that it will run faster after that. In fact, the more loosely coupled, the more indirect, the more layers, the slower the application will be. This is a compromise for better maintainability. Maintenance is also cost saving. This will reduce your time to provide new features.

Answer 3

• Yes
• No

50+ files are small. The spaghetti code is uncontrollable and very inefficient, so there is no performance advantage over the proper structure. Finally, a good structure offers well-designed, tested, and constantly updated plugins to achieve the most common tasks, reducing the amount of code you need to write and maintain.

In 1995, messy spaghetti code packages were confused on high-traffic sites. Today you don’t even have to think about launching a site with high traffic (or any other site!) According to the spaghetti code.