为什么PostgreSQL比MongoDB还快之完结篇(深挖单点索引查询)

之前两篇测试中发现:单点索引查询中PostgreSQL的速度是MongoDB(WiredTiger引擎)的4倍。
http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=20726500&id=4960138
http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=20726500&id=4981629

虽然本人很偏好PG,但也对这个结果表示不能理解。按照常理,纯NoSQL的MongoDB应该比PG快或和PG差不多快才比较合理。
所以,在之前测试的基础上再进行一次深入的挖掘。

之前的0匹配查询,由于执行的时间太短,没有采集到CPU利用率,而且时间值太小,对比的准确性也值得怀疑。
所以,现在构造一个循环的单点索引查询,并在单并发和多并发场景下对比PG和MongoDB的性能。

1. MongoDB(WiredTiger引擎)的测试

单并发测试
循环1万次单点索引查询,平均一次大约返回一条记录。

点击(此处)折叠或打开

  1. -bash-4.1$ cat batchselect_mongo.sh
  2.    for ((i=0;i${1};i++))
  3.    do
  4.        echo "db.json_tables.find({ brand: 'ACME${i}'})"
  5.    done
  6. -bash-4.1$ sh batchselect_mongo.sh 10000|time -p mongo benchmark >/dev/null
  7. real 8.53
  8. user 4.59
  9. sys 2.62
  10. -bash-4.1$ sh batchselect_mongo.sh 10000|time -p mongo benchmark|grep ACME|wc
  11. real 8.33
  12. user 5.33
  13. sys 1.51
  14.    9091 3281851 22061914

看看top的资源使用

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 08:29:13 up 11 days, 11:29, 6 users, load average: 0.09, 0.03, 0.01
  3. Tasks: 159 total, 2 running, 157 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 16.8%us, 1.3%sy, 0.0%ni, 75.6%id, 0.0%wa, 0.0%hi, 6.4%si, 0.0%st
  5. Mem: 1019320k total, 942260k used, 77060k free, 134736k buffers
  6. Swap: 2064376k total, 64712k used, 1999664k free, 265524k cached
  7. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  8. 3951 postgres 20 0 746m 63m 9200 R 85.5 6.4 0:06.97 mongo
  9. 26391 postgres 20 0 617m 339m 12m S 19.3 34.1 10:01.76 mongod

算下来mongod进程占用CPU 1.6s(8.33*19.3%=1.6)

3并发的测试
前面一直是单并发测试,现在看看3并发的场景(测试机是4核)。

点击(此处)折叠或打开

  1. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  2. [1] 5398
  3. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  4. [2] 5401
  5. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  6. [3] 5412
  7. -bash-4.1$ real 8.61
  8. user 6.30
  9. sys 0.64
  10. real 8.61
  11. user 6.37
  12. sys 0.59
  13. real 8.49
  14. user 6.36
  15. sys 0.62
  16. [1] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  17. [2]- Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  18. [3]+ Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null

3并发时的top结果

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 08:42:13 up 11 days, 11:42, 6 users, load average: 1.26, 0.95, 0.39
  3. Tasks: 166 total, 4 running, 162 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 67.4%us, 5.3%sy, 0.0%ni, 25.0%id, 0.0%wa, 0.0%hi, 2.3%si, 0.0%st
  5. Mem: 1019320k total, 570600k used, 448720k free, 1008k buffers
  6. Swap: 2064376k total, 136636k used, 1927740k free, 38632k cached
  7. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  8. 5399 postgres 20 0 746m 63m 9192 R 82.5 6.3 0:05.27 mongo
  9. 5402 postgres 20 0 744m 61m 9192 R 82.5 6.1 0:05.27 mongo
  10. 5413 postgres 20 0 744m 61m 9192 R 82.1 6.2 0:04.96 mongo
  11. 26391 postgres 20 0 625m 266m 3048 S 47.5 26.8 10:27.54 mongod

可以注意到几点
1)每个客户端的执行时间和单并发时差不多一样。3个mongo进程和1个mongod进程几乎各占了一个CPU核,没有CPU争用。
2)mongod进程的CPU实际占用时间是8.6*47.5%=4s,是单并发时的2.5倍(接近理论效果的3倍,里面会有测量误差)
3)性能瓶颈还是在客户端

10并发的测试
10并发时,忙碌的进程数超过CPU核心数,会有CPU争用。

