DharkPoet:
Hi fellow devs, so I've been coding for sometime now, and one thing I've always failed to cater for was consideration for scaling. How to set up infrastructure for scaling.

Should one consider scaling from the onset, or should one start thinking of scaling only when the requests grow to (tens of)thousands of req/sec.

What are the best ways to effectively achieve scaling a PHP app on a LAMP infrastructure?

I would really love to get your feedback.

Thanks.

bearnana:

But first off, if you are thinking of scaling at this early stage, THINK OF YOUR CODEBASE!!!

DanielTheGeek:
Nope, think of your user base..
Nice write up, I only disagree with the listing of MyIsam/InnoDB as database types, those are database engines not types.

Welcome to Nairaland @bearnana

paranorman:
Been eons since I had to read something as enlightening as this on NL p-section.

DanielTheGeek:
It depends on budget and time, if you're building an app that needs to get to the market as quickly as possible, then it's okay to leave scalability till when it is needed but however your code base should be optimized, you should move to a VPS and fine tune your application so you can be certain you've done everything app wise to make sure your application is a bit scalable, then you'd want to enable caching for static pages on your web app and also serve static pages via an Nginx server (its faster cor static pages) and also add a simple load balancer in front of your Servers... This little technique I stated can help your app survive it's first few thousand users...when you get to the next slow point you'd know what to do...
You may want to consider a separate database for reading data and another database for writing data, a data recycle action will be performed by your database platform..this technique can buy you some more breathing space...

Next you may consider either horizontal or vertical scaling...
Vertical scaling is simply adding more powerful hardware resources as the need to scale increases. This seems like the way to go for the lazy and rich programmer who doesn't want anything too complicated. Simply upgrade your resources and the app scales well.
Imagine having a server serving the web app in question. The server has 4GB of RAM, an i5 CPU, and a 1TB HDD. It performs its function well, but to better tolerate a higher influx of traffic, you decide to replace the 4GB of RAM with 16GB, you put in an i7 CPU, and you add a PCIe SSD/HDD Hybrid drive. The server is now much more powerful and can handle a higher load. This is known as vertical scaling

Horizontal scaling means adding more zombie servers and distributing requests through those servers, the server with lesser load receives the next request and once it can no longer handle any more requests another server picks up... This option is the go to option for the developer that can't afford to horizontally scale his app or thinks he'll benefit more from vertical scaling.

However, the best thing is to scale both Horizontally and Vertically. The need for your app to scale means that you have lots of users which means you're making money and so affording to scale shouldn't be a problem. The problem is people try to scale apps that may not even last two years on the internet.

bearnana:
I don't think scalability of applications is much about performance.

Its more about how to manage, if a lot of hands were to get on deck.

To explain my point I'd share a personal experience since you are talking PHP:
I worked on an application where the devs who handled the code before used procedural and the client wanted to build a Software Department to manage the application. It was difficult to understand the application and the variable types the devs before had done. So we were tasked to build the application from ground up in a very short space of time.

Some rules I have learnt in my short time on this coded planet.

1: Your application won't scale if it wasn't designed to scale. i.e. Don't use procedural if your application would one day have a very large number of users and would have a software department.

2: Simple Architecture is good if you are starting i.e Try to optimize your code base for speed (this is different fro performance; your code performs and your code performs fast are two different things. Every codebase is designed to perform, not all codebase is designed to perform fast...)

3: Think about database type. Since you mentioned LAMPP, I am assuming that you are using MYSQL for backend. It may not be as important as the first two rules when starting out but you would have to consider database engine type ISAM, MyISAM, InnoDB.

These are the ones I can think off the top of my head. The other ones are when you have reached about 500k users. You might want to think of load balancers and redundant firewalls, maybe more webservers for performance. By then you would also have to factor splitting your database read and writes. Before you get to this stage, there should be enough money to hire me to help you out...

But first off, if you are thinking of scaling at this early stage, THINK OF YOUR CODEBASE!!!

simiolu1:
First off, scaling is majorly about 3 things

1. Your codebase.

Is your software efficient? Can you squeeze a little more juice out of it by refactoring? Are you using queues in the right places? Anything that can be delayed until a later time should be queued. Examples include transactional e-mails like Password resets, invoice recepits etc. If you are transcoding audio files or video files; abeg use a queue to do that then send notifications to the user when it is done (Facebook does this when you upload videos). If your users are uploading files and you are storing those files in the cloud using Dropbox, S3, G Cloud, Cloudinary etc, find a way to make sure those files are being uploaded to the cloud straight away instead of them being stored on your server first before being moved to the cloud. If you are using an MVC framework or architecture, make sure your controllers are not doing too much or everything. Make use of traits and services.

2. Your infrastructure. I don't think you would want to build a software and scale it using a shared hosting solution. Get a cloud service for your infrastructure. DanielTheGeek has talked about that.
However, from my experience using AWS Elastic Load Balancers, you can configure an auto-scaling group that would scale your servers based on traffic. You can configure your group to have at least 2 servers running (the best configuration) and the load balancer routes requests to each one simultaneously in such a way that one server is not overworked at the expense of another.

