ARTS 1
Algorithm算法部分本周比较初级,之前没刷过,以后每周多刷一些。顺便学下go语言palindrome-number// 思路 此消彼长 x=全部数字 r=
Algorithm
算法部分本周比较初级,之前没刷过,以后每周多刷一些。顺便学下go语言
palindrome-number
// 思路 此消彼长 x=全部数字 r=后半段数字的翻转 当 r >= x时说明已经过了 x的一半了 如果是偶数 x==r 如果是奇数则去掉最后一位判断相等n// 如:n// 1221 对比: 12 和21的翻转是否相同n//n// 12321 对比:12 123 / 10n// 问题:n// 怎么拿到每位的数字? 循环 r = x%10 x/10n// 怎么翻转? r*10 + x%10n//n// 时间复杂度 O(N)n// 空间复杂度 O(1)nnfunc isPalindrome(x int) bool {n if x < 0 || (x != 0 && x%10 == 0) {n return falsen }n var r = 0n for x > r {n r = r*10 + x%10n x /= 10n }n return r == x || r/10 == xn}n
two-sum
/**n空间换时间n求两个数的和等于一个数,就等于查找目标数字和数组里的差是否在数组中。 可以通过hashmap将 O(n) 变O(1)然后一层循环n时间复杂度: N(n)n空间复杂度: N(n)n */nfunc twoSum(nums []int, target int) []int {n var m = make(map[int]int)n m[nums[0]] = 0n for i := 1; i < len(nums); i++ {n var c = target - nums[i]n if n, ok := m[c]; ok {n return []int{n, i}n } else {n m[nums[i]] = in }n }n return niln}n
Review
3个方式编写简洁的测试用例
3 easy ways to write cleaner unit tests
- 不要在把多个test在一个function里进行测试。
- 可读性差
- 模糊不清的状态,需要推理才能知道你在验证什么
- 起始状态不明确
- 起一个有有意义的测试名字
这样更具有更好的可读性,而且测试的目的性也更明确。 可以以这个格式起名字
public void testSYSTEM_BEHAVIOR_CONDITION() {
错误实例: 这是在验证什么,谁也不知道
public void testBasicFunctionality() {
正确实例: 让人一看就知道你要干什么
public void testAuthenticate_rejectsUser_whenBadCredentialsProvided() {
- AAA: Arrange, Act, Assert
- Arrange: 初始化test所需要的环境以及变量。如 mock RPC的返回,模拟填充数据库等。
- Act: 执行需要验证的function
- Assert: 验证是否符合你预期的
按照这个顺序去分割你的代码,使可读性更强一些.
例子:
public void Pay_returnInsufficient_whenNotEnoughAmountOfUserProvided() {n // Arrange n int totalamount = 100n // 模拟数据库返回,返回一个小于totalamout的用户n UserDao userdao = mockUserDaoForSomeNotEnoughAccount(totalamount);n PayService.setUserDao(userdao)nn //Act n // 调用支付方法n PayResult result = PayService.pay(user_id,totalamount)nn // Assert n // 验证状态n assertThat(result.status).isEqueis(Insufficient);n}
单元测试还是很重要的,他可以帮住你验证和梳理你程序的流程、条件等。好的testcese应该让人知道你在验证什么,可读性、目的性要强,同时也方便让他人进行阅读。 对自己负责也对其他人负责
Tip
在用grpc做rpc通讯的时候,不像传统的http可以直接curl请求做测试。 发现了个项目可以用curl的方式调用grpc在此分享一下。
grpcurl -d '{"id": 1234, "tags": ["foo","bar"]}' n grpc.server.com:443 my.custom.server.Service/Method
https://github.com/fullstorydev/grpcurl
Share
最新在看linux性能优化实战,补一些基础的知识,先有个概念,然后在买书深入学些下。把学到一些知识点分享一下。
系统在变慢的时候,首先看下机器的负载情况。
通过top和uptime可以查看平均负载
$ uptimen11:07:56 up 546 days, 22:43, 2 users, load average: 3.12, 3.15, 3.35n# 上边是过去1、5、15分钟的平均负载
System load averages is the average number of processes that are either in a runnable or uninterruptable state. A process in a runnable state is either using the CPU or waiting to use the CPU. A process in uninterruptable state is waiting for some I/O access, eg waiting for disk. The averages are taken over the three time intervals. Load averages are not normalized for the number of CPUs in a system, so a load average of 1 means a single CPU system is loaded all the time while on a 4 CPU system it means it was idle 75% of the time.
系统平均负载简单来说就是就是单位时间内,系统正在处理runnable状态的和不可中断状态的进程。
runnable状态: 正在使用CPU的进程和等待使用CPU的进程。
不可中断状态: 正在等待IO处理的进程。 是系统对进程和硬件的一种保护机制,保证在回写的时候不会被其他进程中断,进而保护数据。
总结下就是平均负载就是活跃的进程数
。是当前IO、CPU、等待进程数的负载情况,所以只看CPU使用率是不能完全代表机器的负载的。
负载超过多少就算高了呢。
一般来说推荐超过70%就算高了. 那怎么计算这个比例呢? 就是平均负载除以CPU核数即可。 获取CPU核数
$ grep 'model name' /proc/cpuinfo | wc -ln4
我的机器是4核心的。 上边负载有3个值,看哪个呢? 都要看的其实,3个值表示一个趋势,比如说过 15分钟的时候负载是7,1分钟的负载是3,那说明负载在降低。反之
可以分场景对比下指标
首先安装systat,其中包含了很多监控系统的工具。 其中mqstat用来查看多核CPU的性能的,pidstat是用来查看进程的运行情况的. 还可以通过stress来模拟IO繁忙和CPU繁忙的状态,进行对应的对比
yum install -y sysstat stress
CPU密集型
终端1 把一核跑满
stress --cpu 1 --timeout 600
终端2 可以看到load已经到1了快,如果跑够一分钟的话就会变成1了。
uptime 11:37:46 up 292 days, 20:07, 4 users, load average: 0.94, 0.49, 0.23
查看每个CPU的负载情况
mpstat -P ALL 5 1nLinux 3.10.0-693.el7.x86_64 (mall-admin1.cf.bj.tx.lan) 2019年03月23日 _x86_64_ (4 CPU)nn11时34分48秒 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idlen11时34分53秒 all 25.18 0.00 0.15 0.05 0.00 0.00 0.00 0.00 0.00 74.62n11时34分53秒 0 0.20 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 99.60n11时34分53秒 1 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.80n11时34分53秒 2 0.20 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 99.40n11时34分53秒 3 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00nn平均时间: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idlen平均时间: all 25.18 0.00 0.15 0.05 0.00 0.00 0.00 0.00 0.00 74.62n平均时间: 0 0.20 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 99.60n平均时间: 1 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.80n平均时间: 2 0.20 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 99.40n平均时间: 3 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
可以看到CPU利用率25% CPU3 被用到了100%
查看哪个进程负载比较高
pidstat -u 5 1nLinux 3.10.0-693.el7.x86_64 (mall-admin1.cf.bj.tx.lan) 2019年03月23日 _x86_64_ (4 CPU)nn11时41分29秒 UID PID %usr %system %guest %CPU CPU Commandn11时41分34秒 0 4696 100.00 0.00 0.00 100.00 3 stressn11时41分34秒 0 12487 0.40 0.00 0.00 0.40 1 barad_agentnn平均时间: UID PID %usr %system %guest %CPU CPU Commandn平均时间: 0 4696 100.00 0.00 0.00 100.00 - stressn平均时间: 0 12487 0.40 0.00 0.00 0.40 - barad_agent
可以看到是我们的stress把把CPU用到了100%
下边基本上就是上边的这几个指标不同的变,我大概说下数据就不补了,有兴趣的同学直接按照上面的命令查看就行
IO密集型
stress -i 1 --timeout 600
负载仍然是1 查看指标的时候会看到%iowait的总值到100%
大量进程场景
stress -c 8 --timeout 600
负载是8 已经严重超标了 %CPU 50%