Facter command slows down when phpunit is started over Jenkins - php

I'm having the problem that shell_exec in combination with the facter command is very slow when started over Jenkins. Other commands than facter (like whoami) are fast.
The code runs on a Ubuntu VM that was recently upgrade from 14.x to 18.04.1 LTS. On Ubuntu 14.x I didn't encounter that problem. Facter is currently on version 3.11.3.
I nailed the speed problem down to the shell_exec in combination with facter by using the following code:
<?php
/**
*/
require_once 'AbstractTestCase.php';
/**
*/
class FacterTest extends AbstractTestCase
{
/**
*/
public function testSpeedDebug()
{
Core_Util_Debug::performanceStart('whoami');
shell_exec('whoami');
Core_Util_Debug::performanceEnd('whoami');
Core_Util_Debug::performanceStart('facter');
shell_exec('facter hostname');
Core_Util_Debug::performanceEnd('facter');
die (PHP_EOL);
}
}
When started manually over the CLI the output is:
>> name: whoami | time: 0.005261 s | memory: 3.3359 kB RAM
>> name: facter | time: 0.160292 s | memory: 0 B RAM
When started over Jenkins the output is:
>> name: whoami | time: 0.005495 s | memory: 3.3359 kB RAM
>> name: facter | time: 8.652776 s | memory: 0 B RAM
Does someone have an idea why it is slow when started over Jenkins (~8 times slower)?
Thank you in advance.
Extra info:
Gave it a quick try on Bamboo, and the behavior is the same as on Jenkins.

Related

Good practice to run 'php artisan schedule:run' for Laravel in Kubernetes

I am working on integrating a few Laravel PHP applications into a new Kubernetes architecture, and still struggling on how I can run php artisan schedule:run in a nice manner.
In the official Laravel manual, we are advised to set up the cronjob like this.
* * * * * cd /path-to-your-project && php artisan schedule:run >> /dev/null 2>&1
ref. https://readouble.com/laravel/5.7/en/scheduling.html
Cronjob
Initially, I came up with the idea of using cronjob in Kubernetes, and it works fine for now but started worried about the current architecture.
(One deployment for web service, and one cronjob for the task scheduling.)
---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: cron
namespace: my-laravel-app
spec:
concurrencyPolicy: Replace
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- image: my_laravel_app_image:latest
name: cron
command: ["php", "artisan", "schedule:run"]
imagePullPolicy: Always
envFrom:
- configMapRef:
name: laravel-app-config
- secretRef:
name: laravel-app-secret
restartPolicy: Never
However, since I use concurrencyPolicy: Replace here the pod itself might be terminated even the job is still running (for more than 1 minute). To avoid this issue, I could use the default value concurrencyPolicy: Allow but it introduces another issue - Even I set failedJobsHistoryLimit at 1 and successfulJobsHistoryLimit at 1 the pod associated with the job are not properly terminated in the current running in-house Kubernetes cluster, and it reaches quota limit.
NAME READY STATUS RESTARTS AGE
pod/test-cronjob-a 0/1 Completed 0 4m30s
pod/test-cronjob-b 0/1 Completed 0 3m30s
pod/test-cronjob-c 0/1 Completed 0 2m29s
pod/test-cronjob-d 0/1 Completed 0 88s
pod/test-cronjob-e 0/1 Completed 0 28s
ref. https://github.com/kubernetes/kubernetes/issues/74741#issuecomment-712707783
Also, I feel It's a bit tricky to configure the monitoring and logging stack for those one-off jobs.
Deployment
Instead of using cronjob, I'm thinking to try to deploy the scheduler as another pod having the cron setting in the container using deployment resource.
(One deployment for web service, and one deployment for the task scheduling.)
I just wonder how you guys normally work around this issue in a scalable manner.
Instead of running schedule:run use K8s kind: Deployment (not Job) and run scheduler as a daemon:
php artisan schedule:work
https://laravel.com/docs/9.x/scheduling#running-the-scheduler-locally
More details:
See: https://medium.com/#agungdarmanto/how-to-run-a-laravel-application-into-kubernetes-a6d0111dc98d

Laravel Dusk: unknown error: call function result missing 'value'

