search

misskey-dev / misskey

🌎 A completely free and open interplanetary microblogging platform 🚀
https://misskey-hub.net/
GNU Affero General Public License v3.0
10.05k stars 1.37k forks source link

Node.jsやめる(Rustにする？) #11078

Open syuilo opened 1 year ago

syuilo commented 1 year ago

Summary

Node.jsはパフォーマンス上の問題があるため

Goとかでもいいけど

syuilo commented 1 year ago

みんな移行はコスト高いって言ってるけど自分はそう思ってない(フロントエンドをReactに書き換えるとかの方がコスト高そう)

mattyatea commented 1 year ago

私は開発に参加していないので何も言えない立場なのですが、まずこのような大きな課題よりほかの比較的小さな課題(今あげられているIssueなど)にリソースを割くべきなのではないかと思います job queueなどの問題(#11001 や #11000 )を解決すればnode.jsをやめなくとも多少なりにはパフォーマンス改善に繋がると思います 外野から失礼しました。

acid-chicken commented 1 year ago

みんな移行はコスト高いって言ってるけど自分はそう思ってない(フロントエンドをReactに書き換えるとかの方がコスト高そう)

少なくともここだけはちょっと同意する

tamaina commented 1 year ago

上2つの両方に同意

syuilo commented 1 year ago

私は開発に参加していないので何も言えない立場なのですが、まずこのような大きな課題よりほかの比較的小さな課題(今あげられているIssueなど)にリソースを割くべきなのではないかと思います job queueなどの問題を解決すればnode.jsをやめなくとも多少なりにはパフォーマンス改善に繋がると思います 外野から失礼しました。

今の自分の能力では今のパフォーマンスがほぼ限界で、これ以上パフォーマンスを改善するアイデアが無くなりつつある

saschanaz commented 1 year ago

https://github.com/saschanaz/kissmey

最近全然すすんでないですが、興味ある方いましたらmisskey-devで共同作業してみたいです（各エンドポイントをRustにしてNode+Rust hybrid状態で少しずつRustに移行する）

tamaina commented 1 year ago

Issueを建てたということは、Rustでパフォーマンスが上がる可能性が弱くて、Rust以外の選択肢が欲しいと言うことと解釈している。どんどんやめるべき理由を書いていくよ私は。

Rustで効果が出るのがほぼ確実であると予測しているなら、今すぐゴリゴリ移植なり簡単なActivityPub実装を書くなりするべきじゃないの。

MineCake147E commented 1 year ago

Node.js使っててネガティブな意見もらうことはあってもポジティブな意見もらうことが全くないのよね

インタプリタ型でなおかつ動的型付けである以上永遠につきまといますね。 もっともNode.jsで採用されているV8 JavaScript engine はJIT風になっているそうですが。

みんな移行はコスト高いって言ってるけど自分はそう思ってない(フロントエンドをReactに書き換えるとかの方がコスト高そう)

確かにフロントエンドをBlazorで書き直すよりは楽そうですね。 でもRustにこだわる理由を思いつきません。

KisaragiEffective commented 1 year ago

Rustで効果が出るのがほぼ確実であると予測しているなら、

仮にそうだったとしても、この手の話題では予測を避けるべきです。

saschanaz commented 1 year ago

パフォーマンステストがないのでRust移植でパフォーマンスが上がっても証明ができない問題はあります (#9937)

Mastodonはどうやってテストしてるのか気になります

mirror-kt commented 1 year ago

通りすがり失礼します Rust移植も別になしではないですが、Misskeyの移植を全面的に進める決定をする前に、ActivityPubサーバーとして認識される最小限の機能をRustで実装してみて、速度比較をしてみるといいかもしれません(いわゆるプロトタイプ).

パフォーマンステストがないのでRust移植でパフォーマンスが上がっても証明ができない問題はあります

Mastodonはどうやってテストしてるのか気になります

そのための前提としてこれが必要ですが

tamaina commented 1 year ago

各エンドポイント

APIのエンドポイント…？意味あるの…？

syuilo commented 1 year ago

とりあえずDeno/Bunはお手軽だからそのうち試す

mirror-kt commented 1 year ago

通りすがり失礼します Rust移植も別になしではないですが、Misskeyの移植を全面的に進める決定をする前に、ActivityPubサーバーとして認識される最小限の機能をRustで実装してみて、速度比較をしてみるといいかもしれません(いわゆるプロトタイプ).

これをやることで、移植にかかるコストも見積もることができます. 私としては移植ってコストめちゃめちゃ高いという認識なんですが、(手戻りがあまり大きくならない範囲で)実際にやってみることでコストを測ってみませんか.

tamaina commented 1 year ago

（部分的にRustなどネイティブモジュールにするにしても、複雑な処理系とかバックグラウンド処理、ストリーミング処理を書き換えるのかなと思っていた）

yuriha-chan commented 1 year ago

今の自分の能力では今のパフォーマンスがほぼ限界で、これ以上パフォーマンスを改善するアイデアが無くなりつつある

こういう理由なら焦らないでよき、というお気持ち

地道に調査していけばそのうちパフォーマンスの問題点も解決策もみつけられるはずだし、Rustに移植したからと言ってその問題点がわかったり、解決策が見つかるわけでもないので。

saschanaz commented 1 year ago

APIのエンドポイント…？意味あるの…？

（部分的にRustなどネイティブモジュールにするにしても、複雑な処理系とかバックグラウンド処理、ストリーミング処理を書き換えるのかなと思っていた）

（複雑な処理をRustでして、それを使うエンドポイントごとRustにしたらwasmとかで頭痛くならないので）

KisaragiEffective commented 1 year ago

（複雑な処理をRustでして、それを使うエンドポイントごとRustにしたらwasmとかで頭痛くならないので）

その処理のコードが複雑であるかどうかと、その処理においてCPU (やIO) がボトルネックになっているかどうかというのは別の問題です。

sorairolake commented 1 year ago

LemmyがRustで実装されてるからRustであることが性能に大きな影響を与えているのなら参考になるかも

tamaina commented 1 year ago

wasmとかで頭痛くならない

複雑な処理って普通はNestモジュールや関数になっているのだからAPIから呼び出しても頭が痛くなることはない気がするけど…

あとAPIエンドポイントってスクリプト言語で書いたほうが保守性がいいのでは…？

MineCake147E commented 1 year ago

あとAPIエンドポイントってスクリプト言語で書いたほうが保守性がいいのでは…？

保守性と｢スクリプト言語｣であることに相関があるとは思えません。

tamaina commented 1 year ago

あとAPIエンドポイントってスクリプト言語で書いたほうが保守性がいいのでは…？

これなしで

saschanaz commented 1 year ago

「どうしてNodeではダメなのか」がまだ明確じゃないのは問題かも

fruitriin commented 1 year ago

RustよりNode.jsのほうが開発の敷居が低いように思うので個人的にはNode.jsであることにかなりポジティブだよ〜

tamaina commented 1 year ago

みんな移行はコスト高いって言ってるけど自分はそう思ってない(フロントエンドをReactに書き換えるとかの方がコスト高そう)

少なくともここだけはちょっと同意する

自分たちで書いたコードを愚直に置き換えること自体は苦痛ではなさそうだけど、パッケージ（ライブラリ）の代替を探すのが苦痛そうかつ書き換えが面倒そうなのと、ビルドした後のバイナリがめっちゃ肥大化するんじゃないかというのが不安

rinsuki commented 1 year ago

純Rustの場合、async runtimeなど独自の実装の学習が必要なので、メインはTypescriptを維持したほうがいいと思います。

少し調べてみたのですが、Rustでは非同期処理の実装が乱立しているみたいですね。 純Rustになった後で大揉めする原因になると思うので、私も純Rust案には賛同出来ないです。

rinsuki commented 1 year ago

Deno とか Bun に移行するなら前座としてルーター Hono にしたらリクエスト受ける部分がちょっと早くなったりしないかなと思っています https://github.com/honojs/hono (Misskeyの場合にFastifyとどっちが早いかは知らない)

まあまずスロークエリ含めたDB周り何とかしたほうがいいと思いますが…

rinsuki commented 1 year ago

あと JSON-LD on Rust はなんか面倒そう (予想) なのでその辺の検証をしっかりやったほうがいいかも

rinsuki commented 1 year ago

Deno とか Bun に移行するなら前座としてルーター Hono にしたらリクエスト受ける部分がちょっと早くなったりしないかなと思っています https://github.com/honojs/hono (Misskeyの場合にFastifyとどっちが早いかは知らない)

そういえば思い出したが今は koa でエイヤではなく NestJS に移行したので NestJS 用の hono のアダプターとか作らないといけなくて面倒？

syuilo commented 1 year ago

Nestjsをフルで使ってはいなくて主にDI部分だけ使ってるからそこは大丈夫かも

equal-l2 commented 1 year ago

Rustの話題と聞いて流れてきたRustaceanです。

今までの議論を読んだ感じ、Rustに移行する動機が弱いかなと思います。 最近大企業が他言語からRustに移行する事例はちょいちょいあるんですが、どれもちゃんとプロファイリングをやって「今の言語ではどうしても解決できないパフォーマンス上の問題がある」という結論に至ったうえでやっている印象があります。 例：Discord（https://discord.com/blog/why-discord-is-switching-from-go-to-rust）

上でも言われているようにプロファイリングをしてみて、CPUバウンドなのかIOバウンドなのか、GCのタイミングで遅くなったりするのかなどを洗い出したほうがいいのでしょうね。

JavaScriptは「GC付きのスクリプト言語」という印象からパフォーマンス上目の敵にされがちですが、実のところどの処理系でも「JavaScriptという遅い言語をいかに速く動かすか」という努力がされていてそこまで遅くない、という評判がコンパイル型言語界隈でも聞こえてくるような状況です。

NodeをBunに変えてみるとかなら割と簡単な気もしますが、実装言語を変えるというのはかなり重い判断になると思います。

equal-l2 commented 1 year ago

↑（個人開発では自分もとりあえず言語やフレームワークをえいやで変えてみたりするので、気持ちはわかる……）

equal-l2 commented 1 year ago

Rustaceanとしての個人的感情を言えばRustで書かれたものが世間に広がったら面白いが、それはそれとしてRustは銀の弾丸ではないので「とりあえずRustで書き直そうぜ！（Rewrite It In Rust）」には賛同しかねる、という立場です。

j416dy commented 1 year ago

開発言語の話とはズレるけど、ここまでDBが足引っ張ってないか気にしてないのが気になるかも。 言語変えたいの話をするなら、せめてどのエンドポイントがどのくらい遅いのか、リクエスト時間中Node.jsのどこが遅いのか、くらいは把握したい所・・・。 (ここ以外のissueですでに議論済みだったらごめんなさい。見つけられなかった。)

感覚的にはDBで詰まってない？とは思ってて、実際上で出たSlowQueryは全部平均30秒超えてるし、大半ブラウザには届いてないはずでは？と思う所。 max_exec_timeに至っては16時間くらい回ってるときもあって、どう考えても無駄っぽい。 それならクエリ実行時にstatement_timeoutしただけでマシになるんでは？とか。 下手に居座るノードがあるより、timeoutエラー頻発でいいからさっさと返したほうがいいはずと思っているので。

syuilo commented 1 year ago

それならクエリ実行時にstatement_timeoutしただけでマシになるんでは？とか。

既に設定されている

kurehajime commented 1 year ago

このIssueは『パフォーマンスを改善したい』と『開発体験を高めたい』の２つを解決しようとしてる 前者の『パフォーマンス』に関してはスロークエリが一番てっとり早そう 後者の『開発体験』はちょっと難しくて、仕事ではない個人のやる気ドリブンの開発では、その技術使ってテンションがあがるか・ワクワクするかが一番大事だと思う

j416dy commented 1 year ago

それならクエリ実行時にstatement_timeoutしただけでマシになるんでは？とか。

既に設定されている

確かに確認したら記述は1年前からありました。失礼しました。

https://github.com/misskey-dev/misskey/blob/61e7eb8ff1d7ef222e60b687090cca53a182efc3/packages/backend/src/postgres.ts#L204

ただioのslowQuery(であってるよね？)でそれを超えるクエリがあるなら、 ここが機能せずに流れてるクエリがあるということかも？とかそういう方向をみたいかも。 ただメインで運用しているのは村上さんなので管轄違うとかそういう所がある？外野からだとなんとも・・・。

utopianf commented 1 year ago

企業とかではなくほぼ個人プロジェクトってところもあるので、作者がRustを試してみたいって言ったらそれが尊重されるべきだとも思うんですけどね

MineCake147E commented 1 year ago

企業とかではなくほぼ個人プロジェクト

image

190人+Dependabotははたして｢個人｣なのでしょうか。

j416dy commented 1 year ago

190人+Dependabotははたして｢個人｣なのでしょうか。

個人かどうかじゃなくて、そこは「商業・営利」と、「趣味・同人」とかの違いだと思うので・・・。 極端な話、 syuilo さんは責務を負ってないとも言える。 (今のFanboxで運用されている環境が本当にそうか？というのはあるが、MisskeyHQとの関係性が良くも悪くも曖昧)

acid-chicken commented 1 year ago

メンバーの立場から見る限り、私は少なくとも現体制は個人（同人的）プロジェクトと表現するのが適切だと思うけど

acid-chicken commented 1 year ago

misskey-dev と io さんの関係は現在はしゅいろが io に住んでいることぐらいしか関係がないぐらい、グループとしては別物であって、例え io さんがどれぐらいの規模感で運営されていようと、それに misskey-dev が追従している（できている）わけではない。 それが課題だとしてもどのみちオフトピなので、この話はこれぐらい説明すればもう十分ですか？

equal-l2 commented 1 year ago

最終的にリーダーが「僕はこうしたいからこうします！」というのは全然アリだとは思う。 オープンソースなので、気に入らない人は自分でフォークしてやっていく手もあるので。

こうやってIssueが開かれた以上意見を求めているのかな？と思ってやってきただけの外野なので、方針を強制する気はないということを後出しながら表明しておきます。

equal-l2 commented 1 year ago

ただ、一人のRustaceanとしては、見切り発車した結果「Rustで書き直してみたけど思ったより良くならないな〜」とがっかりされてしまうのではないか、という危惧があって一連のコメントをするに至ったかたちです。