点击(此处)折叠或打开

  1. -bash-4.1$
  2. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  3. [1] 5156
  4. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  5. [2] 5159
  6. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  7. [3] 5161
  8. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  9. [4] 5163
  10. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  11. [5] 5166
  12. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  13. [6] 5170
  14. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  15. [7] 5172
  16. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  17. [8] 5174
  18. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  19. [9] 5177
  20. -bash-4.1$ sh batchselect_mongo.sh 10000 |time -p mongo benchmark >/dev/null &
  21. [10] 5179
  22. -bash-4.1$
  23. -bash-4.1$ real 25.15
  24. user 7.97
  25. sys 1.06
  26. real 25.54
  27. user 7.93
  28. sys 1.02
  29. real 26.32
  30. user 7.94
  31. sys 1.08
  32. real 26.63
  33. user 8.39
  34. sys 0.93
  35. real 27.01
  36. user 8.44
  37. sys 1.04
  38. real 28.06
  39. user 8.52
  40. sys 1.02
  41. real 28.16
  42. user 8.11
  43. sys 1.24
  44. real 28.27
  45. user 8.47
  46. sys 1.03
  47. real 28.64
  48. user 8.23
  49. sys 1.13
  50. real 29.14
  51. user 8.11
  52. sys 1.12
  53. [1] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  54. [2] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  55. [3] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  56. [4] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  57. [5] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  58. [6] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  59. [7] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  60. [8] Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  61. [9]- Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null
  62. [10]+ Done sh batchselect_mongo.sh 10000 | time -p mongo benchmark > /dev/null

10并发时的top结果

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 08:40:22 up 11 days, 11:40, 6 users, load average: 1.60, 0.40, 0.14
  3. Tasks: 187 total, 11 running, 176 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 73.7%us, 24.9%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 1.5%si, 0.0%st
  5. Mem: 1019320k total, 969800k used, 49520k free, 77180k buffers
  6. Swap: 2064376k total, 66948k used, 1997428k free, 36160k cached
  7. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  8. 26391 postgres 20 0 625m 332m 5220 S 50.5 33.4 10:10.47 mongod
  9. 5168 postgres 20 0 745m 50m 9200 R 40.5 5.0 0:02.16 mongo
  10. 5175 postgres 20 0 745m 58m 9192 R 40.5 5.9 0:02.19 mongo
  11. 5167 postgres 20 0 745m 48m 9192 R 34.9 4.9 0:01.97 mongo
  12. 5157 postgres 20 0 745m 48m 9192 R 34.6 4.8 0:01.96 mongo
  13. 5184 postgres 20 0 744m 44m 9192 R 34.6 4.5 0:01.68 mongo
  14. 5164 postgres 20 0 744m 44m 9192 R 33.6 4.5 0:01.67 mongo
  15. 5182 postgres 20 0 744m 44m 9192 R 31.2 4.5 0:01.58 mongo
  16. 5180 postgres 20 0 744m 44m 9192 R 30.9 4.5 0:01.58 mongo
  17. 5181 postgres 20 0 744m 44m 9192 R 29.2 4.5 0:01.52 mongo
  18. 5183 postgres 20 0 744m 44m 9192 R 28.6 4.5 0:01.54 mongo

1)mongod进程的CPU实际占用时间大约是27*50.5%=13.5s,是单并发时的8.4倍(接近理论效果的10倍,里面会有测量误差)
2)CPU被撑满,客户端消耗的大部分的CPU资源。


2. PostgreSQL的测试

单并发测试
循环1万次单点索引查询,平均一次大约返回一条记录。

