README.md in worker_roulette-0.1.0 vs README.md in worker_roulette-0.1.1

@@ -119,15 +119,15 @@
 ```
 
 ## Performance
 Running the performance tests on my laptop, the numbers break down like this:
 ### Async Api
-  - Manual: ~4200 read-write round-trips / second
-  - Pubsub: ~5200 read-write round-trips / second
+  - Pubsub: ~5500 read-write round-trips / second
+  - Manual: ~4500 read-write round-trips / second
 
 ### Sync Api
-  - Manual: ~1600 read-write round-trips / second
-  - Pubsub: ~2000 read-write round-trips / second
+  - Pubsub: ~2700 read-write round-trips / second
+  - Manual: ~2500 read-write round-trips / second
 
 To run the perf tests yourself run `bundle exec spec:perf`
 
 ## Redis Pubsub and Polling
 The `wait_for_work_orders` method works using Redis' pubsub mechanism. The advantage to this is that it is very fast and minimizes network traffic. The downside is that Redis' pubsub implementation is 'fire and forget', so any subscribers who are not listening at the moment the message is published will miss it. In order to compensate for this, WorkerRoulette's Async Api creates a backup timer (using EM.add_periodic_timer) that will poll redis every 20-25 seconds for new work. Since the timer is reset every time new work comes in, if you have an active publisher, the timer may never need to fire. It only serves a backup to make sure no work is left waiting in the queues because of network problems. Since there is no one polling mechanism that works for all situations in a synchrounous environment, this feature is only available through the Async Api.