Plumbling Life's Depths

So I'm wondering what other people do in this scenario:

• You have an executable that provides a (networked) service
• You want to test against the executable's service
• You want to be able to start/stop the executable during the tests
• You want to be able to run multiple executables between test suites (i.e. with different configs for each suite of tests)

I'm mostly been using subprocess, and this works; but I always seem to wind up with situations where the child process is hung, or winds up running past the execution of the tearDown() for the suite.  Any given failure can almost always be fixed, but it always feels messy and low-level, and it just feels like there should be something better.

So, how do you run captive servers?

Got started on testing performance tonight for ChatTrack.  Wow.  Nowhere near where it needs to be, not even on basic page rendering... seeing something like 14.5rps sustained on 1000 requests with 100 concurrency, and there's significant numbers of requests taking more than 4s to reply (eep!).  And that's on the laptop, the poor little virtual server is just going to keel over.

Good news is, I haven't optimized much yet, just tested, so likely there's just something "oopsie"'d in there. I can see at least 2 queries for the user record on each request... that's not right. There also appears to be some unnecessary queries for the survey options. After that, it's off to the wonderful world of caching! And at some point I need to test the streaming-scaling...

I did find some time to work on the actual presentation this evening, but the next two days I'm off on paying customer's work, so no work on the PyCon stuff for a bit. Still, presentation is shaping up well.

from tftpy.TftpServer import TftpServer
TftpServer( 'tftp' ).listen( 'localhost', 8069 )

Which serves up the files in the 'tftp' directory on port 8069 (69 is the standard tftp port).  To download an existing file from the server:

from tftpy.TftpClient import TftpClient
TftpClient( 'localhost',8069).download( 'exists', 'downloaded.txt' )

Enabling the epoll reactor in Twisted is a two-line change:

from twisted.internet import epollreactor
epollreactor.install()
from twisted.internet import reactor

From there on the app is unchanged.  I didn't have time to really test that today (paying work and all), but I don't really expect to see much of a change.  EPoll is about scaling up, and my current speed annoyances are all about single-query latencies (I see most queries taking 300-430ms).

Anyway, I've got more paying work to get done this week, so the ChatTrack stuff is going to have to wait a bit.  It needs to be done for PyGTA's PyCon Dress Rehearsal on the 19th at the latest, but I can likely get another 2-3 days between then and now, maybe as much as a week if I finish these projects with few speed-bumps.

Just spent hours tracking down the "DOCSIS TLV" config-file format and implementing it.  This is one of those things where the project spec says "do what that spec says to do", pointing you at a deprecated version of the big spec, then the updated version of that spec says "do what this other spec says to do", but that spec is then defined in terms of 2 other specs... an enormous amount of reading to specify something that can be described in a tiny amount of code.

The key thing that gets left out AFAICS is that the spec is recursive; so for option 43.1, 43.2, or 43.3.4.5.2.3.4.5.6, for example, you do all of the encoding steps as though you were doing a top-level encoding for the various named (numbered) sub-options at each level, then you break the resulting (potentially very long) value into 255-byte chunks of top-level encodings.  For instance, our last example there with a value of 'hello' looks like:

[43,21,3,19,4,17,5,15,2,13,3,11,4,9,5,7,6,5,104,101,108,108,111]

Once you actually get all that, it's one of those relatively simple specs that likely should just be wrapped up in a standard library... but that would be hundreds of times more work than putting together something that can do what you need for this tiny project.

There are likely stupid little corner cases, such as whether to do splitting of long option-values only at the top-level, or whether you are intended to also split them in the recursive elements if an individual sub-element is > 255 chars.  There's also some checksums and the like, basically just some sha1 hashes.

The fact that you need lookup tables for all non-trivial interpretation makes the whole thing look way too messy to bother with beyond the needs of your clients of the day.  In the example above, unless you know that 43.3 has internal structure you can't parse the result meaningfully.  It might just as easily be a single long string.  The T (type) in TLV is just a single-byte-integer reference into the current table space, not a direct data-type value.  Those tables are vendor, and potentially even project, specific, so you then need to create a mechanism for users to define the tables... ick.  Makes one appreciate context-free formats all the more.

Finally got a URL set up for the little chatting application.  And actually sat down and played with it for a while with the 3 browsers I have handy (Firefox 3.5, Chromium and IE .  Good news is that (after having to fix a known jquery-on-ie bug), it all seems to pretty much work.  Bad news is that there's lots of little fit-and-finish bugs, UI elements that just don't quite work.  Most are little things that can each be easily coded around, but there's likely a solid day's work in there with all of them.

One that's very annoying is that  Chromium seems to get "tired" after a while if there are too many incoming messages.  I gather something in JQuery gets borked, as the symptom is basically that "K" is not defined (ah, the joys of compressed js).  Speaking of which, I ran the JS and CSS through YUI compressor.  I've done that before, but tonight I realized, why not just gzip compress the minimized results?  Saves rather a lot of transfer; almost 500KB down to 71KB for the js and from 34KB down to 5KB for the CSS.  Seems to work perfectly fine in the 3 big browsers.  Of course, once I finished and actually tested, it doesn't really make much of a difference to the user, as everything is in the cache after the first page-hit.

I'm really not satisfied with the main query-speed so far.  Seeing ~400ms for the page load.  Will have to track that down if I'm going to have even a dozen simultaneous users, let alone hundreds.  The streaming seems perfectly fine, it's just the initial page-load that's taking far longer than I'd like.

I also spent quite a while trying to set up Ajax login... then finally decided that I'll have to just go with non-Ajax login for now; the repoze.who.friendlyform stuff just isn't set up to do async login and fixing that isn't something I want to spend time on right now.