Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve performance during composer install/update events #9

Open
fago opened this issue Jan 1, 2017 · 4 comments
Open

Improve performance during composer install/update events #9

fago opened this issue Jan 1, 2017 · 4 comments
Assignees
Labels
Projects

Comments

@fago
Copy link

fago commented Jan 1, 2017

I really like the idea of the package, but I'm worried by its performance. composer install is very fast if everything if is in place, but only adding 1 phar via tooly composer install gets already delayed by a few seconds.

Expected behavior

composer install should stay fast and be done immediately if everything is in place

Actual behavior

composer installed gets delayed by multiple seconds. It looks like the tools downloads the phar just to verify the checksum.

Steps to reproduce actual behavior

  • Configure the project for one phar
  • Run composer install multiple times

Other information (e.g. version, os system, stacktraces, etc)

I used v1.2.2 with PHP7

@tommy-muehle
Copy link
Owner

tommy-muehle commented Jan 2, 2017

Hi fago,

thanks for your feedback.

Performance is an aspect with many many variables (internet connection, proxy-connection, VPN, OS system, PHP version, xdebug, composer version, global composer plugins and requirements, ...).

Personal for me and others, for example the guys in my company, no one has mature performance impacts.

But to help you i need some more informations:

  • which PHAR are you downloading?
  • PHP 7.0 or 7.1?
  • are you using some global composer plugins? (composer global show -i)

Can you please post this values?

By the way, i also try to profile tooly with blackfire.io. But i still have some problems at the time. See: https://twitter.com/tommy_muehle/status/815813348973547520

My (fast) local test with the five PHAR's required for tooly are checked in 4,4s (without update).

Best regards
Tommy

@tommy-muehle tommy-muehle self-assigned this Jan 2, 2017
@tommy-muehle
Copy link
Owner

tommy-muehle commented Jan 6, 2017

I've got it to work on blackfire with a workaround which simulate the initialization of the script via composer.

Here is the profile:
https://blackfire.io/profiles/bf8cf002-9e65-42a9-a6c3-d51b831351e4/graph

It shows the average of 5 calls. But without the overhead from composer. So for example composer loads all global plugins before executing commands. In my workaround is this not included.

But you're right @fago that the bottleneck is the checksum verifiy. But tooly does'nt download the files for verification. See here and here.

I will try some improvements to increase the performance. And maybe someone else has a hint.

@fago
Copy link
Author

fago commented Feb 19, 2017

The performance issue was definitely caused by a network delay, not a few function calls. I've been using tooly with https://github.com/drunomics/phapp-cli/releases/download/0.2.3/phapp.phar and no global plugins. I just replaced with a simple ScriptHandler which only downloads the file when necessary, what works just fine and is fast. However, I like the idea behind tooly and I'd prefer using it if would work as fast.

https://github.com/tommy-muehle/tooly-composer-script/blob/master/src/Script/Helpe/Verifier.php#L38

Isn't that the problem? sha_file will just download the remote file on every check, what makes it slow.

@fago
Copy link
Author

fago commented Feb 19, 2017

For reference, this is the ScriptHandler I ended up using: https://gist.github.com/fago/8a3d8939bb07ff32b627e4a6ddd72429
I just hard-coded it to only install in dev-mode as that is fitting my use-case.

@tommy-muehle tommy-muehle added this to Review in Default Mar 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Default
Review
Development

No branches or pull requests

2 participants