4 ms·

You're making a big assumption here - that they don't batch events before publishing to Google's Pub/Sub system. The blog post says "We also added queuing and

You're making a big assumption here - that they don't batch events before publishing to Google's Pub/Sub system. The blog post says "We also added queuing and batching in the client. (This wasn’t first time that we needed to roll our sleeves up and reimplement a Google Cloud API client: in another project we implemented a high performance client for the Datastore API.)"

dmytton 11y ago
Batching doesn't make any difference to the pricing: > Batched calls are accounted for as multiple operations. https://cloud.google.com/pubsub/pricing https://cloud.google.com/pubsub/pricing
- CaveTech 11y ago
  Batching could mean they're aggregating calls prior to handing then off to google as a single request. If you have 64k minimum block size (guessing) you can stuff in many small requests before sending them off.
  - dmytton 11y ago
    Right but that only affects networking costs, because the batch is split out into individual publish API calls on Google's side, and that's what you're billed for.
    - deleted 11y ago
      [deleted]
- i0exception 11y ago
  Yes, but if I'm reading their blog post correctly, their individual messages are much smaller than 64K "Pub/Sub passed the test with flying colours. We published 2M messages without any service degradation and received almost no server errors from the Pub/Sub backend. Enabling batching and compression on the Event Service machines resulted in ~1Gbps of network traffic towards Pub/Sub."
  - dmytton 11y ago
    Yes, but that has no impact on the cost. It's a flat rate in 64kb blocks. Batching and compression would only affect the networking fees from Google, not the per API call fees. If you batch up 64 1kb messages into a single batch then Google still bills you for 64 publish API calls.
    - sharpy 11y ago
      They are wrapping small events into fewer larger ones. Hence the word batching. I have 64 1k messages? Ok, I am going to put them inside a single 64k message and reduce my request count by 64x, and profit!
      - foota 11y ago
        "Batched calls are accounted for as multiple operations." - https://cloud.google.com/pubsub/pricing https://cloud.google.com/pubsub/pricing
        deleted 11y ago
        [deleted]
        sharpy 11y ago
        Right. If you look at the API, the publish API allows you to push multiple messages in a single API call, and if that is the batching - publishing multiple messages - then yes, you and others are absolutely correct that there is no cost benefit. But rather than publishing { "messages" : [ { message 1 }, { message 2 } ] } You publish { "messages" : [ { container message containing both, still less than 64k } ] } Then you've reduced your operations count by half. Cloud services like this have a per message overhead, for things like auditing and delivery tracking, which is why the pricing model is what it is. If you are ok with having to unpack and process multiple messages at once as I've described, then it's a way to optimize against the pricing model.
        foota 11y ago
- falsedan 11y ago
  I think what people are proposing is that instead of: 64 1k messages for Events, sent individually or in a batch they suggest: 1 64k message for BatchedEvent
  - dmytton 11y ago
    That doesn't match the graphs Spotify post in their blog post. If the batch gets split out into individual operations then Google still prices for each message and each message gets delivered to the consumer. If it's just a single message that'd show up as a single message as far as Google is concerned, which is not what the Spotify test is showing.
- patrickmclaren 11y ago
  Note by "queuing and batching" Spotify may be aggregating events client-side. Given that messages are priced in 64K increments, it would be most cost efficient to to get each message as close to 64K as possible. i.e. # serialized: 1 message, 1 op publish("['foo', 'bar']") # instead of: # a) 2 messages, 2 ops publish("foo") publish("bar") # b) 2 messages, 1 call, 2 ops publish("foo", "bar")
  - dmytton 11y ago
    Yes then it would be down to their consumers to split them out. However, the graphs Spotify show from Google's monitoring do not support this and they show the actual volume of messages as quoted in the article.
    - patrickmclaren 11y ago
      I agree that the current graphs from Spotify don't support this. They do seem to show a one-to-one mapping between events and messages emitted. Given the comparison in my GP, I think that client-side message collation/aggregation would be a natural next step.

dmytton 11y ago

Batching doesn't make any difference to the pricing: > Batched calls are accounted for as multiple operations. https://cloud.google.com/pubsub/pricing https://cloud.google.com/pubsub/pricing

CaveTech 11y ago
Batching could mean they're aggregating calls prior to handing then off to google as a single request. If you have 64k minimum block size (guessing) you can stuff in many small requests before sending them off.
- dmytton 11y ago
  Right but that only affects networking costs, because the batch is split out into individual publish API calls on Google's side, and that's what you're billed for.
  - deleted 11y ago
    [deleted]
i0exception 11y ago
Yes, but if I'm reading their blog post correctly, their individual messages are much smaller than 64K "Pub/Sub passed the test with flying colours. We published 2M messages without any service degradation and received almost no server errors from the Pub/Sub backend. Enabling batching and compression on the Event Service machines resulted in ~1Gbps of network traffic towards Pub/Sub."
- dmytton 11y ago
  Yes, but that has no impact on the cost. It's a flat rate in 64kb blocks. Batching and compression would only affect the networking fees from Google, not the per API call fees. If you batch up 64 1kb messages into a single batch then Google still bills you for 64 publish API calls.
  - sharpy 11y ago
    They are wrapping small events into fewer larger ones. Hence the word batching. I have 64 1k messages? Ok, I am going to put them inside a single 64k message and reduce my request count by 64x, and profit!
    - foota 11y ago
      "Batched calls are accounted for as multiple operations." - https://cloud.google.com/pubsub/pricing https://cloud.google.com/pubsub/pricing
      - deleted 11y ago
        [deleted]
      - sharpy 11y ago
        Right. If you look at the API, the publish API allows you to push multiple messages in a single API call, and if that is the batching - publishing multiple messages - then yes, you and others are absolutely correct that there is no cost benefit. But rather than publishing { "messages" : [ { message 1 }, { message 2 } ] } You publish { "messages" : [ { container message containing both, still less than 64k } ] } Then you've reduced your operations count by half. Cloud services like this have a per message overhead, for things like auditing and delivery tracking, which is why the pricing model is what it is. If you are ok with having to unpack and process multiple messages at once as I've described, then it's a way to optimize against the pricing model.
        foota 11y ago
falsedan 11y ago
I think what people are proposing is that instead of: 64 1k messages for Events, sent individually or in a batch they suggest: 1 64k message for BatchedEvent
- dmytton 11y ago
  That doesn't match the graphs Spotify post in their blog post. If the batch gets split out into individual operations then Google still prices for each message and each message gets delivered to the consumer. If it's just a single message that'd show up as a single message as far as Google is concerned, which is not what the Spotify test is showing.
patrickmclaren 11y ago
Note by "queuing and batching" Spotify may be aggregating events client-side. Given that messages are priced in 64K increments, it would be most cost efficient to to get each message as close to 64K as possible. i.e. # serialized: 1 message, 1 op publish("['foo', 'bar']") # instead of: # a) 2 messages, 2 ops publish("foo") publish("bar") # b) 2 messages, 1 call, 2 ops publish("foo", "bar")
- dmytton 11y ago
  Yes then it would be down to their consumers to split them out. However, the graphs Spotify show from Google's monitoring do not support this and they show the actual volume of messages as quoted in the article.
  - patrickmclaren 11y ago
    I agree that the current graphs from Spotify don't support this. They do seem to show a one-to-one mapping between events and messages emitted. Given the comparison in my GP, I think that client-side message collation/aggregation would be a natural next step.