mirror of
https://github.com/php/pftt2.git
synced 2026-03-24 01:02:11 +01:00
Automated script running slow on VMs #43
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lavturo on GitHub (Aug 9, 2019).
Seems like there is a priority issue either with the script itself or the task scheduler. Makes it run the tests slower than usual.
This is a problem because the scheduler would try to run 2 instances of pftt since the previous run might not have finished from the previous day.
@cmb69 commented on GitHub (Aug 10, 2019):
The task runs with priority 7 which is BELOW_NORMAL_PRIORITY_CLASS. Did you try to run with, say, priority 5 (NORMAL_PRIORITY_CLASS) instead?
@cmb69 commented on GitHub (Aug 10, 2019):
We may also consider to change the automation strategy, so that only a single build is downloaded and tested, but this is scheduled for short periods (say, every 15 minutes). Something like:
The benefit would be that we're less dependent on the actual duration of the test runs; if they take more than 24h, so be it; if they take less, we could already run further tests if new builds are available.
@lavturo commented on GitHub (Aug 12, 2019):
Yeah, at first I was unsure of why the task was running slower, Thought it was the script itself. However, after a while I found that it was the priority was at 7. So for the time being I switched it to 4 or 5. I believe both of those are still considered normal priority.
To clarify, instead of testing all 4 builds (NTS/TS, x64/x86), we'll test 1 of them? If so, which combination should be tested?
The way I see it from how you have described it (please confirm if it is correct):
-If there is, stop the current test and download the new build to test.
-If there is not, let the test keep running.
Is there a certain way it should test the builds? Currently it checks through each version (7.1, 7.2, 7.3, 7.4). So if there is a new build in any of the versions, should it stop and switch to that one?
Or should it be testing by version? So first 7.1 (doing the check every 15 minutes), it finishes, then moves on to 7.2, does the same thing, and so forth until 7.4. After that it would repeat back at 7.1?
@cmb69 commented on GitHub (Aug 12, 2019):
My idea is a very rough one; I haven't yet considered the exact procedure. However, the main idea is to always finish a started test run, and not to start another test while one is already running (otherwise too much time may be wasted with halfway executed tests, which are useless).
Anyhow, if changing the priority makes all tests run within a day, we can leave it as it is for now.
@lavturo commented on GitHub (Aug 12, 2019):
On the 2016 server, so far it has been fine. However, on the 2012 R2 server, it seems to still run more than 1 instance. So at the very least, I think implementing something to check if there is an existing instance, either wait or stop that instance and start a new one.
@cmb69 commented on GitHub (Aug 13, 2019):
Some mechanism to prevent multiple PFTT2 instances from running in parallel could be generally useful.
In this case, however, we may want to concentrate on the 7.1 snapshots. Usually there are only a few snaps shortly before any release, and testing these additionally to the releases isn't of much help. So at least on the 2012R2 server just skipping 7.1 snapshot test would be fine.
More generally, we may want to skip tests of snapshots which have already been tested. Especially the stable branches do not necessarily have daily commits.
@lavturo commented on GitHub (Aug 13, 2019):
I found that in the task scheduler, there is an option that checks if the task is running. By default, it seems to be set at "do not start a new instance", however, as we have been discussing, there have been times where there are 2 instances.
I think an explanation for that is when I changed the priority level for the task, I had to re-import the task. So it might not have tracked that there was previously an instance running. The only reason I think this is because when I checked the 2016 server, it seemed to not have started a new instance. That also means the builds are taking longer to test than anticipated. A workaround would be to queue the next run. For the time being, I tried changing some settings for the task scheduler and the script itself (very small change). Also, I removed testing 7.1 for the 2012 server. I'm going to see if these changes make it run within the 24 hours.
As of now, the script checks if it already has the existing build. If so, don't test it again.
On another note, the only other thing I can think of is that when we switched to OpenJDK it might have been making the VMs test the builds slower. know when I first setup pftt on the VM, it was running a lot smoother. However, there have been various changes made since then, so it is hard to confirm if it was this change that made it slower.