Thinkphp 3.2 Performance optimization for high-performance API development

Demand analysis

The current business full station uses thinkphp 3.2.3, foreground, backstage, Cli, API and so on. Current business API visits tens of millions of, backend 7 PHP 5.6, average CPU usage 20%.

Test data

Real Business

php5.6:500 QPS

php7.0:850 QPS

Reduce one MySQL query business in real business or reduce the Redis read/write by one time

php5.6:800 QPS

php7.0:1250 QPS

The results of the current optimization:

Thinkphp can be fully run in the cache;

MySQL connection is not established when MySQL query is not required;

Redis connections are not established when Redis is not read and written.

The above data is obtained in the development machine using AB, and is also a simple contrast with other frameworks, with performance no less than other frameworks.

Using the Zend Debugger profile, you can see that the frame layer has a time-overhead ratio of about 24%, and a framework that contains the cache and ORM has a better performance than the performance loss of the C framework 10% for YAF.

Again Spit groove a mention thinkphp frame on the spray performance of the person, any frame to take over a few more database operations, test performance is not forced, only test output a helloworld and what eggs.

Optimization Process 0x00

Early in the project, development pressure was high and there was little time for project and architecture optimization.

After testing, the API stability was greatly improved by adding MySQL long connection and redis long connection, the slowest response time of the business was optimized from 4s to 0.5s, and the curve was very smooth.

PHP-FPM stand-alone 200 process, 2000request,7 PHP back end, the number of long connections stable at about 1700.

The problem arises when the number of long connections exceeds 5k, performance degrades. There have been two times when the MySQL Server ran out of memory.

0x01

After analysis, found a lot of API requests, is not necessary to establish a MySQL connection. Adjust the code, MySQL's query logic as far as possible cache into Redis, reduce the pressure on MySQL.

At the same time, the code logic of the thinkphp, call the model of the method, properties, do not establish a MySQL connection, only read and write to the DB to establish a connection. A lot of resource overhead is reduced.

After this adjustment, the MySQL connection dropped from 1700 to less than 100, and the query and read QPS dropped from 5k to 50.

The optimized thinkphp code has been pushed to GitHub:

Https://github.com/vus520/thinkphp/tree/shuhai/db_link_lazzy

The following is an in-depth test of MySQL master-slave and read-write separation in thinkphp, which increases MySQL's reading ability.

0x03

When the business is heavily dependent on Redis, Redis's QPS once soared to 7k, with memory consuming around 6G.

To alleviate the read pressure of Redis, 4 Redis standalone were used in production to make 1 Master 3 from the architecture.

and add Redis read-write separation support to thinkphp, reducing the pressure on redis.

https://github.com/vus520/thinkphp/blob/shuhai/db_link_lazzy/ThinkPHP/Library/Think/Cache/Driver/Redisd.class.php

The problems that exist today

Redis's high-availability operations, which are inherently complex, are subject to synchronization failures and latency problems due to network jitter.

Especially in the environment of Cloud server architecture, network bottleneck and delay problem have great influence on distributed application.

Unfortunately, we are currently using the Tsing Yun, can not achieve the Redis ultra-high availability, can not achieve seamless expansion, the network transmission performance, latency in the private network has a great space for optimization.

Follow-up optimization plan

To clean up the redis business and reduce unnecessary requests;

compressed content;

Key:value = hash;

One master multi-slave, each PHP backend deployed a redis from, priority reader machine, reduce network latency;

0x04

API Project, disable thinkphp session, route, view, behavior, and so on, for thin acceleration. The performance has been tested for a 30% improvement.

Https://github.com/vus520/thinkphp/tree/shuhai/tiny

• 1, remove the route
• 2, remove the URL schedule
• 3, remove the behavior, Hook
• 4, remove the view
• 5, remove the controller's reflection, empty operation
• 6, remove session, can implement stateless API

0x05

In-depth testing in PHP7, the performance of upgrading to php7,thinkphp 3.2 has a 50+% boost

thinkphp 3.2 Performance optimization for high-performance API development