点击(此处)折叠或打开

  1. -bash-4.1$ cat batchselect_pg.sh
  2. for ((i=0;i
  3. do
  4. echo "SELECT data FROM json_tables WHERE data @> '{\"brand\":\"ACME${i}\"}';"
  5. done
  6. -bash-4.1$ sh batchselect_pg.sh 10000|time -p psql -qAt benchmark >/dev/null
  7. real 1.48
  8. user 0.13
  9. sys 0.14

由于PG太快了,不好收集top信息,改成10万次循环。

点击(此处)折叠或打开

  1. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null
  2. real 10.72
  3. user 0.96
  4. sys 1.01
  5. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark |wc
  6. real 10.91
  7. user 0.61
  8. sys 1.49
  9. 9091 3172759 21561900

看看top结果

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 09:18:00 up 11 days, 12:18, 6 users, load average: 0.35, 0.14, 0.05
  3. Tasks: 166 total, 2 running, 164 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 27.5%us, 4.5%sy, 0.0%ni, 67.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
  5. Mem: 1019320k total, 349168k used, 670152k free, 9200k buffers
  6. Swap: 2064376k total, 68376k used, 1996000k free, 243836k cached
  7. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  8. 9042 postgres 20 0 587m 77m 76m R 81.8 7.8 0:04.35 postgres
  9. 9038 postgres 20 0 103m 1224 1064 S 31.9 0.1 0:01.60 sh
  10. 9041 postgres 20 0 105m 1204 1016 S 18.6 0.1 0:01.08 psql
算下来postgres进程占用CPU 8.9s(10.9*81.1%=8.9)。也就是说mongod进程的CPU实际占用时间是postgres进程的1.8倍,而不是之前简单测试得出的4倍。

3并发的测试
点击(此处)折叠或打开
  1. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  2. [1] 9740
  3. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  4. [2] 9743
  5. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  6. [3] 9746
  7. -bash-4.1$
  8. -bash-4.1$
  9. -bash-4.1$ real 14.15
  10. user 1.21
  11. sys 1.03
  12. real 14.34
  13. user 1.20
  14. sys 1.01
  15. real 14.41
  16. user 1.23
  17. sys 1.01
  18. [1] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  19. [2]- Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  20. [3]+ Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null

top的结果

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 09:25:01 up 11 days, 12:25, 6 users, load average: 0.97, 0.24, 0.08
  3. Tasks: 176 total, 4 running, 172 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 68.6%us, 13.3%sy, 0.0%ni, 18.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
  5. Mem: 1019320k total, 354280k used, 665040k free, 9512k buffers
  6. Swap: 2064376k total, 68376k used, 1996000k free, 243848k cached
  7. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  8. 9749 postgres 20 0 587m 77m 76m R 70.2 7.8 0:08.37 postgres
  9. 9750 postgres 20 0 587m 77m 76m R 67.5 7.8 0:08.60 postgres
  10. 9748 postgres 20 0 587m 77m 76m R 65.8 7.8 0:08.44 postgres
  11. 9739 postgres 20 0 103m 1224 1064 S 31.9 0.1 0:03.39 sh
  12. 9745 postgres 20 0 103m 1224 1064 S 28.9 0.1 0:03.35 sh
  13. 9742 postgres 20 0 103m 1228 1064 S 25.3 0.1 0:03.32 sh
  14. 9741 postgres 20 0 105m 1200 1016 S 16.3 0.1 0:01.95 psql
  15. 9744 postgres 20 0 105m 1200 1016 S 15.6 0.1 0:02.01 psql
  16. 9747 postgres 20 0 105m 1200 1016 S 15.6 0.1 0:01.95 psql

算下来postgres进程占用CPU 大约28.3s(14*(70%+67%+65%+)=28.3),是单并发时的3.2倍。


10并发的测试
点击(此处)折叠或打开
  1. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  2. [1] 10628
  3. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  4. [2] 10631
  5. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  6. [3] 10634
  7. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  8. [4] 10637
  9. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  10. [5] 10639
  11. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  12. [6] 10641
  13. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  14. [7] 10644
  15. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  16. [8] 10646
  17. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  18. [9] 10648
  19. -bash-4.1$ sh batchselect_pg.sh 100000|time -p psql -qAt benchmark >/dev/null &
  20. [10] 10651
  21. -bash-4.1$
  22. -bash-4.1$
  23. -bash-4.1$ real 38.35
  24. user 1.47
  25. sys 0.85
  26. real 38.72
  27. user 1.39
  28. sys 0.90
  29. real 38.87
  30. user 1.45
  31. sys 0.91
  32. real 39.13
  33. user 1.50
  34. sys 0.82
  35. real 39.23
  36. user 1.41
  37. sys 0.94
  38. real 39.63
  39. user 1.42
  40. sys 0.93
  41. real 39.75
  42. user 1.39
  43. sys 0.90
  44. real 39.84
  45. user 1.36
  46. sys 0.98
  47. real 40.24
  48. user 1.42
  49. sys 0.92
  50. real 40.58
  51. user 1.40
  52. sys 0.93
  53. [1] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  54. [2] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  55. [3] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  56. [4] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  57. [5] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  58. [6] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  59. [7] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  60. [8] Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  61. [9]- Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null
  62. [10]+ Done sh batchselect_pg.sh 100000 | time -p psql -qAt benchmark > /dev/null

10并发时的top结果

点击(此处)折叠或打开

  1. [root@hanode1 bin]# top
  2. top - 09:34:12 up 11 days, 12:34, 6 users, load average: 5.21, 1.33, 0.47
  3. Tasks: 201 total, 12 running, 189 sleeping, 0 stopped, 0 zombie
  4. Cpu(s): 84.7%us, 14.9%sy, 0.0%ni, 0.3%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st
  5. Mem: 1019320k total, 370468k used, 648852k free, 9952k buffers
  6. Swap: 2064376k total, 68376k used, 1996000k free, 243860k cached
  7. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  8. 10664 postgres 20 0 587m 77m 76m R 26.8 7.8 0:08.77 postgres
  9. 10660 postgres 20 0 587m 77m 76m R 26.2 7.8 0:08.83 postgres
  10. 10665 postgres 20 0 587m 77m 76m R 26.2 7.8 0:08.46 postgres
  11. 10642 postgres 20 0 587m 77m 76m R 25.5 7.8 0:08.48 postgres
  12. 10656 postgres 20 0 587m 77m 76m R 25.5 7.8 0:08.15 postgres
  13. 10663 postgres 20 0 587m 77m 76m R 24.8 7.8 0:08.48 postgres
  14. 10662 postgres 20 0 587m 77m 76m R 23.8 7.8 0:08.73 postgres
  15. 10635 postgres 20 0 587m 77m 76m R 23.5 7.8 0:09.20 postgres
  16. 10666 postgres 20 0 587m 77m 76m R 23.5 7.8 0:08.87 postgres
  17. 10654 postgres 20 0 587m 77m 76m R 22.5 7.8 0:07.94 postgres
  18. 10636 postgres 20 0 103m 1224 1064 S 9.9 0.1 0:03.15 sh
  19. 10638 postgres 20 0 103m 1228 1064 S 9.9 0.1 0:03.08 sh
  20. 10650 postgres 20 0 103m 1228 1064 S 9.6 0.1 0:03.18 sh
  21. 10627 postgres 20 0 103m 1228 1064 S 9.3 0.1 0:03.00 sh
  22. 10640 postgres 20 0 103m 1228 1064 R 9.3 0.1 0:02.84 sh
  23. 10645 postgres 20 0 103m 1224 1064 S 9.3 0.1 0:03.14 sh
  24. 10630 postgres 20 0 103m 1228 1064 S 8.6 0.1 0:03.22 sh
  25. 10633 postgres 20 0 103m 1228 1064 S 8.6 0.1 0:02.98 sh
  26. 10647 postgres 20 0 103m 1228 1064 S 8.6 0.1 0:03.17 sh
  27. 10643 postgres 20 0 103m 1228 1064 S 8.3 0.1 0:02.82 sh
  28. 10658 postgres 20 0 105m 1200 1016 S 7.0 0.1 0:02.05 psql
  29. 10655 postgres 20 0 105m 1200 1016 S 6.6 0.1 0:02.09 psql
  30. 10629 postgres 20 0 105m 1200 1016 S 6.3 0.1 0:02.02 psql
  31. 10657 postgres 20 0 105m 1200 1016 S 6.3 0.1 0:01.93 psql
  32. 10652 postgres 20 0 105m 1204 1016 S 6.0 0.1 0:01.88 psql
  33. 10649 postgres 20 0 105m 1204 1016 S 5.6 0.1 0:01.84 psql
  34. 10659 postgres 20 0 105m 1200 1016 S 5.6 0.1 0:01.97 psql
  35. 10632 postgres 20 0 105m 1204 1016 S 5.3 0.1 0:02.09 psql
  36. 10653 postgres 20 0 105m 1204 1016 S 5.3 0.1 0:01.96 psql
  37. 10661 postgres 20 0 105m 1200 1016 S 5.3 0.1 0:02.04 psql

1)大致算下来postgres进程占用CPU 大约97.5s(39*25%*10=97.5),是单并发时的10.9倍(97.5/8.9)。
2)CPU被撑满,postgres进程占用了大部分的CPU。

3.总结

测试结果总结如下


从上面的结果可以看出:
1)在多并发场景下,MongoDB和PostgreSQL的服务端进程占用的总CPU时间和并发数基本成正比。说明负载在CPU多核间分担的比较好。
2)多并发时MongoDB在单点索引查询占用的CPU时间大约是PostgreSQL的1.4倍。
3)这个1.4倍的比率基本可以代表了实际场景(高并发,且客户端和服务端不在同一台机器上)下它们的单点索引查询性能差异,而不是之前简单测试显示的4倍。

经过这样严格的比较,我终于可以相信PostgreSQL在单点索引查询上比MongoDB(WiredTiger引擎)快了那么一点点。

结合前两次测试结果,最终的总结如下
1)加载
  WiredTiger的性能是PG的3倍(注1,注2)
2)插入
 相差不大,WiredTiger小胜(注1,注2)
3)全表扫描(0匹配)
 WiredTiger的性能是PG的4倍
4)单点索引扫描
 PG的性能是WiredTiger的1.4倍(注1)
5)数据大小
 PG的数据大小是WiredTiger的3倍

注1)以服务端进程CPU消耗作为衡量指标的,忽略了MongoDB客户端的高CPU消耗。
注2)仅仅是单并发的测试数据

这个结果虽然和开头那个EnterpriseDB的流传较广的测试结果有很大出入,但PG的NoSQL特性在单机环境下仍然有巨大的优势(即:NoSQL+SQL+ACID)。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/297487.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

