Executing PHP Script from CLI with Litespeed.

[ZachH83]

I apologize if this is a silly question, but I am fairly new to Litespeed, and am not sure exactly how it all comes together.

So, what I am trying to do, is execute a php script from my servers CLI (eventually to become a cron job). Currently, I can run it fine using the php command. (php /home/scripts/script.php)

When I type 'which php' I get:

/usr/local/bin/php

When I type 'php -v' I get:

ea-php-cli Copyright 2017 cPanel, Inc.
PHP 5.6.33 (cli) (built: Feb 7 2018 02:53:19)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with the ionCube PHP Loader v4.7.5, Copyright (c) 2002-2014, by ionCube Ltd., and
with Zend Guard Loader v3.3, Copyright (c) 1998-2014, by Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies

So going by this information, I am not sure if I am using the litespeed in this or not. From what I have found through google searches, is that there should be a php found within my servers lsws directory.

As for the details of the script;

When I run the full version of the script (meaning including all html, headers, etc) on the web browser it takes about 1.11 seconds to complete the script.

When I run the short version (meaning just the script that handles my objectives, no bells and whistles) through the CLI, it takes anywhere between 3.5-5 seconds to complete.

I also posted this on the php forum, but it doesn't seem to have much activity on it. So, posting it here to see if a response comes soon. I will remove whichever one gets no attention.

I would imagine that the cli should be equally as fast, or faster, as it is only executing the script, without including all the non-related stuff that the website uses for doing all that it does on load...

Any helpful information is appreciated.

I would like to request that I do not get any "ego-stroking" responses. Please keep your responses related to my question, as inflating it with useless banter about how smart you are, will only hinder future google searches for others.

thank you.

 

[NiteWave]

how about a simple phpinfo.php ? any time difference ?

 

[ZachH83]

It loads about the same in the CLI as it does in the browser. Both under .005.

The phpinfo shows this information. Which, I'm sure confirms that I do in fact have litespeed installed on the server.

Server API LiteSpeed V6.10
Configuration File (php.ini) Path /opt/cpanel/ea-php56/root/etc
Loaded Configuration File /opt/cpanel/ea-php56/root/etc/php.ini
Scan this dir for additional .ini files /opt/cpanel/ea-php56/root/etc/php.
_SERVER["SERVER_SOFTWARE"]LiteSpeed

But I'm still not certain this means that it iss affecting the command line execution.

I was getting the same execution times (.005) for the phpinfo using

/usr/local/lsws/fcgi-bin/lsphp5 /home/scripts/scripts.php
php /home/scripts/scripts.php

I would get slow times (.289) using this,

/usr/bin/php

But, sometimes it would produce the same time(.005) as the ones above.

So, when running a small script; These are the results I get:

# /usr/local/lsws/fcgi-bin/lsphp5 /home/scripts/temp.php
2.29155302048
# /usr/bin/php /home/scripts/temp.php
2.31544303894
# php /home/scripts/temp.php
2.28617501259

So, they're all pretty similar...

 

[ZachH83]

Oh, and additionally, taht small script executed through the browser was completing in 1.38594508171... which is considerably faster

 

[NiteWave]

this issue is new to me, I haven't compared command line php script with accessing from browser before so have no such experience. but looks interesting of your test result.
however, since running from web browser is much faster, I'd suggest you to use "curl the-url-of-the-script.php" in your cron job.

 

[ZachH83]

That may be an option, though, i'd like to avoid it all together and keep the scripts outside of my web directory.
I do appreciate the suggestion though.

 

[tina]

If using the curl option as a temporary solution, you may wish to consider placing the script in a password-protected directory, and using the login credentials in your curl. This way, the script remains inaccessible to the public.