Durable Object は、JavaScript を実行中(リクエストの処理、またはイベントハンドラーの実行)のとき、あるいはアイドルでも 休止(hibernation)の条件 を満たしていないときに、継続時間課金が発生します。休止の条件を満たすアイドルの Durable Object には、ランタイムが休止する直前の短い時間も含め、継続時間課金は発生しません。
オブジェクトがメモリからエビクションされたあと、次に必要になったときは再作成され、コンストラクターが再度呼び出されます。
Durable Object の休止を妨げ、継続時間課金が続く要因はいくつかあります。
詳細は Durable Object のライフサイクル を参照してください。
はい。ただしごくわずかです。空のテーブルでも、列数(テーブル幅)に応じて少なくとも数キロバイトを消費します。空の SQLite データベースは、およそ 12 KB のストレージを消費します。
SQLite バックエンドの Durable Object への書き込みはすべて、Durable Object 内の内部テーブルにわずかな量のメタデータを保存します。このメタデータは課金対象のストレージに含まれます。
メタデータは、deleteAll() を呼び出すまで Durable Object に残ります。
Durable Objects は、多数の Durable Object に対して水平スケールできます。個々の Object は本質的にシングルスレッドです。
- 個々の Object には、1 秒あたり 1,000 リクエストのソフト上限があります。名前空間あたりの個々のオブジェクト数に上限はありません。
- 小さな値に対する単純な ストレージ
get()をそのまま返す場合、大きな JSON 値をシリアライズ / デシリアライズする Durable Object よりも、高いリクエストスループットを出せることがあります。 - 同様に、複数の
list()操作を行う Durable Object は、リクエストスループットの面でより制約を受けやすくなります。
リクエストが多すぎる Durable Object は、いったんキューに入れたあと、呼び出し元に overloaded エラーを返します。
Durable Objects は、システム内の個々のオブジェクト数を制限する必要がないように設計されており、水平にスケールできます。
- 1 つの Durable Object 名前空間 内で、必要な数だけ個別の Durable Object を作成して実行できます。
- Workers Paid プランで SQLite バックエンドの Durable Objects を使う場合、アカウントあたりのストレージ上限はありません。
- SQLite バックエンドの各 Durable Object には、Workers Paid プランで 10 GB のストレージ上限があります。
- 詳細は Durable Object の上限 を参照してください。
Durable Objects は Worker スクリプトであり、他の Workers と同じ 呼び出しあたりの CPU 制限 が適用されます。CPU 時間はアクティブな処理時間です。ネットワークリクエスト、ストレージ呼び出し、その他の一般的な I/O の待ち時間は、CPU 時間や Durable Objects のコンピュート消費には含まれません。
デフォルトでは、Durable Objects の呼び出し(HTTP リクエスト、WebSocket メッセージ、または Alarm)あたりの最大 CPU 時間は 30 秒です。Wrangler 設定の limits.cpu_ms を指定すると、その Durable Object 定義に紐づくすべての Durable Objects で引き上げられます。
{
// ...rest of your configuration...
"limits": {
"cpu_ms": 300000, // 300,000 milliseconds = 5 minutes
},
// ...rest of your configuration...
}[limits]
cpu_ms = 300_000SQLite バックエンドの Durable Object が ストレージ上限(Workers Paid では 10 GB、Free プランでは 1 GB)に達すると、書き込み操作(INSERT、UPDATE、または put() と sql.exec() ストレージ API の呼び出し)は次のエラーで失敗します。
database or disk is full: SQLITE_FULL読み取り操作(SELECT クエリ、get()、list() の呼び出し)は引き続き動作し、空き容量を確保するための DELETE 操作も成功します。
このエラーを Durable Object 内で扱うには、ストレージ API が投げる例外を捕捉します。
try {
this.ctx.storage.sql.exec(
"INSERT INTO my_table (key, value) VALUES (?, ?)",
key,
value,
);
} catch (e) {
if (e.message.includes("SQLITE_FULL")) {
// Storage limit reached — reads and deletes still work
// Consider deleting old data or returning a meaningful error to the caller
}
throw e;
}Durable Object のリクエストログには、インスタンス ID が $workers.durableObjectId に含まれます。このフィールドで絞り込むと、デバッグ対象のインスタンスを特定できます。