FAQ
|
This documentation is not for the latest version Pacemaker version. Click here to switch to version 1.2 |
Composer runs into auth issues on my Mac OS X machine.
Question
As Solution Partner or Customer, you received a ext12345 username together with a token. This gives you access
via composer to the necessary libraries. These credendials have to be added in your auth.json, which can for
example be in the source directory of your project like src/auth.json.
Example:
{
"http-basic": {
"gitlab.met.tdintern.de": {
"username": "ext00000",
"password": "asaZIjkUIollKSADnrlm"
}
}
}Whenever composer will be invoked, these credentials will be used for the HTTP download, composer will do. In some cases you’ll receive a message from composer that you’ll not have the necessary access rights to install pacemaker or one of it’s packages.
Answer
Mac OS saves the credentials in the keychain on host level (https://gitlab.met.tdintern.de). When invoking
composer the first time, and it doesn’t matter from which project, the first host entry from the keychain will
be used and not the one from the auth.json anymore. This may lead to the problem, that pacemaker libraries can
not be loaded anymore because of missing access.
As generally you’ll access the GIT repositories over SSH, in case of pacemaker it will be necessary to disable the caching of the credentials of the system for HTTPS calls. Therefore execute the following commands to remove the credential helper fom the GIT configuration
git config --local --unset-all credential.helper \
&& git config --global --unset-all credential.helper \
&& git config --system --unset-all credential.helperAfter that, the credential helper has to re-initialized empty (because any other tool like xCode for example may also use it) with the following command
git config --global --add credential.helper "" && composer clear-cacheFinally search in the keychain tool for met and delete the entry gitlab.met.tdintern.de. If the
keychain has been deactivated, in the future GIT should ALWAYS use the credentials from the auth.json
from your project or the global one.
The performance on the production/staging system is worse than on my local machine!
Question
The performance between your local and any other system differs significantly. What can be the reason?
Answer
Probably the MySQL transaction log has different settings. The option
innodb_flush_log_at_trx_commit
by default has the value 1. This means, that the transaction log will be written by MySQL after each commit.
This option controls the balance between strict ACID compliance for commit operations and higher performance that
is possible when commit-related I/O operations are rearranged and done in batches. Setting this value to 2,
you can achieve better performance, but then you can lose transactions in a crash.
Possible values are
0 |
write and flush once per second |
1 |
write and flush at each commit |
2 |
write at commit, flush once per second |
For example, switching this value from 1 to 2 the import performance improves
from 02:06:10 to 00:03:29 h which is for sure significant
| ID | Pipeline | Created | Finished | Duration |
|---|---|---|---|---|
219 |
xxx_import_catalog |
Oct 24, 2019 2:47:04 PM |
Oct 24, 2019 4:53:14 PM |
02:06:10 h |
221 |
xxx_import_catalog |
Oct 24, 2019 5:02:02 PM |
Oct 24, 2019 5:05:31 PM |
00:03:29 h |