How can handle thousands of requests per second using php and mysql?

Question

I would like to implement an API using php and mysql technologies that can handle several thousands of requests per second.

I haven't did this kind of API before. If you have an experienced to implement similar task could you please tell me what are the steps?

How can I implement such kind of API that can handle thousands of request per second?

I would be glad if you could explain with sample codes.

Thanks in advance for your help.

Answer 1

Good answer, I think one thing to keep in mind is where the bottleneck is. Many times, the bottleneck isn't the API server itself but the data access patterns with the persistence layer.

Think about how you access your data. For posting new items, a lot of times the processing can be delayed and processed async to the original request. For example if resizing an image or sending an email, you can integrate RabmitMQ or SQS to queue up a job, which can be processed later by workers. Queues are great in buffering work so that if a server goes down, stuff is just queued up to be processed once back online.

On the query side, it is important to understand how indexing works and how data is stored. There are different types of indices, for example hash tables can give you constant access time, but you cannot perform range queries with hash tables. The easiest is if you have simple decentralized data objects queried by identifiers which can be stored in a index. If you're data is more complex where you need to do heavy joins or aggregations, then you can look at precomputed values stored in something like Redis or memcache.

Answer 2

Well you need to consider several factors such as:

1. Authenticating the API. Your API should be called by valid users that are authorized and authenticated

2. Caching API results. Your API should cache the results of API call. This will allow your API to handle requests more quickly, and it will be able to handle more requests per second. Memcache can be used to cache results of API call

3. The API architecture. RESTFul APIs have less overhead as compared to SOAP based APIs. SOAP based APIs have better support for authentication. They are also better structured then RESTFul APIs.

4. API documentation. Your API should be well documented and easy for users to understand.

5. API scope. Your API should have a well defined scope. For example will it be used over the internet as a public API or will it be used as private API inside corporate intranet.

6. Device support. When designing your API you should keep in mind the devices that will consume your API. For example smart phones, desktop application, browser based application, server application etc

7. API output format. When designing your API you should keep in mind the format of the output. For example will the output contain user interface related data or just plain data. One popular approach is known as separation of concerns ( https://en.wikipedia.org/wiki/Separation_of_concerns ). For example separating the backend and frontend logic.

8. Rate limiting and throttling. Your API should implement rate limiting and throttling to prevent overuse and misuse of the API.

9. API versioning and backward compatibility. Your API should be carefully versioned. For example if you update your API, then the new version of your API should support older version of API clients. Your API should continue to support the old API clients until all the API clients have migrated to the new version of your API.

10. API pricing and monitoring. The usage of your API should be monitored, so you know who is using your API and how it is being used. You may also charge users for using your API.

11. Metric for success. You should also decide which metric to use for measuring the success of your API. For example number of API calls per second or monitory earnings from your API. Development activities such as research, publication of articles, open source code, participation in online forums etc may also be considered when determining the success of your API.

12. Estimation of cost involved. You should also calculate the cost of developing and deploying your API. For example how much time it will take you to produce a usable version of your API. How much of your development time the API takes etc.

13. Updating your API. You should also decide how often to update your API. For example how often should new features be added. You should also keep in mind the backward compatibility of your API, so updating your API should not negatively affect your clients.

Answer 3

Based on the details described in the post, you likely want to use an asynchronous, stateless architecture. So requests don't block resources and can scale easier (always sounds easier than actually doing it ;)).

Without knowing to what other services these servers would connect (it certainly doesn't make things easier), I'd go for Elixir/Erlang as programming language and use Phoenix as a framework.

You get a robust functional language which comes with a lot of great built-in features/modules (eg mnesia, roll/unroll versions while being live) and scales well (good in utilizing all cores of your server).

If you need to queue up requests to the 2nd tier servers AMQP client/server (eg RabbitMQ) might be a good option (holds/stores the requests for the servers).

That works pretty okay if it's stateless, in form of client asks one thing and the server responds once and is done with the task. If you have many requests because the clients ask for updates every single second, then you're better switching to a stateful connection and use WebSockets so the server can push updates back to a lot of clients and cuts a lot of chatter/screaming.

All of this writing is from a 'high up view'. In the end, it depends on what kind of services you want to provide. As that narrows down what the 'suitable tool' would be. My suggestion is one possibility which I think isn't far off (Node.js mentioned before is also more than valid).