Monthly Archives: October 2014

DataTables中如何兼容列内容为空的情况?

从后台获取动态JSON数据用于DataTables展现时,可能会遇到某行某字段由于为空,导致它不存在于JSON的情况。

这时就会报这个错误:

引用

Requested unknown parameter ‘someColumn’ for row x

要解决这个问题,可以对于特定的列指定该列的默认值,如


<script>
	$( document ).ready(function() {
		$('#someTable').DataTable({
	        "processing": true,
	        "serverSide": true,	        
	         "ajax": {
	                "url": "/someUrl",
	                "type": "POST"
	         },	      
   
	         "columns": [
	                     ...
	                     { "data": "someColumn", defaultContent:"" },
	                     ...
	                 ]	         
		});
	});		
</script>

但如果每列都这样,会很繁琐。可以通过columnDefs.targets做一下全表的配置:

<script>
	$( document ).ready(function() {
		$('#someTable').DataTable({
	        "processing": true,
	        "serverSide": true,	        
	         "ajax": {
	                "url": "/someUrl",
	                "type": "POST"
	         },	      
	         
 	         "columnDefs": [
	                        {	                          
	                          "defaultContent": "",
	                          "targets": "_all"
	                        }
	                      ],	        
	         "columns": [
	                     { "data": "c1" },
	                     { "data": "c2" },
	                     ...              
	                 ]	         
		});
	});		
</script>

MySQL: 查看一次SQL的执行时间都花在哪些环节上


select @@profiling  -- 看看当前的session的profiling打开没有

set profiling = 1  -- 如果没打开,打开一下 


 -- 执行一些sql 
select count(*) ... 

select * from ...


show profiles -- 查看所有已执行的profile

show profile for query 2  -- 看看刚才某条sql执行的具体时间拆分,2是个某个query id 


show profile cpu for query 2  -- 看看刚才某条sql执行的具体时间拆分,并加上相应的cpu信息 (cpu也可以换成all,以查看更多系统指标) 

准备性能测试数据的常见误区

1. 数据库里的数据量太小。

2. 数据或参数均匀分布,忽略了热区(hot spot)的存在。

3. 在循环中使用同样的参数,触发了缓存而不自知。

最好的办法是:

1. 把生产环境现有的数据复制到测试环境中

2. 在生产环境中记录日志,记下所有数据的产生和访问参数,然后在测试环境中重放它们。

性能测试:rt要看percentile response time

一次性能测试会访问系统很多次,每次的rt都不一样。应该看哪个值?

看max response time并没有意义,因为它可能只是个尖峰(spike),是奇异点。

看average response time会好很多,但如果尖峰太夸张,可能会严重影响平均值。

最合适的值是percentile response time, 比如"95%的请求的rt在5ms以内" 这种。

concurrency并非性能测试的结果,而是测试条件

一个系统能承载多大的concurrency (同一瞬间连接中的tcp连接数,或者同时访问系统的用户数) ?对于http系统来说,这个问题意义不大。

你应该要逐渐增大concurrency, 直到你在合理的rt范围内找到qps的极限。qps和rt才是你关心的东西,当这个极限到来时,concurrency是多少,根本是无所谓的,因为只有qps和rt才能真正代表系统为用户提供服务的能力。

正如  ‘High Performance MySQL’ 所说: concurrency is not a
result, but rather a
property of how you set up the benchmark.