Move test_server module into testing.

[erikrose]

Where it was before, it looked like a test. Even renamed, it would have been strange to have it as a special, favored peer of testing, where all the other test machinery lived. Let's pull it and the Viceroy stuff into a testing package we can expand as necessary.

[posborne]

Probably for a later experiment, but I do wonder if the init inclusions will cause binaries to be larger as the crawler will pull in more python modules as a result.

Not at all concerned for this case (or probably in general for our sdk), it was just something that occurred to me as likely happening in some cases as I think it might trigger more eager inclusion of modules by componentize-py.

[erikrose]

Of course, as you know, nobody should be importing testing in their deployed app. :-) Structuring your stuff to avoid needless imports might be a good thing to include in our customer docs, though. I've started a basic outline for those as part of the Sphinx work.

It would be interesting to measure the size impact on the wizer'd wasm from importing an extra small module.

[erikrose]

It's chaos. Be sure to read all the way to the bottom.

A nearly-empty module costs 15K in wasm size. I added nearly_empty.py to fastly_compute…

nearly_nothing = 1

…and imported it in game-of-life:

from fastly_compute.nearly_empty import nearly_nothing

The difference in the resulting composed wasms was 15K:

-rw-r--r--  1 erik.rose  staff  49843951 Mar 25 11:33 compute-sdk-python/build/game-of-life.composed importing less.wasm
-rw-r--r--  1 erik.rose  staff  49859107 Mar 25 15:40 compute-sdk-python/build/game-of-life.composed.wasm

>>> 49859107 - 49843951
15156

I expect most of that to end up as runtime RAM use. It should be a ceiling, anyway, given how wizer works.

Then…

I tried making the imported module wholy empty. It increased wasm size 1543 bytes.

In fact, doing 2 consecutive builds of equal source just had a 16K variance for me.

What can we conclude?

1. Our build chain is aggressively nondeterministic, and I wouldn't mind digging into this some other month when I have the slack.
2. The addition of a mere empty module is lost in the noise of our nondeterminance.

Whee!

[posborne]

I expect most of that to end up as runtime RAM use. It should be a ceiling, anyway, given how wizer works.

That's somewhat surprising but doesn't totally blow me away; it wouldn't take too much to cause the allocator used leading into snapshotting to result in some fragmentation or other effects. Knowing python, there's probably an absurd number of individual heap allocations taking place during this initialization window (which is obviously a good motivator to snapshot).