ajax和spa的区别,在XX团上消费过一次不正规的Spa,现在过来两个月公安局打电话叫我过去...

咨询我帮助人数:36021721.公安局打电话来的原因比较多,具体需要根据电话的内容进行分析。而且公安局的范围比较大,涉及到的部门比较多,每个部门负责处理各自的工作问题,有民事的,也有刑事的。有派出所的&am…

centos7 iptables 端口转发 保存_iptables 防火墙

目录:yum 在线安装yum卸载安装包rpm 卸载yum安装rpm离线安装利用 Downloadonly 插件下载 RPM 软件包及其所有依赖包使用 Yumdownloader 工具来下载 RPM 软件包及其所有依赖包yum 在线安装CentOS7默认的防火墙不是iptables,而是firewalle.yum卸载安装包yum remove to…

日本惊现神操作!偷偷研究飞刀方程致使厕所爆炸......

欢快如厕为何大声惨叫前几天,竟然有模友私信超模君,说这是不是真的。网友私信截图WTF!数学史上就有一道“奇葩的”难题,是历代数学家们在厕所里解决的。厕所冥想1917年,为了给日本武士增添生活趣味,数学家挂…

抓取手机https_python爬虫入门02:教你通过 Fiddler 进行手机抓包

哟~哟~哟~hi起来everybody今天要说说怎么在我们的手机抓包通过python爬虫入门01:教你在 Chrome 浏览器轻松抓包我们知道了 HTTP 的请求方式以及在 Chrome 中摸清了一些套路但是除了对数据进行解析之外有时候我们想对请求的数据或者响应的数据进行篡改怎么做呢&#…

BeetleX进程服务管理组件应用

有些时候需要在程序中启动和管理其他应用进程,当碰到这样的需求的时候可以通过Process对象来完成;为了让使用和管理更方便在这基础上封装 了BeetleX.ServicesProcess组件,通过组件的管理中心让进程操作更方便,同时还集成了Web套件…

升级总代分享思路_桃生企业至尊七郎瓷砖新展厅全新升级惊艳亮相

桃生企业至尊七郎瓷砖新展厅惊艳亮相,将艺术和时尚完美融合,即将成为晋江天工建材城的新地标!2020年桃生企业逆流升级进行中,全新展厅即将揭幕!全新空间 对话年轻轻奢于行,优雅于里,全新一楼的…

烧脑又过瘾!关于c²= b² + a²,你不知道的N个事实

全世界只有3.14 % 的人关注了爆炸吧知识勾股定理你真的懂吗一般人看来,勾股定理只存在于特定的三角形或几何图形中。但实际上,绝大多数人都小看了这条有2600年历史的公式,很多看似不可能的图形,只要涉及到了平方数,勾股…

[snmp++]读取cisco路由交换机信息[一] - 环境搭建

首先从网上下载gn3这个摸拟器以及cisco路由器的bin. 如图,下面的clouds里添加本地连接,这样表示路由器与本机的网卡桥接。即在R2里的接口设置一个与本机的IP地址同一网段。这样局域网的机就可以与R2通信 R2的配置如下 snmp-server community public RO 读…

