Artifacts that make programmers no longer bitter (on)

Sail the waves, set sail for the future!

To do the program ape "Yuan" is a hard work, in Saturday to get up early in the technology group to greet, see no one response, said a sentence, "Not estimated to wake up", and then a buddy thrown over, "in overtime"!

To do WEB development is a hard work, not like IOS, the client, basically everything is done. Do WEB development is not only to do the backend, the front end also need to understand and familiar with!

The front and back end take-all DEVOPS engineer is absolutely the most bitter, not only need to do development, but also to understand operation and maintenance, optimization, will not be the maintenance of engineers is not a good architect!

but fortunately, a good engineer, despite his busy, is familiar with the front and back, the system, the operation, the optimization, but in his toolbox, put a lot of tools to make this life less difficult to force.

Here are four artifacts that make our DevOps life a better place. They are Xdebug, xhprof,OneAPM and Socketlog, respectively.

Xdebug

As a developer, the most practical thing to sleep with is knowing the code you write, whether it's functional or performance level. And to do Web PHP development, the more difficult thing is the code debugging. As a scripting language, run on the remote server side, the client generates all the HTML code, generally think we can not accurately debug the situation, not to mention the single-step debugging, variable monitoring and other things. In fact, there is a misconception that there is a PHP extension Xdebug that allows us to easily debug code running on a remote server.

The method is simple, download the latest version of the source code from Xdebug. wget Decompression:

?

123456

tar –zxvf xdebug-2.3.3.tgz  cd xdebug-2.3.3  phpize  ./configure –with-php-config=/usr/bin/php-configmake  make install

Add the corresponding configuration to the php.ini, there are two points to note: 1. Xdebug is zend_extension 2. Port default is 9000, and php-fpm default port conflict, so swap 9100

?

123456

[xdebug]zend_extension=/usr/lib/php/extensions/no-debug-non-zts-20121212/xdebug.so  xdebug.remote_enable=on  xdebug.remote_handler=dbgp  xdebug.remote_host=localhost  xdebug.remote_port=9100

This will be installed, it is so simple, below we can start to use. Take thinkphp application development as an example. Thinkphp A typical single-entry application, the call hierarchy is relatively complex. So trying to understand the call stack is still a bit cumbersome. To get the call stack for a row, you can use PHP's own debug_backtrace function to obtain, but not very image, to return an array. And Xdebug can make it all visible.

With Xdebug, you are using Netbeans's own debugging tools. First modify the PHP debugging port through the preferences, change from 9000 to 9100, the other does not move. Note that in the first line stop is selected, this will be in the PHP program debugging, run to the first line of PHP code to stop, in thinkphp, that is, the entry file index.php the first line stop.

In this example, the author makes a car rental management System example, the project name is zuches. Deploy the code where http://localhost/zuches can access it, and the index file is index.php.

Since index.php is a portal file, right-click on the index.php and select Debug.

Then Netbeans automatically opens the following address into the debug state:http://localhost/zuches/index.php? Xdebug_session_start=netbeans-xdebug the same running position indicates that the first line of the index.php is stuck. As follows:

Click Continue to run, due to the IndexController.class.php index method to add a breakpoint, so the position indicator and stay at the corresponding breakpoint.

At this point, we can look at the call stacks and variables at the time of the outage. The stack makes it easy to locate the classes and corresponding methods for each location.

variables, both local and instance, can be seen in the variable table at a glance, whether it's a cookie or a data submission.

In short, Xdebug let us even do the server-side page and API development, can also be like desktop application development, debugging each line of code.

Xdebug In addition to the use of single-step debugging, you can also collect the execution log in the request, record each function's execution process. These logs can be analyzed using tools such as Wincachegrind, and see the call stack and the time spent on the function. Not to mention here, we are not very recommended, because xhprof in this piece to be lightweight and powerful, not so hard to download logs, analysis logs.

xhprof

As mentioned above, for PHP function call stack and performance analysis, XHPROF will Xdebug open precedent inherit and flourish. Xhprof is also a PHP extension, but it is not recommended to download from http://pecl.php.net/package/xhprof , the version has not been updated for nearly 2 years, preferably from https://github.com/ Phacility/xhprof Download . It is easy to download the compilation configuration and the use process.

The configuration only needs to add the following two lines:

?

12	[xhprof]extension=/usr/lib/php/extensions/no-debug-non-zts-20121212/xhprof.so

Then the corresponding XHPROF code is configured to the page that needs to be monitored, that is, you can get the entire page execution, the function of the call report. XHPROF provides an example that the configuration runs successfully as follows:

How do you see the effect in the image above? Place the examples, xhprof_html, xhprof_lib three directories in a location that the browser can access, such as the home directory of localhost. Modify the examples/sample.php in the change to such as: localhost/xhprof_html/. Can.

then access the http://localhost/examples/sample.php to get the output as follows:

As can be seen from examples/sample.php, for page monitoring analysis, at the top of the page using Xhprof_enable to start, and the end of the analysis of the performance of the page at the bottom of the use of xhprof_disable end. So every time you monitor, you need to add a piece of code, so for the sake of specification. The operations related to XHPROF are encapsulated. Continue using the example of the thinkphp car rental system in the previous example to see how to integrate xhprof analysis.

First, the operation of Xhprof is encapsulated into a class.

?

1234567891011

<!--?php class XHProf { private static $strNameSpace = ""; public static function init($strNameSpace = "myhome") { if (!function_exists("xhprof_enable")) { return; } self::$strNameSpace = strval($strNameSpace); $param = XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY; $path = getcwd(); require_once $path.‘/../xhprof_lib/utils/xhprof_lib.php‘; require_once $path.‘/../xhprof_lib/utils/xhprof_runs.php‘; xhprof_enable($param); register_shutdown_function("XHProf::genResult"); } public static function genResult() { $profiler_namespace = self::$strNameSpace; $xhprof_data = xhprof_disable(); $xhprof_runs = new XHProfRuns_Default(); $run_id = $xhprof_runs--->save_run($xhprof_data, $profiler_namespace);        $profiler_url = sprintf(‘http://‘ . $_SERVER[‘HTTP_HOST‘] . ‘/xhprof_html/index.php?run=%s&source=%s‘, $run_id, $profiler_namespace);        echo ‘            <p style="background: orange;">                ‘        . ‘<a href="‘ . $profiler_url . ‘" target="_blank">Profiler output</a>             </p>‘;    }}

In this encapsulated class, the presence of the Xhprof_enable function is first detected, which can be used to determine if the Xhprof extension is configured successfully. Next, the parameter is set, especially the use of function register_shutdown_function to register an operation, which will run automatically before the end of the page.

This way, when analyzing page performance, just add two lines to the thinkphp application's index.php, which is OK.

Like what:

?

12	require_once"xhprof.php";  XHProf::init("zuches");

After running, get the following effect:

And each page has this output. Click "profiler output" to get the report.

In this example, you can see the final integration method, which runs longer than 2 S, is worth watching and optimizing. From the report, you can first see the number of calls for each method or function, the elapsed time, and the ability to layer points to see the parent-child hierarchy of call relationships.

It should be noted that on-line, such as on the use of xhprof to be cautious, even if opened, but also to open the restrictions, such as the current user is some debugging developer users to open. Otherwise, the ordinary user to see such output, is unclear so, to the user confusion, of course, we can also not output, and the data directly stored in the background system to view, so that users can not feel. There is a tool that can completely eliminate these entanglements. That's OneAPM, in part fourth we'll introduce.

Not finished, to be continued ...

Artifacts that make programmers no longer bitter (on)