Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature]: 增加site uv 计数 #965

Closed
appotry opened this issue Apr 25, 2022 · 14 comments
Closed

[Feature]: 增加site uv 计数 #965

appotry opened this issue Apr 25, 2022 · 14 comments
Labels
discussion Question or dicussion enhancement New feature or request

Comments

@appotry
Copy link

appotry commented Apr 25, 2022

功能概述 | Describe the feature

目前用的 不算子计数稳定性太差了。 时常报错,获取不到数据。

希望waline 可以增加访问人数计数。

看着不算子是用的cookies来实现区分pv计数和uv计数的。

waline如果要实现这个uv计数,也可以使用cookies,或者其它技术

@appotry appotry added discussion Question or dicussion enhancement New feature or request labels Apr 25, 2022
@appotry appotry changed the title [Feature]: 增加sete uv 计数 [Feature]: 增加site uv 计数 Apr 26, 2022
@Mister-Hope
Copy link
Member

Mister-Hope commented Apr 30, 2022

To identify uv, we must generate a fingerprint for each device, BUT browsers is not providing such functions, so one common workaround is to use fingerprint.js, to genreate a md5 based on all infomations available at navigator, which is unfortunately, 13.3kb minified in size.

So I am not looking forward to such a function. But if you have good solutions ( at least < 5kb), PR welcomed.

@appotry
Copy link
Author

appotry commented May 1, 2022

@Mister-Hope
Copy link
Member

Mister-Hope commented May 1, 2022

你给别人展示东西的时候,最好弄清楚别人的意图.... 真就我说苹果你拿个香蕉呗.....

首先这篇文章是在开头提到通过 IP 进行 UV 实现的,但是我个人反对这一点,UV标识应该基于设备,一个人 IP 变化的可能太多了,比如他连接不同基站与 Wifi。

另外你发的那段是如何在引入 leancloud package的情况利用 api 存储 UV 和 PV,请你先搞清楚 Waline 的架构。

总之核心一点,你浪费了我8分钟翻那篇文章和2分钟回复你。

@tufu9441
Copy link

tufu9441 commented May 1, 2022

@Mister-Hope 不明白为什么网站的访问统计功能需要用一个评论系统来支持,是不是要求太多了

@Mister-Hope
Copy link
Member

Mister-Hope commented May 1, 2022

所以这也是我表达的核心观点,如果作为一个附加功能,它应该足够轻量。所以如果说我们需要增加15kb左右来支持它的话,我选择拒绝。

@appotry
Copy link
Author

appotry commented May 1, 2022

世界上99%的事情都没有完美的解决方案,能满足大多数情况就够了。

干嘛非得要用fingerprint这种,随机生成一个字符串就能满足99.9%的场景了,类似uuid,可能重复?那种中彩票的概率即使出现了又怎么样?100万次中有没可能出现一次?即使是fingerprint能保证100%不重复?

存入cookies或者localStorage,一些老浏览器,不兼容就不兼容了,干嘛要兼容所有?
90%场景可用,就足以推出了

@tufu9441 hexo vuepress Jekyll 静态博客不全是需要第三方实现pv uv么? 评论系统是这类静态系统里唯一一处可能接触数据库的地方,不在这里实现pv,uv统计,在什么地方统计?

静态博客唯一可能实现pv uv统计的地方只能是采用了数据库的评论系统了!

目前绝大多数静态网站都是使用的不蒜子,但这个响应时间长,经常出错。不蒜子实现的也不够完美,实现一个轻量级满足大多数场景,类似不蒜子的统计就非常有吸引力,单独数据库单独api比不蒜子共用数据库、共用api绝对稳定性高几个数量级

@Mister-Hope 发的那篇文章写的挺好的,作者起码花费了2个小时以上精心编写了这篇文章,原作者编写这篇文章之前起码花费了几周,几个月才积累到足够写这篇文章的知识和技能。开阔了我们的视野,如果你没设想过那种实现方式,看到目录标题就可以关闭了,不会超过30秒,花费8分钟,说明是精心查阅的,应该是没想过的方式,学到的新知识,怎么能说浪费时间?
另外前端页面是没有avMin,和vilane构架是不一样,但是转发相关数据到waline服务器,再采用那篇博客里面提到的参考代码实现,不是很有参考价值么?

@appotry
Copy link
Author

appotry commented May 1, 2022

即使是那篇文章第一段利用nginx access_log实现uv,也不是没有可操作性,结合session识别不同ip,设备,也是可行的,如果是自己搭建nginx服务器,配置文件中加入如下字段

log_format foo '$remote_addr "$request" '
               '$cookie_bar set_cookie=$sent_http_set_cookie';

再nginx配合lua脚本实时替换网页中某些字段,就可以实现uv了

文章有漏洞怎么了,提出的某个名字有参考性,其它99%的文字都是错的也就足以有价值。做web开发非常幸福了,到处都是参考代码,开发内核时,绝大多数工作找不到任何参考资料,知道某个名字就要有实现这个功能的能力是必须的

@Mister-Hope
Copy link
Member

Mister-Hope commented May 2, 2022

花费8分钟,说明是精心查阅的,应该是没想过的方式,学到的新知识,怎么能说浪费时间?

因为我尊重你,所以我把文章从头到尾看了一遍,要是你非得倒打一耙,在这阴阳“没用你还看了8分钟?”,那我们双方的确没有交流的必要了。

