Shulou(Shulou.com)06/01 Report--

Memcached walkthrough (4) uses apache+memcached-session-manager+tomcat clustering, and there are some problems. Question list

Problem 1:2 tomcat nodes, apache,memcached servers are placed in a virtual machine, can not really simulate the real environment.

Problem 2: the distributed environment cannot be fully simulated.

In this paper, the physical structure is redesigned. Follow the "memcached walkthrough (4) using apache+memcached-session-manager+tomcat clustering" configuration. Only the host has been adjusted.

Procedure.

1. Copy the configured tomcat nodes to 2 hosts

Scp-r apache-tomcat-node1 root@hadoop2:/u01scp-r apache-tomcat-node2 root@hadoop3:/u01

two。 Modify the worker.properties of apache

[root@hadoop1 /] # vi / etc/httpd/conf/workers.properties worker.list=loadbalancerworker.tomcat1.port=8009worker.tomcat1.host=192.168.163.156worker.tomcat1.type=ajp13worker.tomcat1.lbfactor=1worker.tomcat2.port=8019worker.tomcat2.host=192.168.163.166worker.tomcat2.type=ajp13worker.tomcat2.lbfactor=1worker.loadbalancer.type=lbworker.loadbalancer.balance_workers=tomcat1,tomcat2worker.loadbalancer.sticky_session=true

3. Modify the context-related MSM configuration of tomcat for each node

Point to 192.168.163.146purl 11211

4. Test the throughput

C:\ Apache24\ bin > ab-n 10000-c 4 http://192.168.163.146/examples/testSession.jspThis is ApacheBench, Version 2.3 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 requestsFinished 10000 requestsServer Software: Apache/2.2.15Server Hostname: 192.168.163.146Server Port: 80Document Path: / examples/testSession.jspDocument Length: 331bytesConcurrency Level: 4Time taken for tests: 10.322 secondsComplete requests: 10000Failed requests: 0Total transferred: 5930000 bytesHTML transferred: 3310000 bytesRequests 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] receivedConnection Times (ms) min mean [+ /-sd] median maxConnect: 0 00.4 1 5Processing: 0 411.7 3 585Waiting: 0 411.7 3 585Total: 0 411.7 3 585ERROR: The median and mean for the Initial connection time are more than twice the standard deviation apart. These results are NOT reliable.

Throughput: 968.84. It is much higher than the test result "727.55" in the previous section.

After many tests, the difference is a little big.

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

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

Simulate the downtime of a node and test the throughput

C:\ Apache24\ bin > ab-n 10000-c 4 http://192.168.163.146/examples/testSession.jspThis is ApacheBench, Version 2.3 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 requestsServer Software: Apache/2.2.15Server Hostname: 192.168.163.146Server Port: 80Document Path: / examples/testSession.jspDocument Length: 331bytesConcurrency Level: 4Time taken for tests: 7.994 secondsComplete requests: 10000Failed requests: 0Total transferred: 5930000 bytesHTML transferred: 3310000 bytesRequests 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

Throughput: 1250.92. FUCK is unexpected. It is even higher than the case of 2 nodes.

After many tests, it was found that they were all about 1700.

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

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

The result was beyond my expectation. Remember this result and do a monitoring analysis later.

Finally, the discussion

For more information on whether session should use memcached storage, see "Why can't you use memcached to store Session"?

Simply sort out the form

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

If you really want to increase Session read speed with memcached, you can learn from the mode of memcached+RDBMS (and, in some cases, NoSQL) proposed by Norkampnas:

When the user logs in, Session "set" to memcached and writes to the database

Add a field to Session to identify when Session was last written to the database

When each page is loaded, the Session is read first from memcached, then from the database.

Write Session to the database again every N or Y minutes after loading

Get the expired Session from the database and get the latest data from the memcached first.

Content from: http://www.infoq.com/cn/news/2015/01/memcached-store-session

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.