I'm having problems with the Laravel Dusk type() and value() method. I'm getting the following error.
$ php artisan dusk --group=activation
Warning: TTY mode is not supported on Windows platform.
PHPUnit 5.7.27 by Sebastian Bergmann and contributors.
DevTools listening on ws://127.0.0.1:12599/devtools/browser/84028821-2ca1-4d26-b66c-4697d2302117
E 1 / 1 (100%)
Time: 13,35 seconds, Memory: 18,00MB
There was 1 error:
1) Tests\Browser\CounselorActivationTest::testActivationWithSubscriptionWithPasswordLogin
Facebook\WebDriver\Exception\UnknownServerException: unknown error: call function result missing 'value'
(Session info: chrome=68.0.3440.84)
(Driver info: chromedriver=2.33.506120 (e3e53437346286c0bc2d2dc9aa4915ba81d9023f),platform=Windows NT 10.0.17134 x86_64)
D:\devYubu\yubu\vendor\facebook\webdriver\lib\Exception\WebDriverException.php:114
D:\devYubu\yubu\vendor\facebook\webdriver\lib\Remote\HttpCommandExecutor.php:326
D:\devYubu\yubu\vendor\facebook\webdriver\lib\Remote\RemoteWebDriver.php:547
D:\devYubu\yubu\vendor\facebook\webdriver\lib\Remote\RemoteWebDriver.php:308
D:\devYubu\yubu\vendor\laravel\dusk\src\Concerns\InteractsWithElements.php:97
D:\devYubu\yubu\tests\Browser\tests\userActivation\CounselorActivationTest.php:58
D:\devYubu\yubu\vendor\laravel\dusk\src\TestCase.php:91
D:\devYubu\yubu\tests\Browser\tests\userActivation\CounselorActivationTest.php:95
ERRORS!
Tests: 1, Assertions: 0, Errors: 1.
I'm using the value method 2 times, I can see that the first one actually fills in the form, however the second one fails..
->value('input[name=external_id]', $counselor->getAttribute(User::COLUMN_EXTERNAL_ID))
->value('input[name=name_full]', $counselor->getAttribute(User::COLUMN_NAME_FULL))
When I'm using type(), the first one also fails:
->type('external_id', $counselor->getAttribute(User::COLUMN_EXTERNAL_ID))
->type('name_full', $counselor->getAttribute(User::COLUMN_NAME_FULL))
In using Windows 10. I'm running Dusk on Windows (I have PHP 7.2 installed). My application runs on Homestead with PHP 7.0. I'm using Laravel 5.4
This was a problem with an outdated ChromeDriver.
Big thanks to Jonas Staudenmeir, who has created a package for updating your Chromedriver:
https://github.com/staudenmeir/dusk-updater
I echo #Martijn Ihhoff. Get the staudenmeir updater -
https://github.com/staudenmeir/dusk-updater
After you download and run it (follow instructions on linked page above) be sure to kill the old ChromeDriver though. Here's how I did it:
run ps -aux then find the process ending with /vendor/laravel/dusk/bin/chromedriver-linux the second parameter from the left on that line will be the PID (Process ID) copy it (and any other PID's of running chromeDrivers) and then kill each of them by running kill ##### where ##### is the copied PID. Once all processes are killed, re-run dusk.

Broadcasting, laravel-echo-server not receiving events

I'm using Laravel in a project and I want to use broadcasting with laravel-echo-server and Redis. I have set up both in a docker container. Output below:
Redis
redis_1 | 1:C 27 Sep 06:24:35.521 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
redis_1 | 1:C 27 Sep 06:24:35.577 # Redis version=4.0.2, bits=64, commit=00000000, modified=0, pid=1, just started
redis_1 | 1:C 27 Sep 06:24:35.577 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
redis_1 | 1:M 27 Sep 06:24:35.635 * Running mode=standalone, port=6379.
redis_1 | 1:M 27 Sep 06:24:35.635 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
redis_1 | 1:M 27 Sep 06:24:35.635 # Server initialized
redis_1 | 1:M 27 Sep 06:24:35.635 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
redis_1 | 1:M 27 Sep 06:24:35.636 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
redis_1 | 1:M 27 Sep 06:24:35.715 * DB loaded from disk: 0.079 seconds
redis_1 | 1:M 27 Sep 06:24:35.715 * Ready to accept connections
A few warnings but nothing breaking.
laravel-echo-server
laravel-echo-server_1 | L A R A V E L E C H O S E R V E R
laravel-echo-server_1 |
laravel-echo-server_1 | version 1.3.1
laravel-echo-server_1 |
laravel-echo-server_1 | ⚠ Starting server in DEV mode...
laravel-echo-server_1 |
laravel-echo-server_1 | ✔ Running at localhost on port 6001
laravel-echo-server_1 | ✔ Channels are ready.
laravel-echo-server_1 | ✔ Listening for http events...
laravel-echo-server_1 | ✔ Listening for redis events...
laravel-echo-server_1 |
laravel-echo-server_1 | Server ready!
laravel-echo-server_1 |
laravel-echo-server_1 | [6:29:38 AM] - dG0sLqG9Aa9oVVePAAAA joined channel: office-dashboard
The client seems to join the channel without any problems.
However, if I kick of an event laravel-echo-server doesn't receive the event.
I did a bit of research and found something about a queue worker. So I decided to run that (php artisan queue:work) and see if that did anything. According to the docs it should run only the first task in the queue and then exit (as opposed to queue:listen). And sure enough it began processing the event I kicked of earlier. But it didn't stop and kept going until I killed it:
[2017-09-27 08:33:51] Processing: App\Events\CompanyUpdated
[2017-09-27 08:33:51] Processing: App\Events\CompanyUpdated
[2017-09-27 08:33:51] Processing: App\Events\CompanyUpdated
[2017-09-27 08:33:51] Processing: App\Events\CompanyUpdated
etc..
The following output showed in the redis container:
redis_1 | 1:M 27 Sep 06:39:01.562 * 10000 changes in 60
seconds. Saving...
redis_1 | 1:M 27 Sep 06:39:01.562 * Background saving started by pid 19
redis_1 | 19:C 27 Sep 06:39:01.662 * DB saved on disk
redis_1 | 19:C 27 Sep 06:39:01.663 * RDB: 2 MB of memory used by copy-on-write
redis_1 | 1:M 27 Sep 06:39:01.762 * Background saving terminated with success
Now I either did so many api calls that the queue is so massive, or something is going wrong. Additionally, laravel-echo-server didn't show any output after the jobs were 'processed'.
I have created a hook in my Model which kicks of the event:
public function __construct(array $attributes = []) {
parent::__construct($attributes);
parent::created(function( $model ){
//event(new CompanyCreated($model));
});
parent::updated(function( $model ){
event(new CompanyUpdated($model));
});
parent::deleted(function( $model ){
event(new CompanyDeleted($model));
});
}
Then this is the event it kicks off:
class CompanyUpdated implements ShouldBroadcast {
use Dispatchable, InteractsWithSockets, SerializesModels;
/**
* Create a new event instance.
*
* #return void
*/
public function __construct(Company $company) {
$this->company = $company;
}
/**
* Get the channels the event should broadcast on.
*
* #return Channel|array
*/
public function broadcastOn() {
return new Channel('office-dashboard');
}
}
And finally, this is the code on the front-end that's listening for the event:
window.Echo.channel('office-dashboard')
.listen('CompanyUpdated', (e) => {
console.log(e.company.name);
});
.env file:
BROADCAST_DRIVER=redis
CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=redis
REDIS_HOST=redis
REDIS_PASSWORD=null
REDIS_PORT=6379
Why isn't the event passed to laravel-echo-server? Anything I'm missing or forgetting?
Started working out of the blue.
For me, #jesuisgenial's comment pointed me in the right direction.
You can easily identify if it's not subscribing by checking the Websockets tab under the Networking tab in Chrome developer tools
Without 1 second delay (no subscribe event):
Echo.private(`users.${context.getters.getUserId}`)
.listen('.conversations.new_message', function(data) {
console.log(data.message);
})
With 1 second delay (subscribe event present):
setTimeout(() => {
Echo.private(`users.${context.getters.getUserId}`)
.listen('.conversations.new_message', function(data) {
console.log(data.message);
})
}, 1000)

PHP exec() not returning all command output - OS X

I am using PHP to find out if a piece of hardware is attached to the server. I am using the following php command on a Mac OS X server. But not all results are returned, makes me feel like they are buried in an array I can't get to.
In Terminal I run:
$ system_profiler SPUSBDataType
The output is:
USB Hi-Speed Bus:
Host Controller Location: Built-in USB
Host Controller Driver: AppleUSBEHCI
PCI Device ID: 0x1e2d
PCI Revision ID: 0x0004
PCI Vendor ID: 0x8086
Bus Number: 0x1a
Hub:
Product ID: 0x0024
Vendor ID: 0x8087 (Intel Corporation)
Version: 0.00
Speed: Up to 480 Mb/sec
Location ID: 0x1a100000 / 2
Current Available (mA): 500
Current Required (mA): 0
FaceTime HD Camera (Built-in):
Product ID: 0x8510
Vendor ID: 0x05ac (Apple Inc.)
Version: 80.25
Serial Number: CC2C9C098NDN9KE0
Speed: Up to 480 Mb/sec
Manufacturer: Apple Inc.
Location ID: 0x1a110000 / 3
Current Available (mA): 500
Current Required (mA): 500
when I run the same command in php:
exec ("system_profiler SPUSBDataType");
only this is returned:
USB 3.0 SuperSpeed Bus:
Host Controller Location: Built-in USB
Host Controller Driver: AppleUSBXHCI
PCI Device ID: 0x1e31
PCI Revision ID: 0x0004
PCI Vendor ID: 0x8086
Bus Number: 0x0a
My full php is as follows:
<?php
$usbDevices = array();
exec ("system_profiler SPUSBDataType", $usbDevices);
foreach ($usbDevices as &$value) {
echo $value .'<br />';
}
?>
Print_r doesn't help, I've searched around and couldn't find too much to help with. Any ideas. Thanks
Update 1
It's not an Array issue, it's simply that _www doesn't seem to be able to capture this data. Even when I pipe the output to a file I get the same result. Using exec() I get a very limited result, but when I run the same command in the terminal I get full results.
Any thoughts on allowing www user to access this extra data?

PSR2 with class declarations extending classes with namespaces in PHP Code Sniffer

I've hit a problem with PHPCS using the PSR2 standard. Have searched high and low but to my surprise I can't find anyone reporting the same issue.
Say I have a class declaration as follows:
<?php
class MyChildClass extends \SomeNameSpace\MyParentClass
{
}
Then I run it through PHPCS with:
bash-3.2$ phpcs -s --standard=PSR2 test.php
FILE: test.php
--------------------------------------------------------------------------------
FOUND 2 ERROR(S) AFFECTING 1 LINE(S)
--------------------------------------------------------------------------------
3 | ERROR | Expected 0 spaces between "SomeNameSpace" and comma; $1 found
| | (PSR2.Classes.ClassDeclaration.SpaceBeforeComma)
3 | ERROR | Expected 1 space before "MyParentClass"; 13 found
| | (PSR2.Classes.ClassDeclaration.SpaceBeforeName)
--------------------------------------------------------------------------------
Time: 0 seconds, Memory: 4.00Mb
Also:
Bash-3.2$ phpcs --version
PHP_CodeSniffer version 1.3.6 (stable) by Squiz Pty Ltd. (http://www.squiz.net)
Has anyone come across this? Am I doing something wrong? Otherwise I'm going head first into the sniffer code - which doesn't feel right.
The PSR-1 and PSR-2 standard inside the current release of PHP_CodeSniffer are not complete. I didn't ever mention them in the release notes so people obviously either just found them, or they are talking about the current dev version, where they are complete.
If you want to try out the complete version of PSR-2 inside PHP_CodeSniffer, you'll need to clone the git repo and use it directly:
git clone git://github.com/squizlabs/PHP_CodeSniffer.git
cd PHP_CodeSniffer
php scripts/phpcs --standard=PSR2 /path/to/code
Or you can wait for the official release, which I'm planning for sometime next week, assuming no major issues are reported.
If you run the latest dev version on the code you supplied, you'll get this:
2:PHP_CodeSniffer gsherwood$ php scripts/phpcs --standard=psr2 temp.php
FILE: /Users/gsherwood/Sites/Projects/PHP_CodeSniffer/temp.php
--------------------------------------------------------------------------------
FOUND 2 ERROR(S) AFFECTING 2 LINE(S)
--------------------------------------------------------------------------------
3 | ERROR | Each class must be in a namespace of at least one level (a
| | top-level vendor name)
5 | ERROR | Expected 1 blank line at end of file; 0 found
--------------------------------------------------------------------------------
Time: 0 seconds, Memory: 4.25Mb
Hope that helps.

Categories