如果后台对某个图片传的是url, 在前台怎么直接展示这个图片？ $(‘#example’).DataTable({ "processing": true, "serverSide": true, "ajax": { "url": "/someRestful", "type": "POST" }, "columns": [ … { "data": "imageUrl", "render": function ( data, type, full, meta ) { return data == null? ”: ‘<img src="’ + data + ‘"/>’; } }, … ] });
从后台获取动态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": …
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，以查看更多系统指标)
网卡不仅带宽要高，而且一定要支持多队列，单队列网卡的中断机制无法利用多核CPU的能力.
一个通用的系统监控工具：Zabbit. 收藏一下。
1. 数据库里的数据量太小。 2. 数据或参数均匀分布，忽略了热区(hot spot)的存在。 3. 在循环中使用同样的参数，触发了缓存而不自知。 最好的办法是： 1. 把生产环境现有的数据复制到测试环境中 2. 在生产环境中记录日志，记下所有数据的产生和访问参数，然后在测试环境中重放它们。
一次性能测试会访问系统很多次，每次的rt都不一样。应该看哪个值？ 看max response time并没有意义，因为它可能只是个尖峰(spike)，是奇异点。 看average response time会好很多，但如果尖峰太夸张，可能会严重影响平均值。 最合适的值是percentile response time, 比如"95%的请求的rt在5ms以内" 这种。
benchmarking – 即平常所说的性能测试：你的系统有多快，极限是多少 profiling – 即调优。为什么我的系统的rt和qps是这个状况，是什么引起的？
一个系统能承载多大的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.
基于比较的分页机制中，输入是一个被比较值。 页码式分页机制中，输入则是页码。 用户体验 对于数据不断增长的功能，页码式分页机制在用户体验方面有个缺点：你翻到下一页时可能会看到刚刚已经看到过的记录。 以贴吧为例，你进到第一页时，你看到的是06，05，04这三条记录；翻到第二页时，本应看到的是03、02、01。 然而在你翻页之前，另一个用户插进了记录07记录； 这时再看第二页时，系统认为此时第一页是07、06、05，于是把第二页04、03、02返回给你，而你刚刚已经看了记录04. tps越高，这种现象就越严重。 而基于比较的分页机制就没有这个问题。第一页看到06, 05, 04; 翻到第二页时，客户端 “告诉系统我要比04更小的三条记录”， 不管这时有没有新增记录07，系统收到的指令都是“比04更小的三条记录”，所以总是返回03、02、01. 性能 如果要对分页查看列表的功能进行性能优化，一个常见的策略就是对前几页进行缓存。用缓存有一个问题：缓存的key是哪些？ 对于页码式分页机制，缓存的key就是页码；要缓存前N页，只需缓存N个key对应的数据。 而对于比较式分页机制，缓存的key是什么？ 它可能是你系统中的任何值，而且随着数据的增减，这个值可能原来是页尾，马上就又不是了。 要缓存多少个key? 只能把所有值都缓存一遍。除了首页由于被比较值固定为0可以缓存之外，其他页都无法缓存。 用户足迹追踪 比较式分页机制对用户足迹追踪不利。你很难根据访问记录（如access log)，决定大部分用户会下翻多少页；而页码式分页机制就没这个问题。