Performance issues with PHP client on __construct process

1

With this simple code:

<?php $key=123456798;

$record = array(
	"hello" => "world",
);

$db=new \Aerospike(array(
	"hosts" => array( array(
		"addr" => 'xx.xx.xx.xx',
		"port" => '1234',
	)
)),false);

$asKey = $db->initKey('my_namespace', 'my_set', (string)$key); // Convert key into string => var type is important

// read selected bins from a record
$option = array( \Aerospike::OPT_POLICY_KEY => \Aerospike::POLICY_KEY_SEND );
$return = $db->put($asKey, $record, 0, $option);

if ( \Aerospike::OK == $return )
	var_dump('record saved!');
else
	var_dump($db->errorno(),$db->error());

we got this result in time with xdebug:

version: 1
creator: xdebug 2.5.5 (PHP 5.6.31-1~ubuntu14.04.1+deb.sury.org+1)
cmd: /var/www/html/test_aerospike.php
part: 1
positions: line

events: Time

fl=(1) php:internal
fn=(1) php::Aerospike->__construct
89 3151863

fl=(1)
fn=(2) php::Aerospike->initKey
91 10

fl=(1)
fn=(3) php::Aerospike->put
95 26779

fl=(1)
fn=(4) php::var_dump
98 47

fl=(2) /var/www/html/test_aerospike.php
fn=(5) {main}

summary: 3179787

-1076408928 1086
cfl=(1)
cfn=(1)
calls=1 0 0
89 3151863
cfl=(1)
cfn=(2)
calls=1 0 0
91 10
cfl=(1)
cfn=(3)
calls=1 0 0
95 26779
cfl=(1)
cfn=(4)
calls=1 0 0
98 47

Human readable format:

{main} : 0,001sec php::Aerospike->__construct : 3,1sec php::Aerospike->put : 0,026sec var_dump() : 0.000047sec php::Aerospike->initKey : 0.00001sec

Conclusion

As you can see the Aerospike PHP extension take 3,1 seconds to load! (initiate connection?) the put process is faster (only 0,026sec).

Environment

PHP 5.6.31-1 aerospike-client-php-3.4.14 ubuntu14.04.1 Apache/2.4.7 (Ubuntu)

Does anyone got this performance issue too? Any ideas?

Thanks for your help!

2

I’ll repeat the answer to your same post on the GitHub repo aerospike/aerospike-client-php.

All Aerospike clients are smart clients - they don’t just handle connection pooling, they also learn the cluster topology when they connect to any node, open connections to all the other nodes, and pull down the partition map. They track changes to the cluster through a cluster tending thread (that can be shared across processes).

This means that the initial connection is a heavy operation, so there’s no surprise in what you’re seeing (depending on your instance). This is covered in the documentation for the constructor, and in how to configure your web server to handle this situation.

3

Thank you rbotzer, i will take a look on the doc.