# Continue-as-new overhead, suitability of using Temporal

**URL:** <https://community.temporal.io/t/continue-as-new-overhead-suitability-of-using-temporal/11245>\
**Category:** Community Support\
**Created:** [March 5, 2024, 11:24am UTC](https://community.temporal.io/t/continue-as-new-overhead-suitability-of-using-temporal/11245 "2024-03-05T11:24:34Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![chris0](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/chris0/32/4334_2.png) [@chris0](https://community.temporal.io/u/chris0)\
**Post date:** [March 5, 2024, 11:24am UTC](https://community.temporal.io/t/continue-as-new-overhead-suitability-of-using-temporal/11245/1 "2024-03-05T11:24:34Z")

</div>

Hi all,

We’re considering using Temporal for a use case in which we’ll have 500k-1M workflows running a polling loop at variable rates ranging from once every few minutes to once every few seconds - so maybe an average of 2 polls per workflow per minute. On each iteration, a workflow would run a single activity which hits a gRPC endpoint and returns a small amount of data (~300 bytes). The relevant “state” of the workflow would be determined entirely by the latest activity response.

Would it be more efficient to have such workflows continue-as-new every iteration (passing the latest activity result as input to the new workflow), or should we let them run for a while before continuing-as-new?

Overall, how well-suited is Temporal to such a usage pattern? We’re debating between Temporal and Orleans. Orleans seems like it _might_ put less load on the underlying nodes/DB, but we’re a small team with zero .NET experience and a good amount of Go experience, so we have a strong preference toward Temporal as long as scaling it won’t be too challenging compared to Orleans.

Thanks!

---

<div class="post-metadata">

**Author:** ![maxim](https://sea2.discourse-cdn.com/flex016/user_avatar/community.temporal.io/maxim/32/8_2.png) [@maxim](https://community.temporal.io/u/maxim)\
**Post date:** [March 5, 2024, 3:53pm UTC](https://community.temporal.io/t/continue-as-new-overhead-suitability-of-using-temporal/11245/2 "2024-03-05T15:53:42Z")

</div>

There is no need to use continue-as-new for simple polling:

> [@What is the best practice for a polling activity?](https://community.temporal.io/t/what-is-the-best-practice-for-a-polling-activity/328/2):
>
> It depends on how frequently you want to poll. For infrequent polls (every minute or slower) use the server side retry. Specify a [RetryPolicy](https://github.com/uber-go/cadence-client/blob/c3cd9f8f9745172572659a28ad1b478c19596def/internal/activity.go#L107) (or [RetryOptions](https://github.com/uber/cadence-java-client/blob/1b2a2ce0de2bc92a609080186009dd793920b46c/src/main/java/com/uber/cadence/activity/ActivityOptions.java#L141) for Java) when invoking the activity. In the RetryPolicy specify an exponential coefficient of 1 and an initial interval of the poll frequency. Then fail the activity in case the polled resource is not ready and the server is going to retry it up to the specified retry policy expiration interval. So what you are doing is absolutely OK. …