Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Areas of improvement #705

Open
RichardHightower opened this issue May 3, 2016 · 0 comments
Open

Areas of improvement #705

RichardHightower opened this issue May 3, 2016 · 0 comments

Comments

@RichardHightower
Copy link
Member

Queue batch size of 1 as the new default

Queues should start with a size of 1, i.e., the QueueBuilder should create a queue with a queue size of one by default. This will help new projects get off the ground and help new people get started w/o getting bitten. If you want speed and throughput, increase the batch size.

ServiceQueue, ServiceBundle, Vertx EventBus Bridge, EndpointServer method dispatch

We have reworked ServiceQueue so it can run in a bundle, it can run alone and it can run in a bundle which is backing an endpoint server. But the design has not kept up with the features. In fact we have more than one way to do the dispatch. The new improve way which the Vertx EventBusBridge uses and the old way, which was sort of put together under duress, but has some possible important perf stuff in it (sometimes ugly code is ugly because it is ugly and sometimes it is ugly for performance). The dispatch has to be documented and understood and possible refactored, but in such a way that does not break working fairly performant code. I am thinking of doing EndpointServer2 and doing the refactor there w/o breaking EndpoitnServerImpl and then slowly move over to ES2 once we can perf test ES1 vs. ES2. The process must start with looking at the current design, (documenting it and understanding it), and then see if there is any improvements to be made.

Thread model of Queue

The Thread model of Queue is ok. It is not flexible. It is tuned for a certain common work load. It would be nice if we could revisit this. I am thinking about moving out the Queue out of core into a new lib called Kueue. Then refactoring the threading model there. You could use the current Queue in any thread model you like, but you would have to write the code yourself. I think we can do better than this.

ServiceBundle

ServiceBundle was originally the dispatcher and it had many service queues to manage. ServiceBundle is the way you manage service pools and round robin and service shards and all sorts of goodies. We need to document the design and then do a refactor after the Thread model Queue refactor. Again, I want to start with a ServiceBundle2, and refactor it and then eventually cross over to using ServiceBundle2.

Not broken

None of this is to say that things are broken, but it is time to look at them again now that we are more feature complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant