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

Question

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)

Even 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?

Answer 1

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.