I think you had a bad test.
That's a little strong.
I may or may not agree, but let's see.
js const funt = (url) => {const started = Date.now(); for (let i = 0; i < 5; i++) { visitUrl(url); } print( Date.now() - started);}; funt("council.php");funt("api.php?what=events&for=Antilag_by_Irrat");
You were calling api.php without any params, so it would exit faster is my impression.
Your impression is correct, and is a good point.
api.php with no parameters gives boilerplate response telling you how to use the call.
It doesn't actually hit up any user data.
I added this to PingRequest:
Code:
private void addFormFields() {
switch (this.pingURL) {
case "api.php" -> {
this.addFormField("what", "status");
this.addFormField("for", "KoLmafia");
}
}
}
And instead of taking from 20-40 msec per test, it's taking 36-65.
My login "goal" would need to be 40, rather than 30.
The advantage of "status" is that it hits up a lot of KoL user data - and is constant, while you are idle (although you need not be idle while executing it; ping() measures the elapsed time of each request separately, rather than the duration of the whole test, from beginning to end).
I changed "status" to "events" and I'm getting from 27-54 msec per test. That's looking at user state, but is NOT constant, since events can come in at any time. With no events, the data per ping is 2 bytes...
I managed to hit a bad server and had both numbers increase as expected. But when removing the params from api.php, I've noticed it is a lot quicker.
Aka, it takes less work for the server to give us a reply, which isn't what we want. Since we want to measure the workload.
I don't think I agree with that.
Consider what we are testing.
KoL has a number of servers on AWS.
They may or may not all be the same type.
They may be in a single region, or they may be spread across several regions.
What do we test?
1. On your computer
KoLmafia makes a request to KoL.
2. In the network
It travels from your computer to an AWS server (at the whim of Internet routers.)
It is handed off to a specific server associated with your session.
3. On KoL's server
The server hands it off to a process/thread to handle your session.
That does some amount of setup to connect to your user/session.
It handles the request and sends the reply.
4. In the network
The reply makes its way back to your computer.
5. On your computer
It is given to KoLmafia, which, itself handles the reply.
We measure the duration of that whole sequence, sans KoLmafia's processing time for the response.
(That's why PingRequest bypasses that; if you use council.php, we do not parse the council text.)
(That is also why the "ping" command and function measures the elapsed time of each request and totals them, rather than including script execution and such.)
We are interested in 2-4, but 2 and 4 are not KoL's fault, as such.
Only 3 is the result of load on KoL's server.
Only 3 is "the workload".
Yes, we want to measure "the workload". Where you and I may disagree is that I think any "constant" task on KoL's server is fine; much of the variation will result from task scheduling in competition with other user tasks. If you have to look up user state, perhaps database contention. If you have to change user state, even more of that.
I do literally all of my ascension in the Relay Browser. Only in aftercore do I automate turns. And the server differences are very noticeable when, for example, I stasis a combat and the combat rounds just scroll on by in the gCLI as opposed to having a second or more between each round. And I observe that if api.php (no arguments) is <= 30 msec, rounds flow on by speedily.
Would it be more accurate to use api.php?what=status and use a goal of <= 40? For me? Probably not. For other people who, for some reason, "don't see api.php times increasing" as the server is more loaded? Perhaps.
I'm going to add two more options for ping testing: the page to use and the number of iterations.
You want ping() - as executed at login - to hit council.php 5 times? Go for it.
I'm not sold on api.php?what-status, since I see measurable difference even without the arguments. To my eye, all the arguments do is slow down the tests. I will experiment more.
