search

LoyaltyNZ / alchemy-framework

Alchemy is a framework for creating highly available systems that are built from micro-services
GNU Lesser General Public License v3.0
676 stars 18 forks source link

Any performance analysis? #1

Open xiamx opened 8 years ago

xiamx commented 8 years ago

Would be nice to show :)

grahamjenson commented 8 years ago

Have you got any ideas about how to go about this, and what exactly to compare? Maybe a load balanced Passenger application versus a load balanced Alchemy application. This application could be almost identical as they could both be implemented in Sinatra.

An important part would be inter-service communication as well. So maybe service A calls service B calls service C and returns the result of C to the client. We could have three nodes each running running service A, B, and C, so have three service instances of the service across the grid at a time.

Then the question would be how would the Passenger services call each other? They could call through the load balancer to get distributed to other nodes, or they could use some service discovery mechanism like Consul to get simple load balancing, or they could call the service directly and get no load balancing. If you call the service directly then there is no load balancing and this would then not be a direct comparison. It is difficult to get the same features.

I am working on this, but any preliminary tests in a PR would be awesome. e.g. a PR that included a similar vagrant+coreos box but running services that are passenger based instead of alchemy based.

matiasinsaurralde commented 8 years ago

:point_up:

jeremyolliver commented 8 years ago

If you take this route, the official passenger docker images might speed-up / simiplify the test setup https://hub.docker.com/r/phusion/passenger-full/

xiamx commented 8 years ago

From what I read, RabbitMQ does the routing, and both external requests and internal requests have to go through RabbitMQ for load balancing. So the message broker could be a potential bottleneck. It would nice to compare this to consul based microservices, where load balancing is done at client level (via DNS round robbin.) This is essentially as @grahamjenson proposed.

Another possibility is to see how system performs when it is partially unavailable. In a consul based system, some requests will probably just timeout and the request gets lost before consul stands up to remove unavailable services from the pool. In alchemy, we leverage at least once delivery guarantee of RabbitMQ, is it likely that we are going to see less timeouts?