PHP session机制

转自 https://www.cnblogs.com/acpp/archive/2011/06/10/2077592.html

一、默认机制,用磁盘文件来实现PHP会话。php.ini配置:session.save_handler = files

1、session_start()

A、 session_start()是session机制的开始,它有一定概率开启垃圾回收,因为session是存放在文件中,PHP自身的垃圾回收是无效的,SESSION的回收是要删文件的,这个概率是根据php.ini的配置决定的,但是有的系统是 session.gc_probability =0,这也就是说概率是0,而是通过cron脚本来实现垃圾回收。 session.gc_probability =1
session.gc_divisor =1000
session.gc_maxlifetime =1440 //过期时间 默认24分钟
//概率是 session.gc_probability/session.gc_divisor 结果 1/1000, 

B、 session会判断当前是否有$_COOKIE[session_name()];session_name()返回保存session_id的COOKIE键值,这个值可以从php.ini找到 session.name = PHPSESSID(默认值)

C、 如果不存在会生成一个session_id,然后把生成的session_id作为COOKIE的值传递到客户端。相当于执行了下面COOKIE 操作,注意的是,这一步执行了setcookie()操作,COOKIE是在header头中发送的,这之前是不能有输出的,PHP有另外一个函数 session_regenerate_id() 如果使用这个函数,这之前也是不能有输出的。

setcookie(session_name(),
    session_id(),
    session.cookie_lifetime, // 默认0
    session.cookie_path, // 默认'/'当前程序跟目录下都有效
    session.cookie_domain, // 默认为空
 )

D、 如果存在那么session_id =$_COOKIE[session_name];然后去session.save_path指定的文件夹里去找名字为’SESS_』.session_id()的文件。读取文件的内容反序列化,然后放到$_SESSION中。

2、 为$_SESSION赋值

比如新添加一个值$_SESSION[『test』] =’blah』; 那么这个$_SESSION只会维护在内存中,当脚本执行结束的时候,用把$_SESSION的值写入到session_id指定的文件夹中,然后关闭相关资源.      这个阶段有可能执行更改session_id的操作,比如销毁一个旧的的session_id,生成一个全新的session_id.一半用在自定义 session操作,角色的转换上,
比如Drupal.Drupal的匿名用户有一个SESSION的,当它登录后需要换用新的session_id。

 if (isset($_COOKIE[session_name()])) {
     setcookie(session_name(),'',time() -42000,'/'); // 旧session cookie过期
 }
 session_regenerate_id(); // 这一步会生成新的session_id
 // session_id()返回的是新的值

3、 写入SESSION操作

在脚本结束的时候会执行SESSION写入操作,把$_SESSION中值写入到session_id命名的文件中,可能已经存在,可能需要创建新的文件。

4、 销毁SESSION

SESSION发出去的COOKIE一般属于即时COOKIE,保存在内存中,当浏览器关闭后,才会过期,假如需要人为强制过期,比如 退出登录,而不是关闭浏览器,那么就需要在代码里销毁SESSION,方法有很多:
A、 setcookie(session_name(),session_id(),time() -8000000,..); // 退出登录前执行
B、 usset($_SESSION); // 这会删除所有的$_SESSION数据,刷新后,有COOKIE传过来,但是没有数据
C.、session_destroy(); // 这个作用更彻底,删除$_SESSION 、session文件和session_id 当不关闭浏览器的情况下,再次刷新,B和C都会有COOKIE传过来,但是找不到数据

附:如何设置一个严格30分钟过期的Session
http://www.laruence.com/2012/01/10/2469.html

小谈MySql查询缓存

原文地址:https://blog.csdn.net/ClementAD/article/details/46806469
http://imysql.com/2014/09/05/mysql-faq-why-close-query-cache.shtml

Query Cache(查询缓存,以下简称QC)存储SELECT语句及其产生的数据结果,特别适用于:频繁提交同一个语句,并且该表数据变化不是很频繁的场景,例如一些静态页面,或者页面中的某块不经常发生变化的信息。QC有可能会从InnoDB Buffer Pool或者MyISAM key buffer里读取结果。

由于QC需要缓存最新数据结果,因此表数据发生任何变化(INSERT、UPDATE、DELETE或其他可能产生数据变化的操作),都会导致QC被刷新。

