@toneji 正解!
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
This account is not set to public on notestock.
たくさんVPSを潰したので、代わりにさくらのVPSをひとつスケールアップ。Dockerで動かしていたサービスが見違えるように速くなった。
ふむ、これでだいぶバランスとれたんじゃない?
まだ新しいXsとか入手してないから自分で確認できないけど、カラー表示の仕組みに変化があるのは確かよね。あとでちゃんと調べよう。
http://news.livedoor.com/article/detail/15348472/ #dtp
This account is not set to public on notestock.
This account is not set to public on notestock.
しかし、MastoPeekよ。リレーのインスタンス情報をモニターしようとするのは無益だぞ。API生えてないし。https://mastopeek.app-dist.eu
This account is not set to public on notestock.
@TaiseiMiyahara @loxodonta 目が一緒なら一緒でいいって感じかな。
……いや、それだと、キツネも犬もネコ目だから、みんなネコになってしまう……。
変わり種リレーアイデア出し、半分ふざけてやってるけど、こういうの希にスマッシュヒットでるので、バカにできない。
#リレーの話
■ 翻訳リレー
日本鯖には日本語で、海外鯖にはその言語で、対訳を追加してリレーしてくれる。
GoogleのAPIなどを使って作れないこともないが、無限にメチャクチャ金がかかる。どうするの。
#リレーの話
16GBあってもmacOSの上にVM載せ出すと足りないし、やっぱり64GBぐらいほしい
サービス整理・統合のため、relay.dtp-mstdn.jp および relay2.dtp-mstdn.jp を閉じることになりました。現在、配信を停止しております。お手数ですが、参加いただいていた方は、管理画面にてリレーへの接続を削除していただけるようお願いします。長らくご利用いただきありがとうございました。
なお、雪餅リレー、浜さんリレー、ちほーリレー(それぞれ勝手に名付けた)などに既に参加されているインスタンスがほとんどでしたので、影響は軽微かと思います。
ハッシュタグリレーについては、現在、ハッシュタグ以外の条件で絞り込みを行う設定ページを作成中です。こちらも当面は運営継続しますが、いずれかの時点でドメインを変更して、新バージョンへの移行を行います。
リレーは、詰まるとやっかいですが、無くても致命的ではないサービス(オプション機能)であり、発展途上のシステムですので、積極的に刷新していくつもりです。
補足。安いのは、クラウドからクラウドへ引っ越すのに、最小限の費用で済む、という意味。
引っ越しのために両方立ち上げている間の時間分の支払で済むので、一日かけてやったとしても、せいぜい200円〜300円ってところ。半日で済めばその半分。
マストどす、復帰できるかなー。
現状、v2.4.0になってるね。ユーザーは各自、クライアントで接続して使えてるのかな。
死んでるのはWebUIなので、たとえば女将のアイコンはnginxが返してくるし、
https://mastodos.com/system/accounts/avatars/000/000/001/original/f8d71756790a0c0d.png
トゥートのURLも、text/htmlを要求するとエラーになるけど、application/activity+jsonを要求すると普通に帰ってくる。こっちはpumaが応答してるハズ。
https://mastodos.com/users/7_nana/updates/4
/ にアクセスするとLocation: https://mastodos.com/about で返してくる。
streaming止めてもWebUIは動くので、nodeは別の話かな。
誰かがssh接続して直接サーバの面倒を見るのが確実だけど、言うは易く行うは難し。技術的にはどうということはないけど、責任の取り方が難しい。
もう一個さくらのクラウドでサーバ借りて、そっちでUbuntuのMastodon環境構築して引っ越しちゃうってプランが、意外と現実的かもしれぬ。クラウドは時間単位の課金だし、コストも低廉。
リレーの負荷、実態はどうなのかな。
100の接続インスタンスがあると、1が受信で、99が配信。
受信は来たものをチェックする程度でなんでもないけど、配信はインスタンスの応答が鈍いと足をひっぱられるかな。とにかく応答が遅いヤツが厳しい。即座にエラーが返ってくるヤツは大丈夫。リトライしないで捨てるので。
リトライはしないけど、次のアクティビティが来た時またその遅いヤツに送ろうとするので、ここを対策しないと結局ツライ。
このへんは皆考えていると思うので、私などが考えるより、その知見に頼りたいトコロ。
違いとしては、リレーは常にオプショナルと見做されていて、届かなければ届かなくても構わない、というスタンスであること。マジメに全部送ろうとしないで、上手に捨てちゃえば良い。
捨て方で考慮するとしたら、削除のアクティビティをどうするか。新規が届かないのは何も起きないのでいいけど、削除は完遂されないと相手方に残っちゃって嬉しくない。まだ送ってないヤツの取り消しなら捨ててもいいけど、それを判定しないのがリレーという気がする。