Scrapboxの100000ページの壁
ネットワークの方は心配していないけど、performanceのほうが気になる
100000ページ以上あるprojectを使っている人が殆どいないので、実際にどうなっているかは全くわからないけど
観測範囲では
さんのところの社内scrapboxくらい
/notaもそのくらいありそう
そこまでは無いですね 
まだ数万レベルかな
10万ページくらい余裕でさばけないと、企業ユースとしては厳しいんじゃないかな 
ソフトウェアの構成を見てみると、全然大丈夫そう（根拠が薄いけど）
Scrapbox より先に、ブラウザ（JavaScriptエンジン）が壊れてしまわないか心配
大丈夫だと思います
企業だと10万ページも使うようなwiki運用ケースがあるってこと！？
大企業だとあるのかな すごい
1000人の会社で1人が平均1日1ページ作ったとすると1年で36万5千ページ
3日に1ページでも余裕そう
人数密度の問題もありそう
10万ページ規模になると「数十人が1projectをいじってる」「1ページ内に数十人が集まって同時編集する」が起こる率高そう
10万到達する≒それなりに大人数で使っている
もちろん少人数で10万到達もありえる（まだ年数少ないで単に到達してないだけで）
Scrapboxは「数十人が同時にいじる」に耐えられる？
使い方次第かも
この件もたしかさん絡みで以前どっかで議論した覚えが。。。
複数人だと遅くなる、みたいな話題でフォーラムかどこかで見ました
プロジェクトExportのファイルサイズ制限の壁があるとどこかで聞いた気がする
30MBだったかな
/motosoは10000ページ超えてますが（短文記事もかなり多い）11MBぐらいでした
ちょっと気になるのでProjectのページ数とExport時のjsonファイルサイズ
エクスポートは最近改善されたはず
自分のプロジェクト14000pageくらいでしたが、ずっと前と最近とでexportの時間が明らかに早くなってたのはこの改善のおかげかな
JSONが分割されて送信されるようになりましたね
47000くらいのprojectでリンクの入力補完の初期化が遅いのが気になっている
開発コンソールをみてみると、そもそも初期化の開始が非常に遅いみたい？
これはfirefoxのせいかも
api/pages/:projectname/search/titlesを47回叩き終わるまで補完ソースが構築されない
(1回で最大1000件のリンクデータを取得できる)
cacheが生きていれば多少早くなるけど、それでも47回もあると遅いと感じる
1000件ずつ補完ソースを構築するようにすればいい？
補完ソース構築中でも検索できる
今Chrome for Androidで当該projectを開いてみたら、3秒もかからずに初期化し終わった
やっぱFirefoxが悪さしているだけかな？
万は見たことあったけど10万もあるんだな
いつか100kページの個人projectを見てみたい
一体何年かかるんだ…
1日50ページ増えても10万ページまで2,000日（5年半）かかると思うとすごい
やってみたらわかるけど、1日50ページというのはけっこうきつい
スクボメイン（むしろオンリー）の生活に寄せる＆ページが増えやすい書き方にする、の二つともが必要になる印象
僕は前者はたまになるけど、後者をあまりしない（むしろ1ページ中に数千文字以上書くなど逆を行きがち）ので50ページ/dayは基本的に厳しい