根据MySQL官方的测试,QC的优劣分别是:

1、如果对一个表执行简单的查询,但每次查询都不一样的话,打开QC后,性能反而下降了13%左右。但通常实际业务中,通常不会只有这种请求,因此实际影响应该比这个小一些。

2、如果对一个只有一行数据的表进行查询,则可以提升238%,这个效果还是非常不错的。

因此,如果是在一个更新频率非常低而只读查询频率非常高的场景下,打开QC还是比较有优势的,其他场景下,则不建议使用。而且,QC一般也维持在100MB以内就够了,没必要设置超过数百MB。

启用查询缓存

查看查询缓存情况:
mysql> show variables like 『%query_cache%』; 
(query_cache_type 为 ON 表示已经开启)
+——————————+———-+
| Variable_name      | Value    |
+——————————+———-+
| have_query_cache     | YES      |
| query_cache_limit       | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size       | 20971520 |
| query_cache_type         | ON       |
| query_cache_wlock_invalidate | OFF      |
+——————————+———-+

如果不是ON,修改配置文件以开启查询缓存:

mysql.cnf 中添加:
query_cache_size = 20M
query_cache_type = ON

重启mysql服务:

service mysql restart

查看缓存使用情况:
mysql> show status like 『qcache%』;  
+————————-+———-+
| Variable_name           | Value    |
+————————-+———-+
| Qcache_free_blocks      | 83       |
| Qcache_free_memory      | 19811040 |
| Qcache_hits             | 3108196  |
| Qcache_inserts          | 757254   |
| Qcache_lowmem_prunes    | 20720    |
| Qcache_not_cached       | 47219    |
| Qcache_queries_in_cache | 47       |
| Qcache_total_blocks     | 276      |
+————————-+———-+

其中各个参数的意义如下:
Qcache_free_blocks:缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理,从而得到一个空闲块。
Qcache_free_memory:缓存中的空闲内存。
Qcache_hits:每次查询在缓存中命中时就增大
Qcache_inserts:每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。
Qcache_lowmem_prunes:缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个 数字在不断增长,就表示可能碎片非常严重,或者内存很少。(上面的 free_blocks和free_memory可以告诉您属于哪种情况)
Qcache_not_cached:不适合进行缓存的查询的数量,通常是由于这些查询不是 SELECT 语句或者用了now()之类的函数。
Qcache_queries_in_cache:当前缓存的查询(和响应)的数量。
Qcache_total_blocks:缓存中块的数量。

此外,QC也不适用于下面几个场景:

  1. 子查询或者外层查询;
  2. 存储过程、存储函数、触发器、event中调用的SQL,或者引用到这些结果的;
  3. 包含一些特殊函数时,例如:BENCHMARK()、CURDATE()、CURRENT_TIMESTAMP()、NOW()、RAND()、UUID()等等;
  4. 读取mysql、INFORMATION_SCHEMA、performance_schema 库数据的;
  5. 类似SELECT…LOCK IN SHARE MODE、SELECT…FOR UPDATE、SELECT..INTO OUTFILE/DUMPFILE、SELECT..WHRE…IS NULL等语句;
  6. SELECT执行计划用到临时表(TEMPORARY TABLE);
  7. 未引用任何表的查询,例如 SELECT 1+1 这种;
  8. 产生了 warnings 的查询;
  9. SELECT语句里加了 SQL_NO_CACHE 关键字;

更加奇葩的是,MySQL在从QC中取回结果前,会先判断执行SQL的用户是否有全部库、表的SELECT权限,如果没有,则也不会使用QC。

相比下面这个,其实上面所说的都不重要。

最为重要的是,在MySQL里QC是由一个全局锁在控制,每次更新QC的内存块都需要进行锁定。
例如,一次查询结果是20KB,当前 query_cache_min_res_unit 值设置为 4KB(默认值就是4KB,可调整),那么么本次查询结果共需要分为5次写入QC,每次都要锁定,可见其成本有多高。

我们可以通过 PROFILING 功能来查看 QC 相关的一些锁竞争,例如像下面这样的:

• Waiting for query cache lock
• Waiting on query cache mutex

或者,也可以通过执行 SHOW PROCESSLIST 来看线程的状态,例如:

• checking privileges on cached query
检查用户是否有权限读取QC中的结果集

• checking query cache for query
检查本次查询结果是否已经存储在QC中

• invalidating query cache entries
由于相关表数据已经修改了,因此将QC中的内存记录被标记为失效

• sending cached result to client
从QC中,将缓存后的结果返回给客户程序

• storing result in query cache
将查询结果缓存到QC中

如果可以频繁看到上述几种状态,那么说明当前QC基本存在比较重的竞争。

说了这么多废话,其实核心要点就一个:
如果线上环境中99%以上都是只读,很少有更新,再考虑开启QC吧,否则,就别开了。
关闭方法很简单,有两种:

1、同时设置选项 query_cache_type = 0 和 query_cache_size = 0;
2、如果用源码编译MySQL的话,编译时增加参数 –without-query-cache 即可;

延伸阅读:
http://www.dbasquare.com/kb/how-query-cache-can-cause-performance-problems/
http://www.percona.com/blog/2012/09/05/write-contentions-on-the-query-cache/
http://dev.mysql.com/doc/refman/5.6/en/query-cache.html

使用Supervisor托管Laravel队列进程

supervisor的安装(Ubuntu 系统)

sudo apt-get install supervisor

supervisor的配置

一般配置文件在/etc/supervisor/conf.d 目录下
也可以运行这个命令可以生成一个默认的配置文件:

echo_supervisord_conf > /etc/supervisor/supervisord.conf

生成成功后,打开编辑这个文件,把最后的 include 块的注释打开,并修改如下:

[include]files = /etc/supervisor/*.conf

新增的 Supervisor 配置文件放在 /etc/supervisor 目录下,并且以 conf 结尾。

这时我们使用新的配置文件来启动 Supervisor:

supervisord -c /etc/supervisord.conf

如果提示已经有进程在运行,那么先 kill 掉它。

supervisor托管队列进程

首先在 /etc/supervisor 目录下新增一个 Supervisor 的配置文件,如下:
文件名laravel-worker.conf,和配置文件中指定的program保持一致

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=/usr/bin/php7 /home/vagrant/code/ccerp-v2/artisan queue:work --tries=3
autostart=true
autorestart=true
user=vagrant
numprocs=8
redirect_stderr=true
stdout_logfile=/var/log/supervisor/laravel-queue.log

这里 user 填写网站运行进程的用户,如 vagrant,numprocs 表示启动多少个进程来监听 Laravel 队列。
一切就绪后,我们使用如下命令就可以启动队列进程的监听了:

注意: 修改了配置文件以后都要进行 reload 和 update

supervisord # 先执行
sudo supervisorctl reload
sudo supervisorctl update
sudo supervisorctl start laravel-worker:*
// 或者
sudo supervisorctl start all

在这一步,可能发生错误,提示如下:

laravel-worker:laravel-worker_00: ERROR (spawn error)
laravel-worker:laravel-worker_01: ERROR (spawn error)
laravel-worker:laravel-worker_02: ERROR (spawn error)
laravel-worker:laravel-worker_03: ERROR (spawn error)
laravel-worker:laravel-worker_04: ERROR (spawn error)
laravel-worker:laravel-worker_05: ERROR (spawn error)
laravel-worker:laravel-worker_06: ERROR (spawn error)
laravel-worker:laravel-worker_07: ERROR (spawn error)

解决过程:

  1. 把 Supervisor 的日志文件,和新增的队列配置文件中的日志文件,用 chown 把用户和组设置为正确的,如本例是 chown vagrant:vagrant file_name,把日志文件权限设置为 777。
  2. 另外一个问题,artisan执行报错,路径不能用相对路径,要用绝对路径(比如 /home/vagrant/Code/laravel/artisan,不能写成 ~/Code/laravel/artisan)

再次经过上述步骤,成功开启进程管理:

aravel-worker:laravel-worker_00: started
laravel-worker:laravel-worker_01: started
laravel-worker:laravel-worker_02: started
laravel-worker:laravel-worker_03: started
laravel-worker:laravel-worker_04: started
laravel-worker:laravel-worker_05: started
laravel-worker:laravel-worker_06: started
laravel-worker:laravel-worker_07: started