深入探讨Varnish缓存命中率

   也许你还在为刚才动态内容获得7336.76 reqs/s的吞吐率感到振奋,等等,理想和现实是有差距的,你要忍受现实的残酷,别忘了,我们压力测试中的动态内容都处于全缓存情况下,也就是每次请求都命中缓存,这在现实中往往是不可能的。

  首先,缓存区空间大小是有限的,而我们的站点可能有大量的内容需要被缓存,而不像前边压力测试时只有一个内容。一旦缓存区被装满,那么缓存管理器便会淘汰一些它认为不再需要的缓存内容,比如通过LRU(最近最少使用算法)将使用频率较低的缓存内容淘汰出去,但是,这里判断“不常使用”的标准是不严格的,也许被淘汰的内容就是你将要访问的下一个内容,这便影响了它的命中率。

  其次,缓存的过期时间也影响到它的命中率,假如有效期很短,为10秒,那么最少10秒便会有一次无法命中。

  还有,有些内容可能根本没有被代理服务器缓存,比如这些内容包含了set-cookie等不可缓存的HTTP头信息,导致反向代理不会缓存它们,并且在浏览器请求它们的时候也不会去缓存区查找。这是影响命中率的一个重要因素,但往往被我们所忽略。

  幸运的是,这些问题我们都可以轻松的解决,前提是,我们需要了解反向代理缓存的实时工作状态,比如Varnish便提供了一个命令行的状态监控程序varnishstat,我们打开它,便看到了当前时刻的状态,如下:

  client_conn 9908723 94.05 Client connections accepted

  client_drop 0 0.00 Connection dropped, no sess/wrk

  client_req 16433490 155.99 Client requests received

  cache_hit 8751732 83.07 Cache hits

  cache_hitpass 42592 0.40 Cache hits for pass

  cache_miss 7573389 71.89 Cache misses

  backend_conn 3889845 36.92 Backend conn. success

  backend_unhealthy 220 0.00 Backend conn. not attempted

  backend_busy 0 0.00 Backend conn. too many

  backend_fail 4536 0.04 Backend conn. failures

  backend_reuse 3780212 35.88 Backend conn. reuses

  backend_toolate 3866687 36.70 Backend conn. was closed

  backend_recycle 7646677 72.58 Backend conn. recycles

  backend_unused 0 0.00 Backend conn. unused

  fetch_head 57 0.00 Fetch head

  fetch_length 155097 1.47 Fetch with Length

  fetch_chunked 7508522 71.27 Fetch chunked

  fetch_eof 0 0.00 Fetch EOF

  fetch_bad 0 0.00 Fetch had bad headers

  fetch_close 3982 0.04 Fetch wanted close

  fetch_oldhttp 0 0.00 Fetch pre HTTP/1.1 closed

  fetch_zero 0 0.00 Fetch zero len

  fetch_failed 0 0.00 Fetch failed

  n_sess_mem 1033 . N struct sess_mem

  n_sess 633 . N struct sess

  n_object 1016443 . N struct object

  n_vampireobject 0 . N unresurrected objects

  n_objectcore 1017564 . N struct objectcore

  n_objecthead 982903 . N struct objecthead

  n_smf 2647421 . N struct smf

  n_smf_frag 622470 . N small free smf

  n_smf_large 3 . N large free smf

  n_vbe_conn 12 . N struct vbe_conn

  n_wrk 8000 . N worker threads

  n_wrk_create 8000 0.08 N worker threads created

  n_wrk_failed 0 0.00 N worker threads not created

  n_wrk_max 11021 0.10 N worker threads limited

  n_wrk_queue 0 0.00 N queued work requests

  n_wrk_overflow 2441 0.02 N overflowed work requests

  n_wrk_drop 0 0.00 N dropped work requests

  n_backend 4 . N backends

  n_expired 6344546 . N expired objects

  n_lru_nuked 183957 . N LRU nuked objects

  n_lru_saved 0 . N LRU saved objects

  n_lru_moved 3692170 . N LRU moved objects

  n_deathrow 0 . N objects on deathrow

  losthdr 84 0.00 HTTP header overflows

  n_objsendfile 0 0.00 Objects sent with sendfile

  n_objwrite 15466812 146.81 Objects sent with write

  n_objoverflow 0 0.00 Objects overflowing workspace

  s_sess 9906155 94.03 Total Sessions

  s_req 16433490 155.99 Total Requests

  s_pipe 37 0.00 Total pipe

  s_pass 108252 1.03 Total pass

  s_fetch 7667658 72.78 Total fetch

  s_hdrbytes 7187255662 68221.35 Total header bytes

  s_bodybytes 111592032839 1059230.32 Total body bytes

  sess_closed 1905544 18.09 Session Closed

  sess_pipeline 0 0.00 Session Pipeline

  sess_readahead 0 0.00 Session Read Ahead

  sess_linger 15277717 145.02 Session Linger

  sess_herd 13547370 128.59 Session herd

  shm_records 1028855796 9765.89 SHM records

  shm_writes 77957008 739.97 SHM writes

  shm_flushes 131005 1.24 SHM flushes due to overflow

  shm_cont 144281 1.37 SHM MTX contention

  shm_cycles 427 0.00 SHM cycles through buffer

  sm_nreq 15306717 145.29 allocator requests

  sm_nobj 2024948 . outstanding allocations

  sm_balloc 13595295744 . bytes allocated

  sm_bfree 40091795456 . bytes free

  sma_nreq 0 0.00 SMA allocator requests

  sma_nobj 0 . SMA outstanding allocations

  sma_nbytes 0 . SMA outstanding bytes

  sma_balloc 0 . SMA bytes allocated

  sma_bfree 0 . SMA bytes free

  sms_nreq 14062 0.13 SMS allocator requests

  sms_nobj 0 . SMS outstanding allocations

  sms_nbytes 487 . SMS outstanding bytes

  sms_balloc 6844837 . SMS bytes allocated

  sms_bfree 6846298 . SMS bytes freed

  backend_req 7668789 72.79 Backend requests made

  n_vcl 1 0.00 N vcl total

  n_vcl_avail 1 0.00 N vcl available

  n_vcl_discard 0 0.00 N vcl discarded

