神楽坂しえる @Clworld@md.ggtea.org

ぐわー(bugfixの結果めっちゃコンフリクトすることが予定された)

Timelineの保存Tootを1600件にした結果、今現在のTimeline末尾が18時あたりのtootでした。動作速度的にはまあまあのレスポンスな気がします。

LTL/FTLには件数制限無かったりするのでFeedの件数増やすよりFeedの末尾まで行ったらSQL処理にFallbackすべきなんだろうか…😐？

Feedの操作はO(log(N))なので増やしてもそんなに酷いことにはならないはず(巨大インスタンスを除く)

https://github.com/clworld/mastodon/pull/14 Feedの件数をカスタマイズ可能にした(md.ggtea.org) とりあえず1600件に設定。

FeedのTRIM操作がO(TRIM量)なので一気に消すのは有効ではないげなのは直感に反するけどまあ多分誤差なのだろう…

Webだとそんなに遡るとReactが音を上げるっぽいけとSubwayTooterで寝てた間のギャップを読む時にbacklog量が欲しい

うちのインスタンスだけ1600くらいまで保存件数増やそうかな…

ついったさんのhome遡れる件数何件くらいか忘れた

homeが400tootしか遡れないのは不足しているかどうか…😐 ついったのクライアントだとクライアント側にキャッシュしてたりするけど。

Web Push の PR が REVIEW ME になってるのう

にゃー

janogdonがちゃんとIPv6対応してたので安心した

大規模Mastodonインスタンスどんどん大きくなっていくとDBの帯域がってなってRailsのテーブルのカラム全部取ってくる仕様がつらくなってくるんじゃないか感が多少ある…。前にRedisの帯域がやばくなってたみたいですけど。

https://md.ggtea.org/skrnotifier.html このSubwayTooter用汎用通知リスナですけどとりあえず見た感じ1日動かし続けましたけどRubyのメモリ使用量は増えてないので心配しなくていい感じですね。50MBくらいです。

1.4.0.5 + ggtea

rcながすぎってDebianユーザ的にはフリーズからリリースまでは半年とかのめっちゃ時間かかるものなので(😐？)

(whoisに関してはスルーしてほしい😐)

gandi.netは個人ユーザでも再販事業者向けっぽいドメイン操作APIが使える良くわからないレジストラです。(DNSSECのキー更新に使う予定だったけどまだ自動化してない)