このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
もう配信 1 年以上前から欲しかったタイプの Apple Watch バンドが、この考え方してるんだよ日曜日じゃねぇかよ QT
こむぎこ、一旦公開範囲を「ローカル公開」に変更しました
フォローしてくれてる人には今までどおり届くはず
縦型配信流行りだした頃からマルコフ連鎖の bot がマルコフ連鎖 bot のこと言っててね…🥺
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
こういう状況のときに、大きいサーバ……というか、リモートフォローの多い、生きたユーザーをたくさん抱えたサーバは、処理量が多くなるので、そこがネックになりやすい。
webもかなり重くなるので、リモート投稿を受け付けるプロセスと、直接の利用者がAPI利用するプロセスをわけておくと、APIの応答性を守れたりするよ。
あとmstdn.jpでよく発生していたと思うけど、負荷が高まってくると画像のアップロードがコケるようになるんだけど、これもバックグラウンド処理があるからで、分離しておくと安定した動作を確保できる。fedibird.comでやってるよ。
まあそんな感じで、多少ソフトウェアの機能を調整したり、どうプロセスを分割して、どこにどのぐらいのリソースを割くようにするか調整するなど、運用って工夫次第なんだ。
あけおめ負荷試験もそうだし、地震も、他鯖の詰まりもそうだけど、そういうのを貴重なデータにして、仮説を立てておいて結果を検証し、改良を重ねて知見を積み上げていくんだよ。
で、ボトルネックは改善すると別の場所に移動するので、あとはバランスとりかな。
misskey.ioはピーキーなサーバなので、そのへん難しいだろうね。構成変更したときにバランスが崩れやすい。ま、任せるしかないけど! がんばえ!
misskey.io側の方針も出てないし、一応、もう一日だけ臨時増設サーバ維持しておきますかねー。 #fedibird #fedibird_info
このアカウントは、notestockで公開設定になっていません。
画面の前のオタクのみんな!モニターはアームなり耐震スタンドなりでがっつり固定しような!
全自動ドッカンアップデートを採用したMisskeyサーバー みーくりあ!(https://a1.miclear.casa/)を立てました。
自動でアップデートして、壊れたら雰囲気で切り戻しをします。
今はまだ更地なので住民を募集しています。
MFM-Tools/MFMをHTMLにするやつ(仮) https://mi.okin-jp.net/@okin_p/pages/1676981799459 を更新しました。
正方形に近いシンプルなMFMは多分それっぽくPNG画像に出来ます
背景透過でダウンロードも出来るので、絵文字作成に使えるかも?
// 但しなので連打は厳禁
以前描いたもの
ありがとう、SobaCha・MateCha。また逢う日まで。 | もんもんぐたーど(おきん) #pixiv https://www.pixiv.net/artworks/105352617
ioの方はこれ→https://misskey.io/notes/9b6hp2fmtr
配送能力が投稿増加に追いつかないとこうなるのはMisskey.ioだけの問題という風に考えるのは良くなくて、Misskeyというソフトウェアがリアルタイム性のためにキューを入れ替えるみたいな実装を考えるときが来たのかもしれない。
リアクションと投稿、どちらを優先するか、どれくらい遅延したら優先度を下げるかなど。交通機関の遅延回復みたいな話。