Nginx access log

image onload 之后发一个请求..

我觉得这玩意儿应该交给 nginx，或者第三方服务

在 webserver 级 搞插件好些

烂点子： 所有文件都走服务端吐出来 http://domain/a?filename=xxx.jpg

#1 楼 @huacnlee 效率不好，而且会跟其他网站搞混。

#4 楼 @huobazi 中间设置一次跳转，从一个 url 跳转到图片地址。应该可以解决这个问题。

access log 是个很好的资源，不用白不用。

#5 楼 @hanluner 怕搞混应该让 nginx 对于不同的域名生成不同的 log，或者直接上 logstash

#5 楼 @hanluner 哪里效率不好了，哪里容易搞混了？

我们现在群发用户公告邮件，统计打开量，就是塞了个 Gif 在邮件里面，然后统计 Access Log 里面那个文件的数量。

@hanluner 长知识了，可以这样用

nginx 可以用 lua 把请求地址压进 redis 队列里去。 access_log 是个很有用的东西，但是考虑到 logrotate 和 fd 的问题，还是不太适合在用户级的应用上使用。

#9 楼 @huacnlee 邮件打开量其实现在根本统计不出来，对数据解读不好还会给决策带来麻烦..

1. Gmail 现在有了 prefetch，所有图片 gmail 服务器都会自己先抓取一下，然后用户加载的是从 gmail 服务器的图片，和 github 上的图片类似，防止 mix content。这里会让打开量偏高。

2. 大部分邮件客户端会有默认不加载图片设置。这里会让打开量偏低。

所以，这个统计结果和真实是否符合完全取决于你的客户使用的邮件服务商和邮件客户端..的比例。

我现在都不统计打开率了，只统计点击率，这个更可靠一些，又不费力气。

#4 楼 @huobazi 一点也不烂，这是最佳实践。用 nginx log 才是反模式。

#13 楼 @hooopo 不知有没有人写这种插件出来。PS：我不会写，纯粹问问。

#13 楼 @hooopo 可是这样服务端亚历山大啊

#15 楼 @huobazi 这只是一个简单的 proxy 请求，处理图片还是用 sendfile 交给 nginx 处理啊，有兴趣你可以测一下这种请求 Rails 每秒可以处理多少，什么样的流量能让服务器亚历山大。

@msg7086

“access_log 是个很有用的东西，但是考虑到 logrotate 和 fd 的问题，还是不太适合在用户级的应用上使用。” 请教，能否具体阐释一下 logrotate 和 fd（这是什么的缩写？）的问题？

#17 楼 @yijunlin file description 文件描述符 web server 会长期打开一个日志文件。要分段处理的话，得把不停文件移走然后重新打开日志文件句柄才行，很麻烦。

#13 楼 #16 楼 @hooopo hit 到 rails stack 就已经很慢了。

nginx+lua+redis 你们可以试试，我测下来性能很好，200qps 下 cpu 占用动都不动……

然后另一边程序部分每几秒钟，或者用 cron 每分钟，从 redis 抓一批数据下来统计进数据库就好了。

或者如果统计结构很简单的话，直接让 lua 做完统计写入数据库就好了。

顺便 at 你： #14 楼 @cisolarix

#19 楼 @msg7086 其实哪个快哪个慢这个大家都有一定的概念。我的观点是够用就行，在一般应用规模，Proxy 方案一定不会成为瓶颈就是了。

无论 access log 还是 nginx + lua 或者 proxy 方案，都是要和应用规模匹配的，不是说性能最好的方案是最佳的。

十万 PV 的应用有十万 PV 的搞法，千万 PV 的应用有千万 PV 的搞法。每个方案都是效率、性能、维护性、扩展性等各种指标的权衡。

我觉得楼主的应用规模不会太大..

另，nginx + lua 和 access log 方案，如果人家的图片在 CDN 或云存储上怎么搞？

#20 楼 @hooopo cdn/云存储的话，请求不会hit到你web server 上，这种除了用跳转以外没法做。

顺便，跳转的话也还是走 nginx 内置脚本最快，走 php 还是会影响性能……