Closed no-yan closed 2 years ago
no-yan
commented
3 years ago 爆速でかえってくるようになりました https://myapp.noyan.workers.dev/api/account/noyan
他のユーザーでも一度アクセスすれば、２回目からは高速です https://myapp.noyan.workers.dev/api/account/anagohirame
https://myapp.noyan.workers.dev/api/contests/latest?contest_page=0
no-yan
commented
3 years ago 実際にデプロイしてみました。 Demo（Heroku自体の起動に30秒程度かかります。） 一度fetchしたことがあれば、キャッシュを削除しても20ms~60msでfetchできてそうです。
@ShopOne このデモではJSONをキャッシュすることでページの表示を高速化しています。これを実際にサービスに採用できる / したいでしょうか？ 勉強がてら作ってみた部分が大きいので（具体的な目標とモチベーションがほしかった）、導入できなくても構わないですー
HttpRequest関数の実装内に閉じているので、それ以外は以前と同じように開発できる
ShopOne
commented
3 years ago 実際サービスのわりには重いので、導入ありかな〜と思います デメリットについても切り替えは用意っぽいので大丈夫だと思います。 お願いしても宜しいでしょうか？
no-yan
commented
3 years ago 了解です！ぜひやりましょう。 とりあえずcloudflare workersのアカウントを誰が作るか考えてます（複数アカウントOKか、workerの譲渡が可能か？（無理そう））
ShopOne
commented
3 years ago アカウントについては僕がメインで紐付いていた方が良さそうなので僕が作ったほうが良い気もします(設定を頑張らないといけなくなりますが) 共用というとこれですかね？ https://support.cloudflare.com/hc/ja/articles/200167946-Cloudflare%E3%82%A2%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%B8%E3%81%AE%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%82%92%E7%AE%A1%E7%90%86%E3%81%99%E3%82%8B
no-yan
commented
3 years ago はい、そこでinviteしてもらえれば大丈夫です。アカウントができたら教えて下さい。 いちどdiscordかなにかで一度に作業してもよいのかもしれません。
ここ数週間何も手につかなかったので、かなり間が空いてしまいました。すみません。
ShopOne
commented
2 years ago すみません、研究もろもろで連絡の確認がすっぽ抜けてしまいました…すみません アカウントは作成しました
no-yan
commented
2 years ago お、了解です。研究第一でいきましょう。いいものを書いてください。
アカウント作成ありがとうございます。
Cloudflareが導入されるとして、Shitforcesのコア部分が高速化する見込みは低い、そう考えるようになりました。 理由として、
たしかにCloudFlare Workersの導入で、よく使うAPIは高速に取得可能で、ページ遷移が高速になります。 ですが、最初のページ表示は遅いままです(index.htmlをHerokuから取得するため)。 また、サーバーを直接叩く必要のある部分も高速化しません。
ユーザープロフィールやLatest ContestsのAPI取得を高速化するだけです。もちろん大きく高速化できますが、アーキテクチャが複雑になることを受け入れるほど必要なものか迷っています。
ShopOne
commented
2 years ago なるほど、確かにです ログを見てみても、コンテスト直前～開始でも、そこまでメインページの使用頻度も高くないので、複雑化するほどでもないかもしれません。 他の可能性としては、herokuからAWS(とカスタムドメイン)はURLが変わるのだけ少しネックかな～という気持ちはあります。 index.htmlを日本に置くですが、これはどれほど効果があるかはやっぱり僕には判断つかないという感じです、すみません。 N+1とかのSQL改善はたぶんあるんですが、現状のデータ数がそんなに無いので、まだあんまり効いてこない気もします。(この辺の感覚はあんまり無いですが) 複雑化を避けるなら、SQL改善が一番ましになるのかな？と思います。
no-yan
commented
2 years ago 
https://bejamas.io/compare/cloudflare-pages-vs-heroku/
各ホスティングサービスが何msでファイルを配信するかの表です
related: #199 APIの取得が遅い要因の一つが、取得先が物理的に遠いことです。エッジキャッシュと呼ばれる技術を導入することで、物理的に近い位置にAPIサーバーのキャッシュをおくことで改善できます。 （自分はサーバーの距離が主要因でサーバーの性能はそこまで問題ではないのではと思っています。herokuはコールドスタートで、どんな小さい処理でもすぐにレスポンスを返さないらしいですが。）
以下のページは、裏でcloudflare workersを使っています。Youtubeと検索してから、一度キャッシュを削除して再度youtubeと検索すると、最初と比べかなり高速に表示されます。別の単語でも同様に高速化されます（無料です）。 https://serverless-api-viewer-c87.pages.dev/
shitforcesでもこれと同様のことをやりたいと考えています。公開して問題ないget系をcloudflare workersに公開すれば、レスポンスが高速化し、サーバーへのリクエストも減るはずです（コスト減）。
Cloudflare Workers フリープランの制限
一日10万件までということで、問題ないはずです。
Workers の機能
1 日あたり 100k 件のリクエスト を含む
リクエストごとに最大 10ms の CPU 時間
最初のリクエスト後の最小遅延 キー バリュー ストレージ機能 2 1 日 10 万回の読み取り操作 1 日 1,000 回の書き込み、削除、リスト操作
懸念
もし
:contestId/problemsをcloudflare workersで公開するとなれば、コンテスト開始後即座にキャッシュを更新する必要があります。ここらへんをどうするか考えています。 スケジュールでキャッシュを更新できる機能があるが、これでまかなえるか検証する感じですかね。 まず影響の少なそうな最初の４つで試してみたいです。/api/ranking/api/account/${accountName}/api/account/${accountName}/history/api/contests/latest↓公開スケジューリングと高頻度のキャッシュ更新が必要
/api/submissions/${contestId}/raid/api/contests/${contestId}/api/contests/${contestId}/problems/api/contests/${contestId}/standings