Dapr + .NET 实战(六)绑定

什么是绑定处理外部事件或调用外部接口的功能就是绑定,绑定可以提供以下好处:避免连接到消息系统 ( 如队列和消息总线 ) 并进行轮询的复杂性聚焦于业务逻辑,而不是如何与系统交互使代码不受 SDK 或外部库的强耦合处理重试和故障恢复Dapr提供了…

对象中multipartfile 空报错_Python 为什么会有个奇怪的“...”对象?

我想到一种特别的写法,很多人会把它当成 pass 语句的替代。在文章发布后,果然有三条留言提及了它。所谓特别的写法就是下面这个:# 用 ... 替代 passdef foo():...它是中文标点符号的半个省略号,也即由英文的 3 个点组成。如果你是…

XP硬盘安装Fedora14图文教程

XP硬盘安装Fedora14图文教程发表于:2010年11月03日 分类:Fedora 26 条评论 5,044 次阅读 昨天是Fedora 14的发布,这篇文章介绍的是如何在windows XP下硬盘安装Fedora 14。 之前写过2篇文章: Linux下硬盘安装Fedora 13:…

用wamper打开php源码_php源码该怎么设置数据库

php源码该怎么设置数据库php源码修改数据库的设置方法:首先在源码中找到程序的配置文件;然后用文本编辑器打开;之后修改数据库地址、数据库名、用户名、连接密码、数据库前缀等参数;最后保存即可。这里以织梦程序为例,…

豆瓣评分9.0+,这几部纪录片看一部少一部!

纪录片是以真实生活为创作素材,以真人真事为表现对象,并对其进行艺术的加工与展现的,以展现真实为本质,并用真实引发人们思考的电影或电视艺术形式。好的纪录片就像打开了一扇新世界的大门,让我们了解更多世界的奇妙之…

记一次 .NET 某纺织工厂 MES系统 API 挂死分析

一:背景 1. 讲故事这个月中旬,有位朋友加我wx求助他的程序线程占有率很高,寻求如何解决,截图如下:说实话,和不同行业的程序员聊天还是蛮有意思的,广交朋友,也能扩大自己的圈子&#…

python求斜边上的高_直角三角形斜边上的高怎么求

展开全部 直角三角形斜边32313133353236313431303231363533e78988e69d8331333431336666上的高的求法: 1. 直角三角形斜边上的高等于两条直角边的乘积除以斜边的商。 例如:直角三角形的两个直角边分别为a和b,斜边为c,那么&#xff…

使用identity+jwt保护你的webapi(一)——identity基础配置

前言用户模块几乎是每个系统必备的基础功能,如果每次开发一个新项目时都要做个用户模块,确实非常无聊。好在asp.net core给我们提供了Identity,使用起来也是比较方便,如果对用户这块需求不是非常个性化的话,identity是…

年轻人不能“饥渴”太久,否则……

全世界只有3.14 % 的人关注了爆炸吧知识文 / 较高端人类来源 / 较高端人类(ID:xinji656)转发到朋友圈健康生活从饮水做起本文来源于微信公众号:较高端人类(ID:xinji656)我们只研究那些你感兴趣的…

Redis集群(一):集群搭建

2019独角兽企业重金招聘Python工程师标准>>> 概述 这里只记录操作步骤和集群测试,保证快速搭建集群环境。具体原理请查阅官方文档(中文版): http://www.redis.cn/topics/cluster-spec.html 集群容灾:Redis集…

python优惠券机器人_python实现机器人卡牌

介绍 这个例子主要利用turtle库实现根据输入动态展示不同机器人的图像和属性信息。 代码部分非原创只是做了些许修改和整理使得更易阅读。 图片和文件资源请访问git仓库获取:链接地址 涉及以下知识点: 1.文件读取 2.字典 3.turtle库的使用 4.控制语句 实…

使用identity+jwt保护你的webapi(二)——获取jwt token

前言上一篇已经介绍了identity在web api中的基本配置&#xff0c;本篇来完成用户的注册&#xff0c;登录&#xff0c;获取jwt token。开始开始之前先配置一下jwt相关服务。配置JWT 首先NuGet安装包&#xff1a;<PackageReference Include"Microsoft.AspNetCore.Authent…