memcached演练(4) 使用apache+memcached-session-manager+tomcat集群(续)

存在一些问题。问题列表

问题1:2个tomcat节点,apache,memcached服务器均放在一个虚拟机,不能真正模拟真实环境。

问题2:不能整整模拟分布式环境。

本文,重新设计下物理结构。沿用《memcached演练(4) 使用apache+memcached-session-manager+tomcat集群》配置。仅仅将主机进行了调整。

memcached演练(4) 使用apache+memcached-session-manager+tomcat集群(续)


操作步骤。

1.将配置好的tomcat节点分别复制到 2个主机

1
2
scp -r apache-tomcat-node1 root@hadoop2:/u01
scp -r apache-tomcat-node2 root@hadoop3:/u01

2.修改apache的worker.properties

1
2
3
4
5
6
7
8
9
10
11
12
13
[root@hadoop1 /]# vi /etc/httpd/conf/workers.properties 
worker.list=loadbalancer
worker.tomcat1.port=8009
worker.tomcat1.host=192.168.163.156
worker.tomcat1.type=ajp13
worker.tomcat1.lbfactor=1
worker.tomcat2.port=8019
worker.tomcat2.host=192.168.163.166
worker.tomcat2.type=ajp13
worker.tomcat2.lbfactor=1
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=tomcat1,tomcat2
worker.loadbalancer.sticky_session=true

3.修改每个节点的tomcat的context相关MSM配置

1
2
3
   <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
      memcachedNodes="n1:192.168.163.146:11211" sticky="false"
      requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$" />

指向192.168.163.146:11211


4.测试下吞吐量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
c:\Apache24\bin>ab  -n 10000 -c 4  http://192.168.163.146/examples/testSession.jsp
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 192.168.163.146 (be patient)
Completed 1000 requests
...
Completed 10000 requests
Finished 10000 requests
Server Software:        Apache/2.2.15
Server Hostname:        192.168.163.146
Server Port:            80
Document Path:          /examples/testSession.jsp
Document Length:        331 bytes
Concurrency Level:      4
Time taken for tests:   10.322 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      5930000 bytes
HTML transferred:       3310000 bytes
Requests per second:    968.84 [#/sec] (mean)
Time per request:       4.129 [ms] (mean)
Time per request:       1.032 [ms] (mean, across all concurrent requests)
Transfer rate:          561.06 [Kbytes/sec] received
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.4      1       5
Processing:     0    4  11.7      3     585
Waiting:        0    4  11.7      3     585
Total:          0    4  11.7      3     585
ERROR: The median and mean for the initial connection time are more than twice the standard
       deviation apart. These results are NOT reliable.

吞吐量:968.84。比上节中的测试结果“727.55”超出不少。

经过多次测试,差别有点大。

Requests per second:    1281.74 [#/sec] (mean)

Requests per second:    1451.22 [#/sec] (mean)


模拟一台节点宕机情况,测试吞吐量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
c:\Apache24\bin>ab  -n 10000 -c 4  http://192.168.163.146/examples/testSession.jsp
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
 
Benchmarking 192.168.163.146 (be patient)
Completed 1000 requests
...
Finished 10000 requests
 
 
Server Software:        Apache/2.2.15
Server Hostname:        192.168.163.146
Server Port:            80
 
Document Path:          /examples/testSession.jsp
Document Length:        331 bytes
 
Concurrency Level:      4
Time taken for tests:   7.994 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      5930000 bytes
HTML transferred:       3310000 bytes
Requests per second:    1250.92 [#/sec] (mean)
Time per request:       3.198 [ms] (mean)
Time per request:       0.799 [ms] (mean, across all concurrent requests)
Transfer rate:          724.41 [Kbytes/sec] received

吞吐量:1250.92。FUCK出乎意料啊。竟然比2个节点的情况下还高。

多次测试,发现均在1700左右。

Requests per second:    1729.64 [#/sec] (mean)

Requests per second:    1779.67 [#/sec] (mean)。


结果出乎我的意料。 记住这个结果,以后做个监控分析下。


最后讨论

关于session应该不应该使用memcached存储,可详见《为什么不能用memcached存储Session

简单整理下表格

 usual session pattern
usual memcached session pattern
* Blobs (250 bytes to 5k+)
* Read from datastore on every single page load
* Usually written to the datastore on every page load
* Reaped from the DB after inactivity
* Read from memcached on page load
* 'set' over the existing session with a new expiration time
* Cache misses mean user is logged out

1.Run your instances out of memory and people get logged out early, or can't log in at all

2.Upgrading memcached, the OS, hardware, etc, now kicks people off

3.Adding or removing servers to the cluster, now kicks people off



如果非常希望借助memcached提高Session读取速度,那么可以借鉴Norkūnas提出的memcached+RDBMS(在有些情况下,NoSQL也可以)的模式:

  • 当用户登录时,将Session “set”到memcached,并写入数据库;

  • 在Session中增加一个字段,标识Session最后写入数据库的时间;

  • 每个页面加载的时候,优先从memcached读取Session,其次从数据库读取;

  • 每加载N页或者Y分钟后,再次将Session写入数据库;

  • 从数据库中获取过期Session,优先从memcached中获取最新数据。



本文转自 randy_shandong 51CTO博客,原文链接:http://blog.51cto.com/dba10g/1837614,如需转载请自行联系原作者
上一篇:Vue前端开发规范


下一篇:一步一步学solr:tomcat7+solr4.9环境搭建