Merge TODOs
This commit is contained in:
parent
3a303015f8
commit
b7bfaf02c9
|
@ -1,59 +0,0 @@
|
||||||
Cope with possibility of duplicate uuid, in e.g. queue/fanout/direct.
|
|
||||||
If a subscription token matches an existing subscription, there's a
|
|
||||||
collision, so choose a new token until there's no collision.
|
|
||||||
|
|
||||||
SAX-style sexp reader/writer, so that we can do something sensible for
|
|
||||||
enormous (e.g. gigabyte-sized) messages.
|
|
||||||
|
|
||||||
The "meta" exchange probably wants to be a topic exchange. Or
|
|
||||||
something.
|
|
||||||
|
|
||||||
The "meta" exchange probably wants to emit how-things-are-now messages
|
|
||||||
when people subscribe to it, to get them started; a kind of
|
|
||||||
last-value-cache type thing.
|
|
||||||
|
|
||||||
Website
|
|
||||||
- http://www.flickr.com/photos/elemishra/158211069/
|
|
||||||
|
|
||||||
Switch from indirect scheduling to direct scheduling
|
|
||||||
- before, on walk: 173kHz test1/test3
|
|
||||||
- after, no change. Probably because we only have a single thread
|
|
||||||
active in the system when running test1/test3, so every time some
|
|
||||||
work comes in, it baton-passes to the next guy in the chain. The
|
|
||||||
change *would* be an improvement but we have a separate worklist
|
|
||||||
(to process now) and runlist (to process after polling for events
|
|
||||||
once) so it always goes back to the scheduler because the worklist
|
|
||||||
is never longer than one.
|
|
||||||
- Revisit once we start testing multiple concurrent streams.
|
|
||||||
|
|
||||||
|
|
||||||
Extension to Sexps:
|
|
||||||
|
|
||||||
- ! <simplestring> <value> : binds the simplestring to the value when
|
|
||||||
seen. Note that the new binding for simplestring is NOT in scope
|
|
||||||
during parsing of the value, so no circular data can be constructed
|
|
||||||
this way. Any previous binding is discarded *after* the value is
|
|
||||||
completely read.
|
|
||||||
|
|
||||||
- ? <simplestring> : retrieves the bound value of the simplestring.
|
|
||||||
|
|
||||||
So
|
|
||||||
!1:a11:hello world(?1:a1: ?1:a1: ?1:a)
|
|
||||||
is equivalent to
|
|
||||||
(11:hello world1: 11:hello world1: 11:hello world)
|
|
||||||
|
|
||||||
And, more to the point, after a receiver has seen
|
|
||||||
!1:a36:af49f5dc-0454-4ba1-9f48-a55e9c10ee35
|
|
||||||
then a simple
|
|
||||||
?1:a
|
|
||||||
is all that's needed to refer to that gargantuan UUID.
|
|
||||||
|
|
||||||
Another example:
|
|
||||||
!1:a()!1:a(?1:a?1:a)!1:a(?1:a?1:a)?1:a
|
|
||||||
is equivalent to
|
|
||||||
((()())(()()))
|
|
||||||
|
|
||||||
|
|
||||||
"Having metrics around as many things as possible really helped us
|
|
||||||
identify a difficult problem to diagnose."
|
|
||||||
-- https://github.com/blog/767-recent-services-interruptions
|
|
64
server/TODO
64
server/TODO
|
@ -1,5 +1,69 @@
|
||||||
|
## OCaml server
|
||||||
|
|
||||||
- use lazy and Lazy.force where appropriate
|
- use lazy and Lazy.force where appropriate
|
||||||
|
|
||||||
- Figure out how to avoid the overhead of Message.message_of_sexp
|
- Figure out how to avoid the overhead of Message.message_of_sexp
|
||||||
- straight matching of sexps without translation gives a ~5% speedup
|
- straight matching of sexps without translation gives a ~5% speedup
|
||||||
- checking for "post" first in message_of_sexp gives a ~3% speedup
|
- checking for "post" first in message_of_sexp gives a ~3% speedup
|
||||||
|
|
||||||
|
## General
|
||||||
|
|
||||||
|
Cope with possibility of duplicate uuid, in e.g. queue/fanout/direct.
|
||||||
|
If a subscription token matches an existing subscription, there's a
|
||||||
|
collision, so choose a new token until there's no collision.
|
||||||
|
|
||||||
|
SAX-style sexp reader/writer, so that we can do something sensible for
|
||||||
|
enormous (e.g. gigabyte-sized) messages.
|
||||||
|
|
||||||
|
The "meta" exchange probably wants to be a topic exchange. Or
|
||||||
|
something.
|
||||||
|
|
||||||
|
The "meta" exchange probably wants to emit how-things-are-now messages
|
||||||
|
when people subscribe to it, to get them started; a kind of
|
||||||
|
last-value-cache type thing.
|
||||||
|
|
||||||
|
Website
|
||||||
|
- http://www.flickr.com/photos/elemishra/158211069/
|
||||||
|
|
||||||
|
Switch from indirect scheduling to direct scheduling
|
||||||
|
- before, on walk: 173kHz test1/test3
|
||||||
|
- after, no change. Probably because we only have a single thread
|
||||||
|
active in the system when running test1/test3, so every time some
|
||||||
|
work comes in, it baton-passes to the next guy in the chain. The
|
||||||
|
change *would* be an improvement but we have a separate worklist
|
||||||
|
(to process now) and runlist (to process after polling for events
|
||||||
|
once) so it always goes back to the scheduler because the worklist
|
||||||
|
is never longer than one.
|
||||||
|
- Revisit once we start testing multiple concurrent streams.
|
||||||
|
|
||||||
|
|
||||||
|
Extension to Sexps:
|
||||||
|
|
||||||
|
- ! <simplestring> <value> : binds the simplestring to the value when
|
||||||
|
seen. Note that the new binding for simplestring is NOT in scope
|
||||||
|
during parsing of the value, so no circular data can be constructed
|
||||||
|
this way. Any previous binding is discarded *after* the value is
|
||||||
|
completely read.
|
||||||
|
|
||||||
|
- ? <simplestring> : retrieves the bound value of the simplestring.
|
||||||
|
|
||||||
|
So
|
||||||
|
!1:a11:hello world(?1:a1: ?1:a1: ?1:a)
|
||||||
|
is equivalent to
|
||||||
|
(11:hello world1: 11:hello world1: 11:hello world)
|
||||||
|
|
||||||
|
And, more to the point, after a receiver has seen
|
||||||
|
!1:a36:af49f5dc-0454-4ba1-9f48-a55e9c10ee35
|
||||||
|
then a simple
|
||||||
|
?1:a
|
||||||
|
is all that's needed to refer to that gargantuan UUID.
|
||||||
|
|
||||||
|
Another example:
|
||||||
|
!1:a()!1:a(?1:a?1:a)!1:a(?1:a?1:a)?1:a
|
||||||
|
is equivalent to
|
||||||
|
((()())(()()))
|
||||||
|
|
||||||
|
|
||||||
|
"Having metrics around as many things as possible really helped us
|
||||||
|
identify a difficult problem to diagnose."
|
||||||
|
-- https://github.com/blog/767-recent-services-interruptions
|
||||||
|
|
Loading…
Reference in New Issue