Spaghetti php code performance and scalability compared to mvc/oop?

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

The application code in almost every file is a mix of html, sql and php(what you call spaghetti), except in a few files that are pure php include files....for example a file containing functions that are needed in many other places.

I have been considering whether it's a good idea to refactor this application to a mvc type architecture.

Now i know that a mvc application offers plenty of advantages like ease of maintenance, reuse and ease of further development etc but what about scalability and performance - specifically in this case ?

My assumption is that since this is a small application(i believe so, do you think it's small enough?), i don't envision having a hard time with maintenance or adding a few more features(at the max) which just may mean a few additions in existing files or maybe say addition of a maximum 5-10 new files.

So i am thinking i shouldn't be converting to mvc just for maintenance sake.

As far as i understand you may put each component of mvc on a separate server to spread the load so as to have a different server serving html, database and logic and do other optimization/caching further as well to make a hich is mvc application scale and perform.

I think even though in a small spaghetti application we cannot have different servers for html, database etc we can easily scale without degrading the performance by having a load balancer in front of web servers, databae server etc.(Supposing it comes to a situation where one server is not enough)

E开发者_JAVA技巧ven more so on it's own the spaghetti code should perform better than mvc, since it doesn't have any overheads like requiring includes or files or function calls from files placed under folders belonging to a different component of the mvc.

So, considering all these things do you really think it's useful to refactor a relatively small spaghetti application to mvc for scalability and performance?

Please don't tell me that refactoring will be useful in future (i know that will help and will consider if 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 a mvc architecture for scalability and performance ?

2)Can a spaghetti application like this scale and perform for atleast a minimum of 1 million request a day and half of which occur during some peak time?

As far as i understand you may put each component of mvc on a separate server to spread the load

I've never heard that myself - but I come from a .Net world where you'd run all your managed code on the same server anyway (it's not like in the Java world where you often have a separate "App" server and "Web" server).

The main reason you'd probably move to MVC (just as you mentioned) is for benefits in managing the code: separation of concerns, re-use, etc; not performance.

In theory you could do this with object / component based technologies like Java or .Net where the components communicate with each other - but in procedural code? i don't think so!

So, considering all these things do you really think it's useful to refactor a relatively small spaghetti application to mvc for scalability and performance?

No - assuming by scalability and performance you're refering to runtime qualities of the system, which I believe is what you meant.

If you put scalability and performance purely into the context of development (people coding - how fast and easily they can work on the system, how easily you can add developers to the project) then the answer would be yes.

2)Can a spaghetti application like this scale and perform for atleast a minimum of 1 million request a day and half of which occur during some peak time?

Nothings impossible - I love Gordons comments along those lines - but as I'm sure you'd agree, it's probably not the best footing you could be on.

No, you don't have to convert because with an infinite budget any application will scale infinitely. Just add more servers. The question is, do you have an infinite budget? If you dont have an infinite budget, find out what is cheaper: add more hardware or optimize code.

So the real answer is: maybe.

We cannot tell you what it takes for your application to reach your scalability goals. We don't know what it does, nor do you provide hard limits for the desired performance. For instance, how long may a request take until it is served? Run ab or Siege and measure your Status Quo. Run a profiler on your code and identify bottlenecks. Find out whether you are IO, CPU or RAM bound. Are you using an Opcode cache? Take all your findings and make an educated guess about cost. Then decide how to optimize.

There will be a point where the effort required to shed some microseconds is higher than simply adding better or more hardware. In practise, you will likely use a mixed strategy to find the most scalable and affordable solution for your needs.

Note that refactoring a big ball of mud into a pristine OOP application does not necessarily mean it will run faster afterwards. In fact, the more loosely coupled, the more indirection, the more layers, the slower the application will likely become. It's a tradeoff for better maintainability. Maintainbility is a cost saver too. It will cut down on your time to deliver new features.

1. Yes
2. No

50+ files is not small. Spaghetti code is unmaintainable and highly inefficient, so there is no performance advantage over a proper framework. Finally, a good framework offers well-designed, well-tested, and constantly updated plugins to achieve most common tasks, reducing the amount of code that you have to write and maintain yourself.

Back in 1995 high-traffic sites were running tangled messes of spaghetti-code. Today, you shouldn't even think about running a high-traffic site (or any kind of site!) on spaghetti code.