即使是那篇文章第一段利用nginx access_log实现uv,也不是没有可操作性,结合session识别不同ip,设备,也是可行的,如果是自己搭建nginx服务器,配置文件中加入如下字段

Waline是一个支持多种方式部署的服务端,上哪去配置nginx?如果你觉得自己看到的这个设计很好,你可以自己去实现,而不是把这个不可能在waline实现的东西拿给waline开发者。

另外你引用的段落只是一个通过leancloud/storage写入uv的一个简单snnipet,这跟Waline实现这个功能,关系在哪?我们已经支持了多种数据库并建立了对应的适配层,所以这个snnipet在我看来,任何一行都不具有任何形式的参考意义。

我保留我的个人意见而且不会再继续回复。你可以看一下另一位维护者感不感兴趣。总之我的最终答复是我个人没有好的实现但pr welcome,pr基本条件是具体实现准确且 <3kb min without gzip。

@lizheming
Copy link
Collaborator

@Mister-Hope 我觉得 @appotry 只是在正常交流,不要带有感情色彩回复吧。如果不想回复可以忽略。

@Mister-Hope
Copy link
Member

Mister-Hope commented May 2, 2022

干嘛非得要用fingerprint这种,随机生成一个字符串就能满足99.9%的场景了,类似uuid,可能重复?那种中彩票的概率即使出现了又怎么样?100万次中有没可能出现一次?即使是fingerprint能保证100%不重复?

我们需要一种可靠的根据设备来生成唯一标识符的方式,首先不同浏览器不共享localStorage,另外localStorage在手机端保持的时间极为有限。一大批国产管家清个垃圾就把localStorage清没了,换句话说,如果只是在本地随机生成一个字符串并存储的UV区分方式的话,如一个用户按照5天访问一次的频率,在半年的范围计作十几个uv是非常有可能的,至少我认为这种uv准确度,还不如不做。

@appotry
Copy link
Author

appotry commented May 2, 2022

@Mister-Hope nginx统计方法一开始就是你提有问题的,而我一开始就直指第三种方法

localStorage 或者cookies清理了就清理了,有什么关系? 其它的统计工具不是一样存在同样的问题么,有哪个统计工具100%完美解决了UV统计?

不准备就不准确,有100%准确的方法么? 吃饭还可能噎死,难道不吃饭?浮点数存储被内存截取,损失精度,我们不是一样每天用电脑,有什么影响?不准确,而被大众天天用的多了去了

考虑普通情况就行了,什么多浏览器,多设备,缓存清理,多人共用设备等等,都不应该是前端该解决的问题。

即使是pv统计,同一个浏览器,短时间内刷新一下,大家的普遍做法都是+1,严格来说也是不对的,大家不都是这么用么

这是看问题角度不同,你在挑毛病,我在看可用部分,不可用的找解决方法,解决不了或成本太高就放弃

@appotry
Copy link
Author

appotry commented May 2, 2022

直接随机字符串区分uv,独立api和独立数据库,就比不蒜子准确性,可用性要高几个数量级。

不蒜子被应用的非常广,它经常502出错,响应时间极长,严重拖慢访问速度,但有谁说不蒜子坏话么?相反,都很感谢不蒜子

@lizheming
Copy link
Collaborator

@appotry UV 这个事情主要是需要做用户的每条记录,这个对于评论系统来说数据层面有点太重了。

你提供的所谓的 Hooks 思路其实只是 LeanCloud 支持云函数的一种形式,本质还是在云函数中对用户的访问做了记录。我们本身已经是云函数了,所以 Hooks 不 Hooks 也无所谓了,而且 Waline 需要兼容多平台,不太方便用某个平台特有的功能。

目前这个功能暂时不是 Waline 的高优需求,后续如果有什么新的实现想法我们会支持上的,当然如果你能帮忙做一下也欢迎 PR。

@Mister-Hope
Copy link
Member

Mister-Hope commented May 2, 2022

我做个总结吧。

似乎从你的角度来讲,你需要uv/pv,但是对不算子的服务不满意,而你又想要或者已经在使用waline,所以你希望有数据库和后端的waline提供一个uv支持,这对于你个人是一个合理的想法。你可能对它的要求就是比不算子强就行。

但是从我们的角度,我们是一个不需要uv的评论系统。大多数博客只需要展示pv,uv主要还是博主自用,所以这是在我们眼中的一个非必要功能。而且我们对待附加功能的态度是做出一个准确的功能来,你眼中的比不算子强的简单实现在我们眼中就是一个残缺的功能,我们不想要这样添加这也无可厚非。而目前现有的常规方案里,添加一个完善的uv统计需要15kb min的空间,这对我们来说是不可接受的。简单点就是我们两和开发者一致认为,waline不需要添加一个体积小但不准确的uv统计功能

总之,即使你有你自己的观点,但既然我们从waline项目的观点是合理的,试图将你的需求转换成论据强加于项目上也并没有什么实际意义。

我们只能说,我们欢迎任何小于5kb的pr方案。如果你有兴趣,你可以自行试图缩小fingerprint,看一下能否用更小的体积,去实现一个设备唯一的特征id生成。

@walinejs walinejs locked and limited conversation to collaborators May 2, 2022
@lizheming lizheming converted this issue into discussion #983 May 2, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
discussion Question or dicussion enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants