Ldaprecord-laravel: [Support] Slow php artisan commands

[jsandfordhughes]

Environment (please complete the following information):

• LDAP Server Type: ActiveDirectory
• PHP Version: 7.4

Describe the bug:
When this package is installed all php artisan commands are extremely slow even the artisan command on its own to list commands, if I remove this package from composer run update and then run php artisan the command is back to normal speed

[stevebauman]

Hi @jsandfordhughes, I'm not able to reproduce this on my end on both v1 and v2:

https://user-images.githubusercontent.com/6421846/103467144-1878f200-4d1a-11eb-986e-c0cb1728b224.mov

Which version of Laravel are you using? Can you try on a fresh Laravel instance and see if you still encounter this?

[jsandfordhughes]

Hey Steve,

So yes just done a fresh instance and it does not have the issue however as soon as I remove this package from the troublesome instance php artisan works fine. I am on Laravel 8.

[stevebauman]

Hm, strange! Can you post your composer.json file?

Have you created any custom commands or service providers that may be attempting opening a connection to an LDAP server? Does it seem like it takes around 5 seconds to display the commands? That is the default timeout set in LdapRecord, so it may be the case.

[jsandfordhughes]

Okay, So fresh instance with just LdapRecord installed, before I publish the config file everything is fine. As soon as I publish the config file it hangs for 5 seconds ish, remove the ldap.php file and its back to normal

https://user-images.githubusercontent.com/35659248/103489119-0b3b3080-4e0a-11eb-9202-0f7bac5716de.mov

[stevebauman]

Hmm, I'm still not able to produce this. Tried using PHP 7.3, 7.4, and 8.0:

https://user-images.githubusercontent.com/6421846/103490144-d918d700-4de7-11eb-82fa-c205ea53a29f.mov

This seems to be machine related somehow. Can you check your mac's PHP error logs to see if there has been any entries created there? Do you have the LDAP extension enabled in your PHP ini?

You may have to dd() (dump and die) in the artisan lifecycle to see where it's getting held up. I haven't had any other reports of this and have also not experienced this on any of the production servers that have LdapRecord-Laravel installed.

[jsandfordhughes]

I have done some digging and have narrowed it down to this method in this package:

/**
     * Initializes the LDAP connection.
     *
     * @return void
     */
    public function initialize()
    {
        $this->configure();

        $this->ldap->connect($this->host, $this->configuration->get('port'));
    }

This is in the connection.php file

If I comment both of the methods out, php artisan runs fine. If I comment one or the other out it still runs slow. It has to be both methods commented out for it to work correctly.

Any suggestions on where to look next?

[stevebauman]

Those two methods initiate a new LDAP resource, using the ldap_connect and ldap_set_option methods. This leads me to believe there may be issues with the LDAP extension in your PHP install.

Do you have the LDAP extension enabled on the PHP version that is accessible globally on your machine through CLI?

Any suggestions on where to look next?

I would suggest looking at your PHP error logs as well to see if any errors are being thrown that may not be displayed.

[stevebauman]

Also, does changing the default timeout configuration option to one (1) in the published config/ldap.php file reduce the time that it takes to run the php artisan command?

Do you have any .env or system env variables that may be setting the LDAP_HOST variable to null or empty?

https://github.com/DirectoryTree/LdapRecord-Laravel/blob/86b1c7cd637da559ffba59f6d96fbcd83dde01b9/config/ldap.php#L32

I feel there may be something strange going on where the ldap_connect method is somehow waiting for timeout on an invalid IP or URL given as a host to the ldap_connect method. I'm going to investigate the PHP source.

[jsandfordhughes]

Hi Steve,

Yes the global php 7.4 shows the ldap extension as enabled when running php -v
Nothing in the php logs
No, strangely if I change the timeout it still takes 5 seconds or so
No env file as this is a fresh installation of laravel

[jsandfordhughes]

You are right in that it is something to do with the php extension, the cause in both of those methods is the call to the following: ldap_set_option ldap_connect

If i remove them and return true instead the speed is fine.

[stevebauman]

Hmmm very strange... A couple more questions:

1. Does changing PHP versions resolve the issue?
2. Do you have an ldap.conf file on your system?

I've looked at the PHP source and it doesn't appear that there is anything attempting a connection:

