/
Todo.txt
87 lines (80 loc) · 5.29 KB
/
Todo.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
6. Code review to get rid of any dodgy bits
6b. Code coverage and update tests where appropriate
6c. Review file structures
6d. Consider getting rid of any globals, e.g. hitURL
10. Need some validation in config to ensure various interdependent config items are put together - possibly include some sensible defaults
12. Need to allow command line options - especially for which config file to use
13. Consider serving up a results page with a link to the inflight results and any previous results
14. Save results to file in the first format for display later
15. Default page shows previous results "files", picking on launches with that data
Addedd a file list to charthandler
Need a new page that displays that list as URLs
Need a a stats handler that serves up the right file from its URL
Include some navigation
The active test is a special case?
Or can I read from the output file?
16. Look at using http://hdrhistogram.org/
17. Bundle template with exe
18. Ajax updates to the graph
20. URLs are currently hard coded in both the server and the HTML
21.
DONE
19. Finish off string together the different output handlers
20. Fix bug in DealWithIt. Reading the body leaves the ReadCloser empty for the parent e2f3b4e9f7b0a476d9ff4d2a8683f37703dff439
7. Need usable output from running gravo - see below OUTPUT
8. Allow addition of a validator - eval a user specified regex on the output
11. Extend verbose to dump out return from service calls - already a feature!
9b. Support for http verbs other than GET - See VERBS section below..a35d2fdcfbd57269e75aae596be545a9b190ba3c
9a. Get rid of references to soap as its actually related to the likes of post - 7cab1abd4292b7cdceedb12177d4c1a8aba4c5d8
6a. Run golang tools to validate code - 9c8efb5b0eff06793b99445ab262da9e097dc820
6d. Clean out junk from gravo - 9c8efb5b0eff06793b99445ab262da9e097dc820
5. Plumb interfaces for SOAP handling
5a. Write tests for iterator
5b. Update config (and tests) to correctly load and parse the template
5c. Construct the soap iterator with the template from the config
5d. Call the soap iterator
4a. Need to add a new method to soap iterator that includes a check on whether slices are correct length - commit e44c4c1d607cf26f7ddb95223c16f0886a9a3e65
3. Finish off support for URL file
1. Try a soap endpoint
2. Extend for different http verbs
4. Plumb interfaces for URL handling
VERBS
Currently support GET and POST. For POST I assume its soap related with a single URL. For GET its multiple URLs...
Can we shift to a mode where we infer what behaviour is required. The config specifies the verb. Then iterate over both the URLs and the data...
What to do when one of them runs out? Does a single URL imply repeatedly calling that URL?
Currently for SOAP we construct the URL from the config.
For now the simplest thing is to rename SOAP and extend to support any verb. Same for URL.
Can then use the "SOAP" flag to determine behavior...
OUTPUT
Write a new output handler that does the following:
| Captures the output as a timestamp (start of the request) plus time take to respond
- Streams that output to file as a simple CSV using the start of the run to help make the file unique
| Keep the data in memory
| Spin up a web server that serves up the Highlight template with a json call to a data endpoint on local host
| Provide a json endpoint for use by the web template
- Work out how to update the graph via ajax calls
| Pass in a command line flag that specifies a data file for display - don't run the test, just display
| Of course the http.ListenAndServe is a blocking call. Need to change the output handler to be a separate go routine.
- The routine will probably need a "have you finished" channel. The main thread can then wait for that. At some point
I can then add a "finish" to the web interface.
In the stats handler we can fire up the web server on a goroutine
The hanlder needs access to the data being populated by the perf test. Should do this via a channel to
ensure data is shared appropriately
| Change charthandler to check for existing of file rather than file name. If the file exists then load
the content. If it does, create it and output data to it
| Always pass a file name in to charthandler
| Use the filename (main part) as the URL for the results - will need to setup routing correctly
- When metrics come in to the handler need to both write the file and keep in memory
- Should these be separate? A handler that dumps to file, the other that holds in mem?
Found a good way of doing this. http://stackoverflow.com/a/16931348 shows how to
do a pubsub pattern in go. Basically you can use a fan out func to link one pub
channel to many (slice) other channels. I can use this to pass output from the
main gravo thread to the output handlers.
- Need to look into bundling the template in with the exe
Bug 20: Found a bug such that the DealWithIt chain of calls
doesn't work correctly. The first one works ok but passing the response
to the parent doesn't work because once an io.reader finishes you can't then
just reread it. Need to put a failing test in (somehow) and then find a
way to reset the reader. Also, sometimes we don't need the payload so maybe
don't need to read the full thing all the time...
Found https://medium.com/@xoen/golang-read-from-an-io-readwriter-without-loosing-its-content-2c6911805361#.9v0j1xahn