时间: 2024-09-23 17:34:27

深入探讨Varnish缓存命中率的相关文章

php实现监控varnish缓存服务器的状态

 这篇文章主要介绍了php实现监控varnish缓存服务器的状态,Varnish是一款高性能的开源HTTP加速器,可以替代Squid.Nginx等服务器,需要的朋友可以参考下     当varnish和网站部署在同一台服务器上的时候,我们不可能随时登录上服务器去查看varnish的命中率,没想到有大神早就写了出来,今天就分享给大家,使用网页查看varnish命中率.   系统:centos 5.x 软件:varnish-3.0.x   ps:3.0以下的版本可以通过Socket连接到Varnis

解析Linux下Varnish缓存的配置优化_php技巧

Varnish是一款高性能的开源HTTP加速器,挪威最大的在线报纸 Verdens Gang 使用3台Varnish代替了原来的12台Squid,性能比以前更好. 但与老牌的squid相比,各有各的优劣势,网上大量的相对比较只是在其个人对自己熟悉的应用的最大使用上的发挥而已,可能squid到了有能力的人手上才足以发挥最强大的威力Varnish采用了"Visual Page Cache"技术,在内存的利用上,Varnish比Squid具有优势,它避免了Squid频繁在内存.磁盘中交换文件

合理配置MySQL缓存 提高缓存命中率

众所周知,系统读取数据时,从内存中读取要比从硬盘上速度要快好几百倍.故现在绝大部分应用系统,都会最大程度的使用缓存(内存中的一个存储区域),来提高系统的运行效率.MySQL数据库也不例外.在这里,笔者将结合自己的工作经验,跟大家探讨一下,MySQL数据库中缓存的管理技巧:如何合理配置MySQL数据库缓存,提高缓存命中率. 一.什么时候应用系统会从缓存中获取数据? 数据库从服务器上读取数据时,可以从硬盘的数据文件中获取数据,也可以从数据库缓存中读取数据.现在数据库管理员需要搞清楚的是,在什么样的情

centos中varnish缓存配置及php监控varnish状态

1.安装varnish #!/bin/bash# BY kerryhu# MAIL:king_819@163.com# BLOG:http://kerry.blog.51cto.com# Please manual operation yum of before Operation.....#============================ 更新系统时间 ============================yum install -y ntpntpdate time.nist.gov

Linux下Varnish缓存服务器的安装与配置

  Varnish是一款高性能且开源的反向代理服务器和http加速器.与传统的Squid相比,Varnish具有性能更高.速度更快.管理更方便等诸多优点.作者Poul-Henning Kamp是FreeBSD的内核开发者之一.Varnish采用全新的软件体系架构,和现在的硬件提交配合紧密.在1975年时,储存媒介只有两种:内存与硬盘.但现在计算 机系统的内存除了主存外,还包括了cpu内的L1.L2,甚至有L3快取.硬盘上也有自己的快取装置,因此squid cache自行处理物件替换的架构不可能得

缓存命中率

命令行查看Memcached运行状态 很多时候需要监控服务器上的Memcached运行情况,比如缓存的查询次数,命中率之类的.但找到的那个memcached-tool是linux下用perl写的,我也没试过windows能不能用.后来发现个简单的办法可以做到,就是使用Telnet.首先登录到服务器,然后在cmd命令行中键入telnet 127.0.0.1 11211其中127.0.0.1是服务器的地址(这里是本机) ,11211是memcached绑定的端口号.之后命令行窗口全黑只有光标提示,摸

nginx 如何将后端squid缓存命中率字段输出到自己的access.log当中?

问题描述 nginx 如何将后端squid缓存命中率字段输出到自己的access.log当中? 如题,由于需要统计缓存命中率,缓存后端使用的是squid,有什么办法能将squid的缓存命中率字段打印到nginx的access.log当中? 解决方案 这个access.log是nginx自己写的,没有给你定制化,你只能后续再用程序来处理

如何提高缓存命中率

缓存命中率的介绍 命中:可以直接通过缓存获取到需要的数据. 不命中:无法直接通过缓存获取到想要的数据,需要再次查询数据库或者执行其它的操作.原因可能是由于缓存中根本不存在,或者缓存已经过期. 通常来讲,缓存的命中率越高则表示使用缓存的收益越高,应用的性能越好(响应时间越短.吞吐量越高),抗并发的能力越强. 由此可见,在高并发的互联网系统中,缓存的命中率是至关重要的指标. 如何监控缓存的命中率 在memcached中,运行state命令可以查看memcached服务的状态信息,其中cmd_get表

[20171109]缓存命中率神话.txt

[20171109]缓存命中率神话.txt --//在oracle版本的早期,缓存命中率是一个很重要的优化指标,实际上这个根本不重要. --//一般OLTP系统即使出现严重的性能问题,这个数值也很高,实际上一个简单的情况就能说明问题, --//比如走hash join的计划,不小心走了nested loop,可能导致逻辑读上升.缓存命令率很高,但是数据库 --//未必运行在最佳性能. --//这个也是我学习oracle早期一个不好理解的问题,^_^. --//https://connor-mcd