3. Your database. I would not like to go into database engines and the best one for your software but to scale your DB, cache the most frequent queries your users have. Memcached and Redis are the best in this category. Caching reduces the number of queries hitting your database and allows your DB to rest a little. Then have more than one DB server running. You would then set a time of the day when you generally have reduced traffic that these DBs would sync.

bearnana:
I don't think scalability of applications is much about performance.

Its more about how to manage, if a lot of hands were to get on deck.

To explain my point I'd share a personal experience since you are talking PHP:
I worked on an application where the devs who handled the code before used procedural and the client wanted to build a Software Department to manage the application. It was difficult to understand the application and the variable types the devs before had done. So we were tasked to build the application from ground up in a very short space of time.

Some rules I have learnt in my short time on this coded planet.

1: Your application won't scale if it wasn't designed to scale. i.e. Don't use procedural if your application would one day have a very large number of users and would have a software department.

2: Simple Architecture is good if you are starting i.e Try to optimize your code base for speed (this is different fro performance; your code performs and your code performs fast are two different things. Every codebase is designed to perform, not all codebase is designed to perform fast...)

3: Think about database type. Since you mentioned LAMPP, I am assuming that you are using MYSQL for backend. It may not be as important as the first two rules when starting out but you would have to consider database engine type ISAM, MyISAM, InnoDB.

These are the ones I can think off the top of my head. The other ones are when you have reached about 500k users. You might want to think of load balancers and redundant firewalls, maybe more webservers for performance. By then you would also have to factor splitting your database read and writes. Before you get to this stage, there should be enough money to hire me to help you out...

But first off, if you are thinking of scaling at this early stage, THINK OF YOUR CODEBASE!!!

DharkPoet:

Quick question, how does one implement queues say in PHP?

DharkPoet:

Lol!!! Who knows, I could have been the one who wrote it in procedural. Well, for sometime now, I've been battling picking up OOP as a concept, don't get me wrong, I understand the fundamentals but I've not been able to implement them, I think one of the reasons is due to the fact that I've not really embarked on any project that would make me use OOP (or maybe I'm just comfortable of this status quo).

This has made me not to pick up any PHP framework, a part of me feels I need to master OOP to an extent I'm order to start using any Framework. (Correct me if I'm wrong.)

Maybe one day I'd hire you, though I'd like to work with you. (Yeah, nobody wants to work with a rookie, I get)

simiolu1:


Unfortunately, that question is beyond the scope of this thread. Also, I cannot give you a comprehensive anser just like that. Google it, visit stack overflow and different blogs. By the time you read 10blog posts and try a few times, you would get it.

Lol, I once had problem with javascript for a payment gateway, I went as far as talking/sharing my code with a professional developer in europe and the embarassing response I got from him made me sit up...

Sometimes being naughty has a way of passing the right knowledge.

simiolu1:


I want to disagree a little with some things you wrote.

In the perfect developer world, everyone writes OOP, deploys with Git and can set up AMP on a Linux server from scratch. In reality, a lot of developers still write spaghetti code, have never hosted outside shared hosting, don't know how to use git and have never even set up AMP talkless of using SSH.

My point is that we should allow people to learn and outgrow things. Believe me, when a developer grasps OOP, no one would tell him or her to drop spaghetti code. Then he or she would start to wonder how dumb they were coding like that in the first place. Saying that spaghetti code can't scale is not entirely true. It can if you scale out the infrastructure but one day while writing a new feature, someone is going to break.something.

I signed up on Twitter late 2008 and back then, the service broke almost every day. Instagram in its early days broke a couple of times too. But those people and teams learnt from those mistakes. I once heard Jan Koum (the CEO) of WhatsApp say that the only reason why WhatsApp has been stable was that the two founders were former employees of Yahoo who had experienced how to scale a digital product at Yahoo.

Scaling a product is hard; only a few developers would get to do it in their lifetimes. A lot of those would make mistakes when doing it for the first time. They would learn from it and move on.

DharkPoet:
I was beginning to lose hope, when I saw the views without the replies. Y'all remain blessed!!! Thanks Fam.

DanielTheGeek:


Even YouTube was shitty at some point, it started out with PHP and now runs on Python, Java and Go with BigTable and MariaDB as databases of choice.


Note: YouTube's switch over from PHP doesn't mean a YouTube kinda site can't survive on PHP. There's HHVM, and stats show that Facebook is nearing YouTube on video uploads and playbacks.

bearnana:


I think I mentioned that MyIsam/InnoDB are database engine types.
If you don't consider your codebase I wonder how developers would work on it to manage better performance.

Thanks for the welcome.

bearnana:


Wow. Didn't know Youtube, started out with PHP. I wonder why they switched. Language inconsistency maybe.

bearnana:
Well, it seems the OP has learnt enough to last him a year. If there are any specifics, please ask, I'd be more than glad to give my input.

HottestFire:




Lol, you must be joking about your not too interested in OOP, well never too late to develop frameworks or work with over the shelves.

You don't want your codebase to be problematic for others to understand.

HottestFire:




Lol, I once had problem with javascript for a payment gateway, I went as far as talking/sharing my code with a professional developer in europe and the embarassing response I got from him made me sit up...

Sometimes being naughty has a way of passing the right knowledge.

DharkPoet:


I wish I could get people to review my codes.

Ok, any terms or reference..