翻译接口的响应信息 - 缓存命中及翻译字符使用
首先,translate.js - translate.service 整个系统有三级缓存,这三级缓存不太了解的,可以先点此查看一下,大概有个了解。
查看方式:审核元素,然后随便翻译一下,找到 translate.json 的请求,如下图所示
- day_current_size 是今天这个网站已经使用的翻译字符数
- day_max_size 是当前的字符限制上限,你这个域名每天能翻译多少字符
当你配置了domain.json 后,不确定是否生效,可以通过这里来进行验证。
当前翻译接口是否命中文件缓存
- day_current_size 响应头中出现 filecachehit:true 则表示当前翻译请求已命中文件缓存。
当 text 的内容被翻译过一次后,就会将其加入文件缓存(磁盘IO),当同样的 text 内容在进行翻译时,目标语言一致的情况下,它会直接从文件缓存中取出,进行响应。
当命中文件缓存时,服务器的性能使用是非常低的,它将不再进行预处理、分词、内存处理、各种处理等,直接进行返回。所以它的响应时间也是极快,一般几十毫秒(如果是几百毫秒可能是因为使用了代理,因网络中转产生了时间消耗)
怎么判断当前翻译接口是否有命中内存缓存
响应标头中:
- memorycachehitsnumber 当前命中的内存缓存的翻译文本条数。
注意,它并不是完全跟你传入要翻译的 text 要翻译的json数组一样,比如你 text 中传入的json数组是有三项,也就是三条翻译的文本,传入 translate.json 接口后,翻译服务会自动对其进行预处理、分词、等一系列操作,有可能预处理完毕后,经过拆分,它可能变成了5条要翻译的文本(也有可能经过预处理,发现有的是不需要进行翻译的,可能变成了2条要进行翻译的文本)。
然后将预处理之后的5条文本,再进行内存缓存的命中(如果启用了内存缓存),比如这里命中了4条,那这里的数字就是4。 这时你会发现,你text实际才传入了3条,它确命中了4条,是因为这个原因。
一般情况下,你实际传入的text的条数,跟预处理后实际要进行翻译的条数,是差不多的,不会相差太多,也就是并不会产生倍数的差距。
另外,有这个参数,并且值大于0,也代表当前请求已经命中了内存缓存。 - memorycachehitssize 当前命中内存缓存的字符数。
同memorycachehitsnumber这个参数一样,它也是先经过预处理后,在进行的缓存命中,也就是预处理之后的要翻译的字符数,一定是小于等于 text 本身传入的字符数的。
响应头中有这个参数,并且值大于0,也代表当前请求已经命中了内存缓存。