New r124/ydb312_gtm8182g subtest (tests YottaDB/YottaDB#312 in r1.24) #341
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nars1
requested changes
Jul 26, 2018
r124/inref/ydb312gtm8182g.m
Outdated
|
|
||
| getPaths | ||
|
|
||
| SET INST1path=$ZTRNLNM("path_INST1","","","","","VALUE") |
r124/outref/ydb312_gtm8182g.txt
Outdated
| Create the DB | ||
|
|
||
|
|
||
| %GDE-I-GDUSEDEFS, Using defaults for Global Directory |
There was a problem hiding this comment.
GDE outputs don't need to be in reference file. Instead a line saying GBL1.gld and GBL2.gld are created to point to mumps.dat and a.dat respectively is enough. Also indicate both gld files point to mumps.repl instance file.
r124/outref/ydb312_gtm8182g.txt
Outdated
|
|
||
| %GDE-I-GDCREATE, Creating Global Directory file | ||
| ##TEST_PATH##/GBL2.gld | ||
| # Start INST1 INST2 replication |
There was a problem hiding this comment.
replication -> replication with mumps.gld as $zgbldir
r124/outref/ydb312_gtm8182g.txt
Outdated
| Starting Primary Source Server in ##TEST_PATH## | ||
| Starting Passive Source Server and Receiver Server in ##FILTERED##_REMOTE_TEST_PATH_/instance2 | ||
|
|
||
| # Run ydb312gtm8182g.m to update DB through GBL1 and GBL2 |
There was a problem hiding this comment.
GBL1 and GBL2 -> GBL1.gld and GBL2.gld
r124/outref/ydb312_gtm8182g.txt
Outdated
|
|
||
| Before updates: | ||
| ----------------: | ||
| Attached processes: 1 |
There was a problem hiding this comment.
Attached processes -> # of processes attached to journal pool of mumps.repl
r124/u_inref/ydb312_gtm8182g.csh
Outdated
| ################################################################# | ||
| # | ||
| setenv gtm_repl_instance "mumps.repl" | ||
| unsetenv gtm_db_counter_sem_incr # avoid semaphore counter overflow |
There was a problem hiding this comment.
Add comment that otherwise they inflate semval which affects the reference file.
r124/u_inref/ydb312_gtm8182g.csh
Outdated
| setenv gtm_repl_instance "mumps.repl" | ||
| unsetenv gtm_db_counter_sem_incr # avoid semaphore counter overflow | ||
|
|
||
| #setenv ydb_gbldir "GBL3" |
There was a problem hiding this comment.
Please remove commented lines if they are no longer relevant. They are found in various sections of this .csh file.
r124/u_inref/ydb312_gtm8182g.csh
Outdated
| # add -segment cusseg -file=cus.dat | ||
| # C[HANGE] -S[EGMENT] segment-name [-SEGMENT-qualifier...] | ||
|
|
||
| setenv ydb_gbldir "GBL1" |
There was a problem hiding this comment.
Remove any ydb_gbldir usages. Just gtmgbldir usages are fine since that is what the test framework works with.
r124/u_inref/ydb312_gtm8182g.csh
Outdated
|
|
||
| setenv ydb_gbldir "GBL1" | ||
| setenv gtmgbldir $ydb_gbldir | ||
| setenv GBL1 "GBL1.gld" |
There was a problem hiding this comment.
Can we avoid this extra GBL1 and GBL2 variables?
nars1
approved these changes
Jul 30, 2018
nars1
added a commit
to nars1/YottaDBtest
that referenced
this pull request
Aug 14, 2018
nars1
added a commit
that referenced
this pull request
Aug 14, 2018
nars1
pushed a commit
that referenced
this pull request
Jun 9, 2021
…3-009 performance improvement for conversion utilities This commit adds a new v63009/gtm9115 test based heavily on the r130/ydb485 test that tests $HO, %OH, %DO and %OD for correctness and improved performance compared to the pre V6.3-009 versions in a similar manner to how r130/ydb485 tests %HD and %DH. The test also tests the YDB#685 changes. Portions of the test that test YDB#685 are marked accordingly in the reference file. This commit also makes some changes to the r130/ydb485 test to speed it up by reducing various 15 second stages to 2 seconds.
nars1
pushed a commit
that referenced
this pull request
Jun 9, 2021
This commit fixes 2 test failures: * The mpt_extra/conv test failed with the YDB#685 changes because a `%OH` on `1294` previously returned an empty string instead of `A` and the test was not updated to reflect the new behavior of %OH. * The performance section of the v63009/gtm9115 test was failing occasionally under load. The fix for this is to move that section into a new timing/gtm9115 test. Should the timing/gtm9115 test fail, it will need to be modified to use CPU time instead of elapsed time.
nars1
pushed a commit
that referenced
this pull request
Jun 9, 2021
…15 and r130/ydb485 tests This commit addresses test failures in the performance comparison section of the timing/gtm9115 and r130/ydb485 tests by switching them to use 2 seconds of CPU time instead of 2 seconds of elapsed time. It also treats anything above 90% of the previous implementation as a pass for the 14 digit %HO comparison because the new implementation, which is usually slightly above 100% of the previous implementation's performance, came in at 94.72% once in internal testing out of 100 runs using CPU time.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Sets up and tests the following test case
Add test case where DB1 is in GLD1 and DB2 is in GLD2 and DB1/DB2 are in GLD3. And source server is started with GLD3.
And all of GLD1/GLD2/GLD3 use the same mumps.repl file. Now a process that updates through GLD1 and GLD2 should
attach to the journal pool only once. And the ftok semaphore counter should be bumped only once, not twice.