Show newer

继续折腾,想把全文搜索给再开一次,不过上次开了把机子卡死的后果历历在目…… :EveOneCat22:

但似乎可以考虑跨机子部署 es ?但这样为了安全要考虑 vpn 方案或者 cloudflare 什么隧道吧……

不管了,先眯会儿,希望醒来时有好心人能直接发一份完整的方案(

南狐 boosted

"1888年,他在那里完成了第一部重要著作—《时间与自由意志》。经过八年风平浪静的日子,他的第二本也是最为艰涩的一本书——《物质与记忆》问世。1898年,柏格森成为巴黎高等师范学院的教授,1900年,他转入法兰西学院,直到1941年去世。1907年,柏格森凭借自己的杰作《创造性进化》赢得国际声誉,他几乎一夜成名,成了哲学界最炙手可热的人物。1914年,柏格森的著作被列入《天主教教会禁书目录》,此时,柏格森才算真正成功了。"

-- "哲学的故事", page 408

生草,但也确实。

不满 1T 也要按 1T 计费……该思考怎么霍霍了……

Show thread

真好啊,fedilab 的列表甚至还自带了差集显示,主页不会显示列表中的帐号内容……

(思考了一下)
真有吗?打开浏览器看主页和列表 api 返回的内容,原来是做差集列表的时候把后端都给改了,所以客户端也受到影响了…… :blobfoxlurkowo:

Show thread
南狐 boosted

再一次迁移媒体文件……
怎么感觉最近数据都没好好安静过……

Show thread
南狐 boosted

首先为昨天错怪了 PeerTube 深感抱歉,它的构建是古怪了点导致我未经查证就认为是它导致的错误,但实际上转码是没有问题的,一个视频巨大无比也没有错,以下是具体的分析: 

!!以下内容包含大量的主观猜测,仅供参考!!
首先,一个视频巨大无比,是如何做到在网页上被播放的? PeerTube 的在线视频使用的点播技术为 HLS ,即
HTTP Live Streaming,它的原理是将一个大的视频切成一小份一小份的 HTTP 请求,将这些分片连在一起就可以实现在线播放和快速前后跳动。 HLS 的视频分片信息使用一个 m3u8 文件提供,一个典型的 M3U8 文件中描述了视频的每一个小切片所使用的文件,和它的具体的切片长度,即持续多少长度@从第几字节起(图1),播放器播放时,会根据时间定位到 m3u8 文件中描述的文件和字节,并使用 Content-Range 请求头来指定所需文件的起始和结束位置(图2)。存储有文件的网页服务器会根据这个请求头返回指定部分的文件,来实现一个小切片的正常播放。
对于我们的 NyaShow 所在的对象存储服务商 Wasabi 来说是如此,对 CloudFlare 来说也是如此——有个例外,就是缓存。 CloudFlare 作为一大 CDN 提供商,其除了使用经由其数据中心专线的反向代理来加速流量外,有很大一部分的功能,就是对数据的缓存管理,来加速一些大文件的内容呈递。一般来说这是没有问题的,对于需要流式传输的大型文件,例如视频,或是一些软件的安装包等静态资源来说,是没有问题的,但遇上视频,就出现了局限。
对于已经被缓存的视频文件来说,向 CloudFlare 的服务器请求资源是很正常的事,它能正常相应所需的数据头,并返回正确的分片,这就是为什么之前的几个视频都能正常播放,因为它们已经被缓存到了 CloudFlare 的服务器上。
但是对于新上传的,还没有谁点过的视频来说,事情就变得有些复杂了:对于免费计划的用户来说,他们的缓存并没有做后台处理,也就是说用户请求的时候,他们才会去源站拉取数据。这本无可厚非,毕竟这样的策略确实能更有效地在保证用户体验的同时实现资源的最优配置。但对于视频点播文件的回源请求来说, CloudFlare 为了保证缓存文件的完整性(缓存最忌讳的就是文件破碎,存了错误的文件还不如不存),它会在转发用户请求回源的同时,删掉其中的
Content-Range 切片请求头(图3)。这就导致了用户在播放视频时,服务器无法返回正常的视频切片,因而导致开始了一个冗长的加载流程,从用户侧的表现来看就是视频无法加载,有一个非常长的请求,下载时是完整的巨大文件——导致了我昨天的错误思考。
但这样无法解释的是,为什么先前的视频和新上传的 360p 的视频可以被正常播放,更高分辨率的就不行?因为已经清理了所有的缓存数据,不再能找寻到当时的请求详情,所以该部分只能进行大胆而过分的猜测。 PeerTube 有视频冗余功能,其他实例可以通过拉取该实例的视频,来实现资源的共享、和链路压力的分担。事实上,在已经上传的的视频文件中,就有一部分会从
@[email protected] 的服务器上进行冗余的请求加载(图4)。360p 的视频文件非常小,而其他分辨率的视频文件大小与视频的分辨率呈正相关增加;考虑到启动实例时经常执行反反复复的启停操作,极有可能是在这一步的过程中中断了与外站的连接,进而导致只有 360p 的视频被成功地缓存了——不只是外站缓存,还包括外站缓存视频文件时经由 CloudFlare 代理的缓存,从而在 CloudFlare 的服务器上也以完整的形式呈现;因而 360p 的视频和之前上传的、已经尝试完整的视频可以被正常地播放,而其他分辨率的视频,则因为并没有被缓存等的种种原因,无法被切片加载,从而失去了在线播放的可能性。
因而目前的处理方案,是绕过 CloudFlare 的代理机制,使用了直接连接到对象存储服务器的请求,来实现视频资源的加载。这终究只是一个权宜之计——不是所有人都享有可以流畅播放的优质网络,但既然已经找到了问题的所在,我们也会进一步研究相关的对策,争取能为每一位用户带来更为优质的使用体验。
非常感谢
@[email protected] 在实例搭建过程中提供的思考和帮助,再次为我昨天的失态感到诚挚的歉意!

views.southfox.me/videos/watch
果然是分辨率的问题……手机录制出来的是 1000x2000 的奇怪分辨率,然后 peertube 直接整不会了然后就压成了 300P…… :EveOneCat05:
难道以后我每次传个录像都要自己在电脑上手动压一下分辨率吗?

今天的跨站轴好冷清哦,怎么两三分种才一条消息?
中继——正常
服务器负载——正常
网络——正常
排查了十几分钟,发现是半夜为了测试图片加载速度把跨站轴只看媒体选项开了…… :blobfoxuwu: (一个经典呆瓜行为

也把 bookwyrm 实例里的图片搬到对象存储上了……

(如果存储用 ipfs 做后端的话,在想重复的文件能不能只算成一个文件啊? I mean,这对那种又大又杂的使用者来说还是有点诱惑力的吧……)

Show thread
南狐 boosted

原来是字体问题……还得我自己手动 wget 才行……

Show thread

为啥 bookwyrm 的 preview 卡片不能用啊……为啥啊? :tiredcat:
重建镜像啥的都搞过了啊……

南狐 boosted


更新了下现代主题,手机端 PWA 页面的元素 z 轴偏移问题应该得到解决了。

南狐 boosted

看服务器上传速度蹭蹭涨但是下载半天不动,怎么你一个存储服务活像 bt 里的吸血客户端……是集群炸了一大半然后 ipfs 寻址卡住了吗?(虽然现在大概好了)

Show thread
南狐 boosted
南狐 boosted
Show older