https://github.com/php/php-src/blob/589bdf30b2bea10172a49bcad26d44b18f192556/ext/ldap/ldap.c#L985-L1084

[jsandfordhughes]

All very strange.

Just removed php completely with brew and then reinstalled 7.4 and 8.0 have tried both version but still the same issue.

Yes I have an ldap.conf however it is all commented out inside.

[stevebauman]

All very strange.

Definitely!

I have some more questions:

• Does disconnecting your mac's WiFi or network connection make a difference?
• Does deleting/moving your ldap.conf file make a difference?
• What version of macOS are you using? I'm on Big Sur (11.1)

[jsandfordhughes]

Wifi is a no and moving the ldap.conf is a no.

I am on Catalina (10.15.7)

Thanks for your help on this!

[stevebauman]

Apologies for the late reply on this @jsandfordhughes!

Are you able to test this on any other computer by chance? Or in a sandbox environment such as Docker? I have a feeling this is something machine related, but I want to confirm before making assumptions 👍

[stevebauman]

Closing due to inactivity.

[jsandfordhughes]

Hi Steve,

Sorry for the late reply. Tried loads of stuff including upgrading to Big Sur. Still had the same issues. Ended up doing a fresh install of Big Sur and the issue has gone away. Must of been some Dodgy openldap extension or something.

Thanks for your help and the great package!

👍

[stevebauman]

No problem @jsandfordhughes! Thanks so much for following up and letting me know what fixed it! Definitely a strange issue.

Always happy to help and thanks for your kind words! Really glad you find LdapRecord useful 😄

[bcalik]

I have just wasted 2 hours on this.
Removing this package solves my issue.

xdebug shows that php::ldap_set_option takes 5 seconds.
I'm not sure why this package calls php::ldap_set_option even if its not active.

[stevebauman]

Hi @bcalik,

Sounds like you have a buggy LDAP installation on your system.

I'm not sure why this package calls php::ldap_set_option even if its not active.

If you have published the config/ldap.php configuration file, then a new Connection instance will be instantiated for however many connections you have inside of the configuration file.

Here's where the connections are loaded from the configuration file:

https://github.com/DirectoryTree/LdapRecord-Laravel/blob/1a355537f04fa091799898a9c532c6acb9b51d23/src/LdapServiceProvider.php#L82-L90

https://github.com/DirectoryTree/LdapRecord-Laravel/blob/1a355537f04fa091799898a9c532c6acb9b51d23/src/LdapServiceProvider.php#L97-L108

Then, here's where ldap_set_option is being called:

https://github.com/DirectoryTree/LdapRecord/blob/2d1c4d71dd900b2f8245a6e32f67274795fac8a2/src/Connection.php#L185-L192

By default, the configuration file comes with a single non-existing connection configured -- for convenience. Simply remove all the connections, or define them a different way, if you have issues in your environment with your LDAP installation.

I have just wasted 2 hours on this.
Removing this package solves my issue.

LDAP is your problem. Not this package.

[jsandfordhughes]

Your systems LDAP extension is 100% the issue here and NOT this package.

[bcalik]

@stevebauman Thanks for the explanation.

Your systems LDAP extension is 100% the issue here and NOT this package.

@jsandfordhughes My systems ldap extension may be faulty but this does not explain why this package try to instantiate Connection instance on every artisan command when I don't use it, even if I disabled it via .env, and did not even configure any connection. Which is unexpected.

[jsandfordhughes]

When this package is installed, so is it's service provider which is what is being called on every boot of the framework

[bcalik]

When this package is installed, so is it's service provider which is what is being called on every boot of the framework

Let me clear the question for you, why the package instantiate Connection instance on boot of service provider, instead of before actual connection?

[stevebauman]

Hi @bcalik -- you're right, I think we should avoid issuing any LDAP instructions until it's explicit and known by the developer.

I'm going to fix this today and put out a new release. I appreciate the critique! 👍

[stevebauman]

Okay, I've just pushed a new release v2.4.5 that resolves this issue.

I have moved LDAP connection initialization into the actual connection attempt, rather than the instantiation of the Connection class itself. This will prevent this issue from occurring on users machines if their LDAP install has this issue.

Thank you @jsandfordhughes and @bcalik! Really appreciate your time and feedback.

[bcalik]

@stevebauman Thank you very much for taking time on this, much appreciated.