RequestQueueV2 performs 4 writes per request vs only 2 with RequestQueueV1

[silva95gustavo]

Hi Apify team,

I've been optimising the cost of my Apify actors and noticed that writes to the Request Queue account for over half of the total cost. After migrating to RequestQueueV2, I saw a noticeable increase in the number of writes from 2 per request in V1 to 4 in V2.

I understand there may be architectural reasons behind this change, but I wanted to raise it in case there's room for improvement. Ideally, it would be great if the number of writes in V2 could be reduced, or alternatively, if the V1 behavior could still be supported as a configurable option (and not deprecated) for those prioritising cost efficiency.

Thanks!

[janbuchar]

Hi Gustavo! You are right, the RequestQueueV2 performs additional operations to ensure safe concurrent processing of the same queue from multiple Actors, which increases the usage cost. If you could explain to us what your usage pattern is, perhaps we can help optimize it.

However, we are planning to make request locking opt-in again because we found that it is not necessary for the majority of use cases. In the meantime, you are free to switch back to RequestQueueV1 and it should work the same as before.

[silva95gustavo]

Thanks for the clarification!

In my case, the actor is accessing a page that uses cursor-based pagination, so I'm always limited by the availability of the next cursor. This means there's no point in parallelizing the actor across multiple instances, since the next page can only be requested after the current one is processed. I also prefer to optimise for cost rather than speed, so reducing the number of writes is more important to me.

It's great to hear that request locking will become optional again. If that change brings the number of writes per request back to 2, then that would be ideal for my use case.

[janbuchar]

Just to be clear, the locking has always been optional, but now it's enabled by default and using RequestQueueV1 explicitly will work just fine, albeit with a deprecation warning.

[silva95gustavo]

Ok thank you