Mac itunes备份的文件在哪里 Mac itunes备份文件路径解析

Mac itunes备份的文件在哪里?想必很多使用Mac的朋友也不知道,今天PC6小编教大家通过两种办法找到Mac itunes备份文件路径,方便大家直接管理自己的iTunes备份文件夹。

一、打开Finder,在菜单栏点击“前往”选项,按住option键会显示“资料库”,点击进入

在资料库中,可以找到“Application support”文件夹,继续前往下级Mobilesync文件夹里面的backup就是备份文件所在的地方了。

二、另外一种更加便捷的方法是在Finder下直接通过快捷键commnd+shift+G打开前往文件夹,直接复制:用户名/Library/application support/mobilesync然后回车,打开backup里面的就是了。

 

大型网站技术架构-入门梳理

罗列了大型网站架构涉及到的概念,附上了简单说明

前言

  • 本文是对《大型网站架构设计》(李智慧 著)一书的梳理,类似文字版的“思维导图”
  • 全文主要围绕“性能,可用性,伸缩性,扩展性,安全”这五个要素
  • 性能,可用性,伸缩性这几个要素基本都涉及到应用服务器,缓存服务器,存储服务器这几个方面

概述

  • 三个纬度:演化、模式、要素
  • 五个要素: 性能,可用性,伸缩性,扩展性,安全

演化历程

图例可参考 大型网站架构演化历程

  1. 初始阶段的网站架构:一台服务器,上面同时拥有应用程序,数据库,文件,等所有资源。例如 LAMP 架构
  2. 应用和数据服务分离:三台服务器(硬件资源各不相同),分别是应用服务器,文件服务器和数据库服务器
  3. 使用缓存改善网站性能:分为两种,缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器的远程缓存
  4. 使用应用服务器集群改善网站并发处理能力:通过负载均衡调度服务器来将访问请求分发到应用服务器集群中的任何一台机器
  5. 数据库读写分离:数据库采用主从热备,应用服务器在写数据时访问主数据库,主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器使用专门的数据访问模块从而对应用透明
  6. 使用反向代理和 CDN 加速网站响应:这两者基本原理都是缓存。反向代理部署在网站的中心机房,CDN 部署在网络提供商的机房
  7. 使用分布式文件系统和分布式数据库系统:数据库拆分的最后手段,更常用的是业务分库
  8. 使用 NoSQL 和搜索引擎:对可伸缩的分布式有更好的支持
  9. 业务拆分:将整个网站业务拆分成不同的应用,每个应用独立部署维护,应用之间通过超链接建立联系/消息队列进行数据分发/访问同一数据存储系统
  10. 分布式服务:公共业务提取出来独立部署

架构演化-分布式服务

演化的价值观

  • 大型网站架构的核心价值是随网站所需灵活应对
  • 驱动大型网站技术发展的主要力量是网站的业务发展

误区

  • 一味追随大公司的解决方案
  • 为了技术而技术
  • 企图用技术解决所有问题

架构模式

模式的关键在于模式的可重复性

  • 分层:横向切分
  • 分割:纵向切分
  • 分布式:分层和分割的主要目的是为了切分后的模块便于分布式部署。常用方案:
    • 分布式应用和服务
    • 分布式静态资源
    • 分布式数据和存储
    • 分布式计算
    • 分布式配置,分布式锁,分布式文件,等等
  • 集群:多台服务器部署相同的应用构成一个集群,通过负载均衡设备共同对外提供服务
  • 缓存:将数据放距离计算最近的位置加快处理速度,改善性能第一手段,可以加快访问速度,减小后端负载压力。使用缓存 两个前提条件 :1.数据访问热点不均衡;2.数据某时段内有效,不会很快过期
    • CDN
    • 反向代理
    • 本地缓存
    • 分布式缓存
  • 异步:旨在系统解耦。异步架构是典型的消费者生产者模式,特性如下:
    • 提高系统可用性
    • 加快网站访问速度
    • 消除并发访问高峰
  • 冗余:实现高可用。数据库的冷备份和热备份
  • 自动化:包括发布过程自动化,自动化代码管理,自动化测试,自动化安全检测,自动化部署,自动化监控,自动化报警,自动化失效转移,自动化失效恢复,自动化降级,自动化分配资源
  • 安全:密码,手机校验码,加密,验证码,过滤,风险控制

核心要素

架构是“最高层次的规划,难以改变的规定”。主要关注五个要素:

  • 性能
  • 可用性(Availability)
  • 伸缩性(Scalability)
  • 扩展性(Extensibility)
  • 安全性

架构

下面依次对这五个要素进行归纳

高性能

性能的测试指标主要有:

  • 响应时间:指应用执行一个操作需要的时间
  • 并发数:指系统能够同时处理请求的数目
  • 吞吐量:指单位时间内系统处理的请求数量
  • 性能计数器:描述服务器或者操作系统性能的一些数据指标

性能测试方法:

  • 性能测试
  • 负载测试
  • 压力测试
  • 稳定性测试

性能测试曲线

性能优化,根据网站分层架构,可以分为三大类:

  • Web 前端性能优化
    • 浏览器访问优化
      • 减少 http 请求
      • 使用浏览器缓存
      • 启用压缩
      • CSS 放在页面最上面,JavaScript 放在页面最下面
      • 减少 Cookie 传输
    • CDN 加速:本质是一个缓存,一般缓存静态资源
    • 反向代理
      • 保护网站安全
      • 通过配置缓存功能加速 Web 请求
      • 实现负载均衡
  • 应用服务器性能优化:主要手段有 缓存、集群、异步
    • 分布式缓存(网站性能优化第一定律:优化考虑使用缓存优化性能)
    • 异步操作(消息队列,削峰作用)
    • 使用集群
    • 代码优化
      • 多线程(设计为无状态,使用局部对象,并发访问资源使用锁)
      • 资源复用(单例,对象池)
      • 数据结构
      • 垃圾回收
  • 存储服务器性能优化
    • 机械硬盘 vs. 固态硬盘
    • B+ 树 vs. LSM 树
    • RAID vs. HDFS

高可用

  • 高可用的网站架构:目的是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问,主要手段数据和服务的冗余备份及失效转移
  • 高可用的应用:显著特点是应用的无状态性
    • 通过负载均衡进行无状态服务的失效转移
    • 应用服务器集群的 Session 管理
      • Session 复制
      • Session 绑定
      • 利用 Cookie 记录 Session
      • Session 服务器
  • 高可用的服务:无状态的服务,可使用类似负载均衡的失效转移策略,此外还有如下策略
    • 分级管理
    • 超时设置
    • 异步调用
    • 服务降级
    • 幂等性设计
  • 高可用的数据:主要手段是数据备份和失效转移机制
    • CAP 原理
      • 数据一致性(Consisitency)
      • 数据可用性(Availibility)
      • 分区耐受性(Partition Tolerance)
    • 数据备份
      • 冷备:缺点是不能保证数据最终一致和数据可用性
      • 热备:分为异步热备和同步热备
    • 失效转移:由以下三部分组成
      • 失效确认
      • 访问转移
      • 数据恢复
  • 高可用网站的软件质量保证
    • 网站发布
    • 自动化测试
    • 预发布验证
    • 代码控制
      • 主干开发、分支发布
      • 分支开发、主干发布
    • 自动化发布
    • 灰度发布
  • 网站运行监控
    • 监控数据采集
      • 用户行为日志采集(服务器端和客户端)
      • 服务器性能监控
      • 运行数据报告
    • 监控管理
      • 警报系统
      • 失效转移
      • 自动优雅降级

伸缩性

大型网站的“大型”是指:

  • 用户层面:大量用户及大量访问
  • 功能方面:功能庞杂,产品众多
  • 技术层面:网站需要部署大量的服务器

伸缩性的分为如下几个方面

  • 网站架构的伸缩性设计
    • 不同功能进行物理分离实现伸缩
      • 纵向分离(分层后分离)
      • 横向分离(业务分割后分离)
    • 单一功能通过集群规模实现伸缩
  • 应用服务器集群的伸缩性设计
    • HTTP 重定向负载均衡
    • DNS 域名解析负载均衡
    • 反向代理负载均衡(在 HTTP 协议层面,应用层负载均衡)
    • IP 负载均衡(在内核进程完成数据分发)
    • 数据链路层负载均衡(数据链路层修改 mac 地址,三角传输模式,LVS)
    • 负载均衡算法
      • 轮询(Round Robin, RR)
      • 加权轮询(Weighted Round Robin, WRR)
      • 随机(Random)
      • 最少链接(Least Connections)
      • 源地址散列(Source Hashing)
  • 分布式缓存集群的伸缩性设计
    • Memcached 分布式缓存集群的访问模型
      • Memcached 客户端(包括 API,路由算法,服务器列表,通信模块)
      • Memcached 服务器集群
    • Memcached 分布式缓存集群的伸缩性挑战
    • 分布式缓存的一致性 Hash 算法(一致性 Hash 环,虚拟层)
  • 数据存储服务集群的伸缩性设计
    • 关系数据库集群的伸缩性设计
    • NoSQL 数据库的伸缩性设计

可扩展

系统架构设计层面的“开闭原则”

  • 构建可扩展的网站架构
  • 利用分布式消息队列降低耦合性
    • 事件驱动架构(Event Driven Architecture)
    • 分布式消息队列
  • 利用分布式服务打造可复用的业务平台
    • Web Service 与企业级分布式服务
    • 大型网站分布式服务的特点
    • 分布式服务框架设计(Thrift, Dubbo)
  • 可扩展的数据结构(如 ColumnFamily 设计)
  • 利用开放平台建设网站生态圈

网站的安全架构

XSS 攻击和 SQL 注入攻击是构成网站应用攻击最主要的两种手段,此外还包括 CSRF,Session 劫持等手段。

  • 攻击与防御
    • XSS 攻击:跨站点脚本攻击(Cross Site Script)
      • 反射型
      • 持久型
    • XSS 防御手段
      • 消毒(即对某些 html 危险字符转义)
      • HttpOnly
    • 注入攻击
      • SQL 注入攻击
      • OS 注入攻击
    • 注入防御
      • 避免被猜到数据库表结构信息
      • 消毒
      • 参数绑定
    • CSRF 攻击:跨站点请求伪造(Cross Site Request Forgery)
    • CSRF 防御:主要手段是识别请求者身份
      • 表单 Token
      • 验证码
      • Referer Check
    • 其他攻击和漏洞
      • Error Code
      • HTML 注释
      • 文件上传
      • 路径遍历
    • Web 应用防火墙(ModSecurity)
    • 网站安全漏洞扫描
  • 信息加密技术及密钥安全管理
    • 单向散列加密:不同输入长度的信息通过散列计算得到固定长度的输出
      • 不可逆,非明文
      • 可加盐(salt)增加安全性
      • 输入的微小变化会导致输出完全不同
    • 对称加密:加密和解密使用同一个密钥
    • 非对称加密
      • 信息传输:公钥加密,私钥解密
      • 数字签名:私钥加密,公钥解密
    • 密钥安全管理:信息安全传输是靠密钥保证的,改善手段有:
      • 把密钥和算法放在一个独立的服务器上
      • 将加解密算法放在应用系统中,密钥放在独立服务器
  • 信息过滤与反垃圾
    • 文本匹配
    • 分类算法
    • 黑名单

作者@brianway更多文章:个人网站 | CSDN | oschina

编程类开放书籍荟萃

关于开源图书有人在网络上做了大量整理,本文为大家刊载《免费的编程中文书籍索引》

书山有路勤为径,学海无涯苦作舟!

语言无关类

操作系统

智能系统

web服务器

版本控制

NoSQL

MySQL

项目相关

Web

大数据

编程艺术

其他

语言相关类

AWK

C/C++

CSS/HTML

Dart

Fortran

Java

JavaScript

PHP

iOS

Android

Python

Ruby

Shell

Go

Groovy

LaTeX

LISP

Lua

Haskell

R

Scala

Swift

Perl

Prolog

Vimscript

读书笔记及其它

读书笔记

测试相关

性能测试工具 wrk 安装与使用

今天给大家介绍一款开源的性能测试工具 wrk,简单易用,没有Load Runner那么复杂,他和 apache benchmark(ab)同属于性能测试工具,但是比 ab 功能更加强大,并且可以支持lua脚本来创建复杂的测试场景。

wrk 的一个很好的特性就是能用很少的线程压出很大的并发量, 原因是它使用了一些操作系统特定的高性能 I/O 机制, 比如 select, epoll, kqueue 等。 其实它是复用了 redis 的 ae 异步事件驱动框架. 确切的说 ae 事件驱动框架并不是 redis 发明的, 它来至于 Tcl的解释器 jim, 这个小巧高效的框架, 因为被 redis 采用而更多的被大家所熟知.

wrk GitHub 源码:https://github.com/wg/wrk

安装

wrk只能运行于 Unix 类的系统上,也只能在这些系统上便宜,所以我们需要一个Linux或者macOs。

不得不说,使用了 Win10之后方便很多。

必备条件:

  • Win10 RS及以上版本
  • 启用Ubuntu子系统

1、Win10 系统通过bash命令,切换到Ubuntu子系统。
然后需要安装一下编译工具,通过运行下面命令来安装工具:

# 安装 make 工具
sudo apt-get install make

# 安装 gcc编译环境
sudo apt-get install build-essential

安装 gcc 编译环境的时候最好挂一下VPN,速度会快些。
image

2、安装完成之后使用 git 下载 wrk 的源码到本地:

https://github.com/wg/wrk.git

3、切换到git的wrk目录,然后使用make命令:

cd /mnt/盘符/wrk目录

make

image

编译完成之后,目录下面会多一个 wrk 的文件。

image

测试

使用以下命令来测试一下:

./wrk -c 1 -t 1 -d 1 http://www.baidu.com

image

简单说一下wrk里面各个参数什么意思?

  • -t 需要模拟的线程数
  • -c 需要模拟的连接数
  • –timeout 超时的时间
  • -d 测试的持续时间

结果:

  • Latency:响应时间
  • Req/Sec:每个线程每秒钟的完成的请求数
  • Avg:平均
  • Max:最大
  • Stdev:标准差
  • +/- Stdev: 正负一个标准差占比

标准差如果太大说明样本本身离散程度比较高. 有可能系统性能波动很大.

如果想看响应时间的分布情况可以加上–latency参数
image

我们的模拟测试的时候需要注意,一般线程数不宜过多,核数的2到4倍足够了。 多了反而因为线程切换过多造成效率降低, 因为 wrk 不是使用每个连接一个线程的模型, 而是通过异步网络 I/O 提升并发量。 所以网络通信不会阻塞线程执行,这也是 wrk 可以用很少的线程模拟大量网路连接的原因。

在 wrk 的测试结果中,有一项为Requests/sec,我们一般称之为QPS(每秒请求数),这是一项压力测试的性能指标,通过这个参数我们可以看出应用程序的吞吐量。

总结

关于 wrk 已经介绍完毕了,之所以写这篇文章的目的是为了接下来对 ASP.NET Core做一个性能对比测试(Java,NodeJS,Python等)时需要用到该工具,敬请大家期待。


本文地址:http://www.cnblogs.com/savorboard/p/wrk.html
作者博客:Savorboard
欢迎转载,请在明显位置给出出处及链接


ASP.NET Core 性能对比评测(ASP.NET,Python,Java,NodeJS)

性能是我们日常生活中经常接触到的一个词语,更好的性能意味着能给我们带来更好的用户体检。比如我们在购买手机、显卡、CPU等的时候,可能会更加的关注于这样指标,所以本篇就来做一个性能评测。

性能也一直是我们开发人员一直追求的一个目标,我们在做语言选择,平台选择,架构选择的过程中都需要在性能之间做衡量。

同样性能对 .NET Core 团队来说也是至关重要的,一项新技术的诞生,除了对生产力的提高,还有技术团队对性能的追求。

今天,我们就来做一个对比测试,来看看微软的这样新技术性能到底怎么样,俗话说的好:“是骡子是马,拉出来溜溜”。

下面让我开始吧。

目录

测试目标

在测试之前,我们必须要明确我们本次测试想达到的一个目标。本次测试主要是测试应用程序的一个吞吐量。其中QPS,并发数,响应时间是我们衡量吞吐量的几个重要指标。

以下是本次对比测试的任务目标:

编号 对比方 系统环境 宿主环境 测试目标
1 ASP.NET Core vs ASP.NET Core Windows Kestrel vs IIS 相同平台不同宿主间性能差距
2 ASP.NET Core vs ASP.NET Windows IIS vs IIS 相同平台相同宿主不同框架间性能差距
3 ASP.NET Core vs ASP.NET Windows Kestrel vs IIS 相同平台不同宿主不同框架间性能差距
4 ASP.NET Core vs Python Django Linux Kestrel vs uwsgi 相同平台不同语言不同宿主不同框架间性能差距
5 ASP.NET Core vs Java Servlet Linux Kestrel vs Tomcat 相同平台不同语言不同宿主不同框架间性能差距
6-1 ASP.NET Core vs NodeJS Express Linux Kestrel vs self host 相同平台不同语言不同宿主不同框架间性能差距
6-2 ASP.NET Core vs NodeJS Koa Linux Kestrel vs self host 相同平台不同语言不同宿主不同框架间性能差距

测试工具

工欲善其事,必先利其器。

首先我们需要一个压力测试工具,本次我们使用 wrk,有关于wrk的介绍和使用,请查看我的 这篇博客

然后我们需要一个性能监控工具,因为wrk已经会给我们输出吞吐量相关指标,所以我们只需要一个监控CPU,内存等的工具即可。本次我们使用 Windows 自带的性能监视器。

Windows 性能监视器的打开方式:开始-->运行-->perfmon
PS: 在下面的监视器图中如果你发现cpu并没有100%,那是因为使用的虚拟机占用了一部分cpu,所以计算方式应该是虚拟机的cpu使用量+物理机cpu使用量。

环境准备

既然做测试,首先肯定是具有相同的运行环境,以下是本次测试使用到的软件和硬件环境。

  • 软硬件环境
名称 操作系统 职责 CPU 核心数 内存
物理机器1 Windows 10 RS1 Web Server && 负载生成 Intel Core i5-4590 4 16G
虚拟机器2 Ubuntu Server 16.04 Web Server Intel Core i5-4590 2 1G
虚拟机器3 Nano Server Web Server Intel Core i5-4590 2 1G

其中 虚拟机器2 为 “物理机器1” 使用 win 10 的 Hyper-v 技术搭建的一个虚拟机,所以有几个指标对于本次测试至关重要。

image

虚拟机设置为了2个虚拟核心,以便于在压力测试的过程中利用到多核特性。其中的虚拟机保留百分比,需要设置为100%,来分配两个物理cpu所有资源给它。占综系统资源百分比设置为50,也就是说虚拟机最多利用本地50%的CPU资源,虚拟机限制设置为100。

  • 源代码

AspNet 在 GitHub 有一个开源的性能测试项目叫benchmarks,之前新闻中23倍的性能也是出自于本测试项目, 为了客观,本次测试并不使用该项目,所有项目均我们自己新建,并且使用当前流行的框架,为了排除代码因素的干扰,我们使用最简单的 Hello World!。

如果你觉得本代码不够客观公正,欢迎在GitHub上Fork本项目,修改后给我提交PR,我会重新进行测试,并且更新本博客。

GitHub: https://github.com/yuleyule66/AspNetCoreBenchmarksCompare

开始测试

wkr命令参数:

wrk -t 2 -c 50 -d 20 --latency http://xxx

因为已经分配了2个核心给虚拟机使用,所以开的是双线程。使用这个参数是我经过多次测试,得到的一个最佳的模拟效果。

1 – ASP.NET Core vs ASP.NET Core(Kestrel vs IIS)

ASP.NET Core

  • 环境:物理机器1
  • OS:Windows 10 RS 1
  • Host:Kestrel
wrk -t 2 -c 50 -d 20 --latency http://localhost:5000

Running 20s test @ http://localhost:5000
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.49ms   21.72ms 358.18ms   98.99%
    Req/Sec    23.28k     1.98k   27.48k    92.13%
  Latency Distribution
     50%    0.00us
     75%    6.87ms
     90%   12.76ms
     99%   28.58ms
  913567 requests in 20.02s, 115.00MB read
Requests/sec:  45636.43
Transfer/sec:      5.74MB

ASP.NET Core

  • 环境:物理机器1
  • OS:Windows 10 RS 1
  • Host:IIS 10.0
wrk -t 2 -c 50 -d 20 --latency http://localhost:5001

Running 20s test @ http://localhost:5001
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.30ms    5.81ms  22.24ms   76.75%
    Req/Sec     7.61k   455.21     8.12k    90.00%
  Latency Distribution
     50%    3.14ms
     75%    9.02ms
     90%   15.62ms
     99%   17.17ms
  302880 requests in 20.02s, 44.77MB read
Requests/sec:  15130.97
Transfer/sec:      2.24MB

总结

QPS(Kestrel):45636.43
QPS(IIS):15130.97

这个结果难免令人诧异,程序部署在IIS上和使用Kestrel竟然差别如此之大,我们知道实际上即便部署在IIS上,实际上内部还是调用的Kestrel,但是测试结果告诉了我们答案。可能是由于IIS进一步的http封装导致的吧,毕竟IIS提供了那么多的其他功能。

以下是Windows的性能监视器,两个的曲线图差不多我就放一个了:
image

  • 红色:CPU使用率
  • 蓝色:内存使用率

2 – ASP.NET Core vs ASP.NET(IIS vs IIS)

ASP.NET Core

  • 环境:物理机器1
  • OS:Windows 10 RS
  • Host:IIS
wrk -t 2 -c 50 -d 20 --latency http://localhost:5001

Running 20s test @ http://localhost:5001
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.30ms    5.81ms  22.24ms   76.75%
    Req/Sec     7.61k   455.21     8.12k    90.00%
  Latency Distribution
     50%    3.14ms
     75%    9.02ms
     90%   15.62ms
     99%   17.17ms
  302880 requests in 20.02s, 44.77MB read
Requests/sec:  15130.97
Transfer/sec:      2.24MB

ASP.NET

  • 环境:物理机器1
  • OS:Windows 10 RS
  • Host:IIS
  • .NET Framework 4.6 + MVC5
wrk -t 2 -c 50 -d 20 --latency http://localhost:10280

Running 20s test @ http://localhost:10280
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.94ms    5.58ms  22.82ms   80.90%
    Req/Sec     9.10k   444.04     9.42k    95.00%
  Latency Distribution
     50%    3.00ms
     75%   10.10ms
     90%   13.57ms
     99%   16.45ms
  362177 requests in 20.00s, 89.80MB read
Requests/sec:  18104.50
Transfer/sec:      4.49MB

总结

QPS(ASP.NET Core + IIS):15130.97
QPS(ASP.NET + IIS):18104.50

看到这个结果的时候,其实我还是有一点小惊讶的,不仅仅是因为ASP.NET跑出了1.8K QPS这样的成绩,而是通过Stdev可以看出,ASP.NET 在应对高请求高并发的时候,还是相当的稳定的。这个结果说明了,在同样Windows+IIS环境中,ASP.NET是具有优势和竞争力的,可以预见 ASP.NET 应该还不会淘汰的太快。

Windows性能图我就不上了,基本上和上面一样 CPU 100% 的使用率。

3 – ASP.NET Core vs ASP.NET(Kestrel vs IIS)

ASP.NET Core

  • 环境:物理机器1
  • OS:Windows 10 RS 1
  • Host:Kestrel
wrk -t 2 -c 50 -d 20 --latency http://localhost:5000

Running 20s test @ http://localhost:5000
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     5.49ms   21.72ms 358.18ms   98.99%
    Req/Sec    23.28k     1.98k   27.48k    92.13%
  Latency Distribution
     50%    0.00us
     75%    6.87ms
     90%   12.76ms
     99%   28.58ms
  913567 requests in 20.02s, 115.00MB read
Requests/sec:  45636.43
Transfer/sec:      5.74MB

ASP.NET

  • 环境:物理机器1
  • OS:Windows 10 RS
  • Host:IIS
  • .NET Framework 4.6 + MVC5
wrk -t 2 -c 50 -d 20 --latency http://localhost:10280

Running 20s test @ http://localhost:10280
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.94ms    5.58ms  22.82ms   80.90%
    Req/Sec     9.10k   444.04     9.42k    95.00%
  Latency Distribution
     50%    3.00ms
     75%   10.10ms
     90%   13.57ms
     99%   16.45ms
  362177 requests in 20.00s, 89.80MB read
Requests/sec:  18104.50
Transfer/sec:      4.49MB

总结

QPS(ASP.NET Core + Kestrel):45636.43

QPS(ASP.NET + IIS):18104.50

这个结果应该是在预料之中的,大概是3倍的性能差距吧。但是我觉得和之前微软宣传的23倍的性能,是有很大差距的。

4 – ASP.NET Core vs Python Django

注意,以下我们开始使用到虚拟机器2了,我们要在Windows性能监控器里面查看CPU使用率,还需要再添加2个计数器。

物理处理器 \Hyper-V Hypervisor Logical Processor(*) \ %Total Run Time

虚拟处理器 \Hyper-V Hypervisor Virtual Processor(*) \ %Guest Run Time

ASP.NET Core

  • 环境:虚拟机器2
  • OS:Linux
  • Host:Kestrel
wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:5000/
Running 20s test @ http://192.168.2.48:5000/
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.39ms    5.33ms  33.05ms   77.20%
    Req/Sec    13.43k     1.32k   17.95k    74.75%
  Latency Distribution
     50%    2.00ms
     75%    8.15ms
     90%   13.75ms
     99%   15.80ms
  534787 requests in 20.01s, 67.32MB read
Requests/sec:  26730.83
Transfer/sec:      3.37MB

image


Python Django

  • 环境:虚拟机器2
  • OS:Linux
  • Host:uwsgi
  • Python 2.7.12 + Django 1.10.2

服务端宿主运行命令:

sudo uwsgi --http :8000 --file HelloWorldWebApp/wsgi.py --processes=2 --threads==2 --daemonize=/var/log/django.log

结果:

wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:8000
Running 20s test @ http://192.168.2.48:8000
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    23.40ms   12.23ms  78.13ms   74.81%
    Req/Sec   792.64    143.13     1.25k    67.10%
  Latency Distribution
     50%   21.16ms
     75%   31.25ms
     90%   38.26ms
     99%   53.75ms
  31591 requests in 20.09s, 3.01MB read
  Socket errors: connect 0, read 31591, write 0, timeout 0
Requests/sec:   1572.64
Transfer/sec:    153.67KB

image


总结

QPS(ASP.NET Core + Kestrel):26730.83

QPS(Python Django + Kestrel ):1572.64

不知道是我运行的方式不对还是怎么,这个差距还是蛮大的,大概是17倍的差距。看来Python Web 在做针对于做大请求并发情况下,还是弱了一点。

5 – ASP.NET Core vs Java Servlet

C# 和 JAVA 一直是两大阵营的开发人员喜欢讨论的话题,为了避免有阵营偏见,JAVA的源代码是我委托我们一个JAVA同事编写的,并且委托由他部署的,并且已经交代了他避免使用jsp,由Servlet直接输出。

ASP.NET Core

  • 环境:虚拟机器2
  • OS:Linux
  • Host:Kestrel
wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:5000/
Running 20s test @ http://192.168.2.48:5000/
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.39ms    5.33ms  33.05ms   77.20%
    Req/Sec    13.43k     1.32k   17.95k    74.75%
  Latency Distribution
     50%    2.00ms
     75%    8.15ms
     90%   13.75ms
     99%   15.80ms
  534787 requests in 20.01s, 67.32MB read
Requests/sec:  26730.83
Transfer/sec:      3.37MB

image


Java Servlet

  • 环境:虚拟机器2
  • OS:Linux
  • Host:Tomcat 7.0 + jdk 1.7
wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:8080/j2eeWebApp/hello
Running 20s test @ http://192.168.2.48:8080/j2eeWebApp/hello
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.93ms    6.17ms  68.17ms   81.53%
    Req/Sec     9.22k     1.01k   14.06k    70.50%
  Latency Distribution
     50%    1.75ms
     75%    9.91ms
     90%   14.39ms
     99%   22.10ms
  367733 requests in 20.05s, 93.70MB read
Requests/sec:  18338.73
Transfer/sec:      4.67MB

image


总结

QPS(ASP.NET Core + Kestrel):26730.83

QPS(Java Servlet + Tomcat):18338.73

通过这个结果我们可以看出,在性能上 ASP.NET Core 已经超越了Java。不说太多了,怕被喷…

6 – ASP.NET Core vs NodeJS

ASP.NET Core

  • 环境:虚拟机器2
  • OS:Linux
  • Host:Kestrel
wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:5000/
Running 20s test @ http://192.168.2.48:5000/
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.39ms    5.33ms  33.05ms   77.20%
    Req/Sec    13.43k     1.32k   17.95k    74.75%
  Latency Distribution
     50%    2.00ms
     75%    8.15ms
     90%   13.75ms
     99%   15.80ms
  534787 requests in 20.01s, 67.32MB read
Requests/sec:  26730.83
Transfer/sec:      3.37MB

NodeJS

  • 环境:虚拟机器2
  • OS:Linux
  • Host:self host
wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:1337
Running 20s test @ http://192.168.2.48:1337
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     4.40ms    5.23ms  31.25ms   79.47%
    Req/Sec    10.32k     0.88k   11.37k    90.25%
  Latency Distribution
     50%    2.08ms
     75%    8.32ms
     90%   13.19ms
     99%   15.93ms
  410902 requests in 20.02s, 61.13MB read
Requests/sec:  20522.89
Transfer/sec:      3.05MB

image

***************更新1:NodeJS 添加Web框架*******

Express框架,cluster模式

wrk -t 2 -c 30 -d 20 --latency http://192.168.2.48:1337
Running 20s test @ http://192.168.2.48:1337
  2 threads and 30 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.97ms    1.45ms  32.23ms   83.97%
    Req/Sec     7.83k     0.90k    8.82k    91.50%
  Latency Distribution
     50%    2.00ms
     75%    2.50ms
     90%    3.50ms
     99%    6.00ms
  311896 requests in 20.01s, 66.03MB read
Requests/sec:  15583.99
Transfer/sec:      3.30MB

Koa框架,cluster模式

wrk -t 2 -c 30 -d 20 --latency http://192.168.2.48:1337
Running 20s test @ http://192.168.2.48:1337
  2 threads and 30 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.74ms    0.86ms  13.59ms   86.65%
    Req/Sec     8.79k   804.39     9.98k    87.75%
  Latency Distribution
     50%    1.99ms
     75%    2.00ms
     90%    2.96ms
     99%    4.83ms
  349856 requests in 20.02s, 53.38MB read
Requests/sec:  17478.73
Transfer/sec:      2.67MB

从测试结果可以看出,Koa框架性能略高于Express框架。

**************End***********


总结

QPS(ASP.NET Core + Kestrel):26730.83

QPS(NodeJS):20522.89 (非cluster模式)
QPS(NodeJS Express):15583.99 (cluster模式)
QPS(NodeJS Koa):17478.73 (cluster模式)

这个结果着实让我吃了一惊,NodeJS性能竟然如此惊人,比JAVA要快10%。作为一个解释性语言这个性能可以说达到了极致,虽然在测试之前知道NodeJS采用的是异步IO,但还是被测试结果震惊了。

===========更新1=========

NodeJS 在加入了Web框架之后,性能仍然不弱。


不知道是不是因为NodeJS没有经过什么Web框架,直接输出的结果。所以我需要再加测一个ASP.NET Core 通过中间件直接输入结果的性能,这次我要使用微软的测试项目benchmarks。

wrk -t 2 -c 50 -d 20 --latency http://192.168.2.48:5000/plaintext
Running 20s test @ http://192.168.2.48:5000/plaintext
  2 threads and 50 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     3.69ms    5.03ms  18.30ms   80.38%
    Req/Sec    25.06k     4.14k   29.19k    83.33%
  Latency Distribution
     50%  806.00us
     75%    6.82ms
     90%   12.62ms
     99%   15.63ms
  1002476 requests in 20.10s, 126.20MB read
Requests/sec:  49874.57
Transfer/sec:      6.28MB

My God !!!

总结

以下是测试结果的汇总统计:

编号 对比方 系统环境 宿主环境 测试结果(QPS)
1 ASP.NET Core vs ASP.NET Core Windows Kestrel vs IIS 45.6k vs 15.2k
2 ASP.NET Core vs ASP.NET Windows IIS vs IIS 15.2k vs 18.2k
3 ASP.NET Core vs ASP.NET Windows Kestrel vs IIS 45.6k vs 18.2k
4 ASP.NET Core vs Python Django Linux Kestrel vs uwsgi 26.7k vs 1.57k
5 ASP.NET Core vs Java Servlet Linux Kestrel vs Tomcat 26.7k vs 18.3k
6-1 ASP.NET Core vs NodeJS Express Linux Kestrel vs self host 26.7k vs 15.6k
6-2 ASP.NET Core vs NodeJS Koa Linux Kestrel vs self host 26.7k vs 17.5k

image

作为微软的下一代 ASP.NET 框架,ASP.NET Core没有让我们失望,通过本次测试,我们大概对ASP.NET Core的性能心里有底了。一个圈子的良好发展需要社区的共同参与,也希望大家共同为.NET Core社区贡献自己的力量,同时也希望看到本篇文章的CTOs们以后在平台和框架选择的过程中考虑一下ASP.NET Core,因为她真的很优秀。

如果你觉得本篇博客对您有帮助的话,感谢您的【推荐】,如果你对.NET Core感兴趣可以关注我,我会定期在博客分享关于.NET Core的学习心得。


========更新1 :2016-10-17 感谢园友“幻天芒” 关于NodeJS的贡献======

有园友反应NodeJS项目没有使用web mvc框架,所以特更新,同时感谢 “幻天芒” 在github向nodeJS项目提交的PR。

1、添加node 多核cpu cluster 模式
2、添加node koa框架和express框架测试

更新测试结果。


========更新2 :2016-10-19 添加ASP.NET Core 在Windows Nano Server的测试结果======

环境:虚拟机器3,和Linux硬件一样

wrk -t 2 -c 30 -d 20 --latency http://192.168.2.52:8000
Running 20s test @ http://192.168.2.52:8000
  2 threads and 30 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.08ms  709.98us  31.25ms   77.30%
    Req/Sec    13.98k     1.38k   15.80k    87.75%
  Latency Distribution
     50%    1.00ms
     75%    1.03ms
     90%    2.00ms
     99%    3.45ms
  556354 requests in 20.03s, 70.04MB read
Requests/sec:  27780.50
Transfer/sec:      3.50MB

这个测试结果和微软的测试结果是一致的,Nano Server大概比在Linux上高出5-10%的性能。


========更新3 :2016-12-30 添加 WebListener 测试 ======

WebListener 是基于 Http.sys 实现的非跨平台只能运行于 Windows 的一个 web 服务器,其目的我觉得是为了替代iis的性能不足问题。

引用自QQ群 Lyrics:我的理解是这样的,Kestrel是跨平台的,定义了一套通用的 feature,然而目前在windows平台上,Kestrel所具备的feature 并没有 http.sys 提供的那么强大,为了使老系统能顺利迁移到core上面,微软不得已搞了一个能支持所有http.sys 的web server,就是weblistener, weblistener 能完整的利用 http.sys 的特性,在windows上功能完整。

测试结果:

Windows ASP.NET Core Kestrel :35.5k

Windows ASP.NET Core WebListener:27.9k

Kestrl 大概比 WebListener 高出 5-10%的性能。


本文地址:http://www.cnblogs.com/savorboard/p/dotnet-benchmarks.html
作者博客:Savorboard
欢迎转载,请在明显位置给出出处及链接


ASP.NET Core: 全新的ASP.NET !

背景

最新版本的 ASP.NET 叫做 ASP.NET Core (也被称为 ASP.NET 5)   它颠覆了过去的 ASP.NET。

什么是 ASP.NET Core?

ASP.NET Core 1.0 是一个开源跨平台的开发框架,用于构建基于云的现代 Web 应用 。它是从底层开始重新构建来提供性能优良的Web应用开发框架,可以部署在云上或者本地服务器上。另外,它使得 ASP.NET 应用更加精简和模块化(可以根据你的应用需要向里面添加其他模块),跨平台(你可以很容易的在 Windows, Mac or Linux 上开发和部署你的应用),云优化(你可以在云上在云上部署和调试你的应用)。

以前的版本

对于使用 ASP.NET 旧版本的我们来说,这意味着什么?

如果你正在使用旧版本的 ASP.NET 或者你有 WebForms 的开发背景,那么你将会认识到 ASP.NET Core 有多完美,这感觉起来就像从古典的 ASP 时代来到全新的 ASP.NET 的世界。

1

现在,让我们来一探究竟

下面列出 ASP.NET Core 1.0 的核心变化.

跨平台的运行时

你可以在 OSX 和 Linux上运行 ASP.NET Core 应用,这对于 ASP.NET 来说,这具有跨时代的意义,也给 ASP.NET 开发者和设计师们带来了全新的体验。ASP.NET Core 具有两个运行时,这意味着你可以选择不同的运行环境来部署你的应用,使得你的应用将更加灵活。

ASP.NET Core 1.0 是一个 ASP.NET 的重构版本,它运行于最新的 .NET Core。它是模块化的,允许开发者以插件的形式添加应用所需要的模块,大多数的功能都将作为插件提供并通过 NuGet 程序包管理。这样做的一个好处就是你可以升级应用的一个模块,但丝毫不会影响其他模块;另外,.NET Core 是一个跨平台的运行时,因此你可以在 OSX 或 Linux 操作系统上部署你的应用;它也是一个云优化的运行时,用于在云上部署和调试应用;.NET Core 可以和你的应用程序一起被部署,当服务器上有多个 .NET Core 版本时, 你依旧可以运行 ASP.NET Core 应用。

你也可以创建只运行在 windows 下完整 .NET 框架的 ASP.NET Core 应用。

ASP.NET 4.6 是最新的完整 .NET Framework 的发布版本,它允许你可以利用所有的 .NET 组件并且具备向后兼容能力。如果你计划将应用迁移到 .NET core,那么你需要做适量的修改,因为 .NET Core 相对于完整 .NET Framework 来说有所限制。

需要明确的是,ASP.NET 4.6 更加成熟。它如今久经考验并且现已发布并可使用。ASP.NET Core 1.0 是1.0 发布版本,包含 Web API 和 MVC,但是现在还没有 SignalR 和 Web Pages。,它也不支持VB 和 F# 语言。

ASP.NET Core 不再只依赖Visual Studio

ASP.NET Core 的跨平台,让它不再只依赖 Visual Studio,开发者和设计师们可以在自己喜欢的环境上工作。比如 Sublime Text,WebStorm ,这真是太棒了!

新的工程解决方案结构

如果你使用 Visual Studio 创建了一个空的 ASP.NET Core 工程,那么你将会看到下面的惊喜。(除非你没有使用之前的 ASP.NET 创建过任何项目)

2

你感觉到惊喜了吗?新的工程结构完全不一样了, 工程模板焕然一新,包含以下的新文件:

· global.json: 你可以在这里放置解决方案的配置信息和工程之间的引用。

· Program.cs: 这个文件包含了 ASP.NET Core RC2 应用的 Main 方法,负责配置和启动应用程序。

· src folder: 包含组成你应用程序的全部项目代码。

· wwwroot: 你的静态文件将被放置在这个文件夹,它们都将作为资源直接提供给客户端,包含 HTML,CSS 和 JavaScript 文件。

· project.json: 包含项目设置。在 ASP.NET Core中,你可以通过使用 NuGet 程序包管理工具(NPM)添加 NuGet 包或者编辑这个文件来管理从属。你可以通过任何文本编辑器来编辑这个文件,如果你使用 Visual Studio 2015,,这将会更加 轻松,因为它的智能提示会帮助你找到合适的 NuGet 包作为从属。project.json 就像下面这样。

3

· startup.cs 这个主要放置你 ASP.NET Core 的 stratup 和 configuration 代码,下面就是 stratup 类的样子。

4

ConfigureServices 方法定义了你应用程序使用的服务,Configure 方法用来定义组成请求管道的中间件。

· References: 它包含了 .NETCoreApp 第一个版本运行时的引用。

WebForms

是的,WebForms 不再是 ASP.NET 5 的一部分,这真令人悲伤。你可以继续使用 VS2015 的 .NET 4.6 来构建 Web Forms 应用,但是却不能体会 ASP.NET 5 的新特性了。

我已经开发了很多年从小型到大型的企业级 Web Forms 应用。 我很喜欢 Web Forms,,事实上我还会继续支持在各种论坛使用 WebForms 的社区,比如 http://forums.asp.net。但是我们是时候进步了,去学习一些新东西。这是学习 ASP.NET MVC 最后的时间了,就像过去的许多事物,你要么去适应,要么被淘汰。

除了 WebForms, the .NET Core 也没有包含 Windows Forms, WCF, WPF, Silverlight 等等。

VB.NET and F#

目前,在当前 ASP.NET Core 1.0 RC2 版本中, VB.NET 和 F# 也不被支持。

MVC Core 统一架构

5


ASP.NET Core 将见证 MVC, Web API 和 Web Pages(可能包含)组合在一个架构中,它被称为 ASP.NET MVC Core。尽管当前发布版本中,还不支持 Web Pages and SignalR。

在之前的 ASP.NET MVC 中, MVC 控制器和 Web API 控制器是不同的。 一个 MVC 控制器使用基类 System.Web.MVC.Controller ,一个 Web API 控制器使用基类 System.Web.Http.ApiController 。 在 MVC Core 中,会为它们提供一个共同的基类,就是 Microsoft.AspNetCore.Mvc.Controller

对于 HTML Helpers 来说,MVC 和 Web Pages 的合并是非常有可能的。 Web Pages 编程模型对当前版本来说还不适用,所以我们还不能负责任地说下一步计划合并哪些特性。 但是我们可以预测到,传统的 MVC 模型绑定将会出现。

View Components

在之前 ASP.NET MVC 中,, Html.Action() 帮助方法一般用于调用一个 sub-controller。ASP.NET MVC Core 将会使用新的 View Components 用来代替使用Html.Action() 的部件。

View Components 支持完全异步,这允许你创建异步的视图组件。

下面是一个简单的视图组件的例子,根据身份会返回个人介绍。

using Microsoft.AspNetCore.Mvc;  
using MVC6Demo.Models;  
using System.Threading.Tasks;  
using System.Collections.Generic;  
  
namespace MVC6Demo.ViewComponents  
{  
    public class PersonListViewComponent : ViewComponent  
    {  
        public async Task<iviewcomponentresult> InvokeAsync(string status) {  
            string viewToUse = "Default";  
            bool isFiltered = false;  
  
            PersonModel model = new PersonModel();  
  
            if (status.ToLower().Equals("registered")) { 
                viewToUse = "Registered"; isFiltered = true; 
            }  
                  
            var p = await GetPersonAsync(status, isFiltered);  
            return View(viewToUse,p);  
        }  
          
        private Task<ienumerable<person>> GetPersonAsync(string status, bool isFiltered) {  
            return Task.FromResult(GetPerson(status,isFiltered));  
        }  
        private IEnumerable<person> GetPerson(string status, bool isFiltered) {  
            PersonModel model = new PersonModel();  
  
            if (isFiltered)  
                return model.GetPersonsByStatus(status);  
            else  
                return model.GetAll;  
  
        }  
    }  
}  </person>

下面是 View Component 的视图:

<h3>Person List</h3>  
<ul>  
    @foreach (var p in Model) {  
        <li>@string.Format("{0} {1}",p.FirstName,p.LastName)</li>  
    }  
</ul>

这里展示了如何在主视图中调用 View Components

<div>   
    @await Component.InvokeAsync("PersonList", new { type = "Registered" })
</div>

新指令: @inject, @using, @inherits

ASP.NET MVC Core 提供了少量新指令。 下面我们来看看如何使用 @inject。 @inject 指令允许你注入一个类中的方法到你的视图中。

这是一个简单的类,来展示一些异步的方法。

using System.Threading.Tasks;  
using System.Linq;  
  
namespace MVC6Demo.Models  
{  
    public class Stats  
    {  
        private PersonModel _persons = new PersonModel();  
  
        public async Task<int> GetPersonCount() {  
            return await Task.FromResult(_persons.GetAll.Count());  
        }  
  
        public async Task<int> GetRegisteredPersonCount() {  
            return await Task.FromResult(
                      _persons.GetAll.Where(o => o.Status.ToLower().Equals("registered")).Count());  
        }  
  
        public async Task<int> GetUnRegisteredPersonCount() {  
            return await Task.FromResult(
                     _persons.GetAll.Where(o => o.Status.ToLower().Equals("")).Count());  
        }  
    }  
}

现在我们就可以在视图中使用 @inject 指令来调用那些方法:

@inject MVC6Demo.Models.Stats Stats  
  
@{  
    ViewBag.Title = "Stats";  
}  
  
<div>

这是不是很酷?

查看我关于 ASP.NET MVC 新指令详细例子的文章: Getting Started with ASP.NET MVC Core

Tag Helpers

ASP.NET MVC Core 另外一个非常酷的东西就是 Tag Helpers。对于之前的 HTML Helpers,Tag Helpers 是可选的替代语法。

所以相比于以下代码:

@using (Html.BeginForm("Login", "Account", FormMethod.Post, 
        new { @class = "form-horizontal", role = "form" }))
            {
                @Html.AntiForgeryToken()
                <h4>Use a local account to log in.</h4>
                <hr />
                @Html.ValidationSummary(true, "", new { @class = "text-danger" })
                <div class="form-group">
                    @Html.LabelFor(m => m.UserName, new { @class = "col-md-2 control-label" })
                    <div class="col-md-10">
                        @Html.TextBoxFor(m => m.UserName, new { @class = "form-control" })
                        @Html.ValidationMessageFor(m => m.UserName, "", new { @class = "text-danger" })
                    </div>
                </div>
}

你可以使用这些代码:

<form asp-controller="Account" asp-action="Login" method="post" class="form-horizontal" role="form">  
    <h4>Use a local account to log in.</h4>  
    <hr />  
    <div asp-validation-summary="ValidationSummary.ModelOnly" class="text-danger"></div>  
    <div class="form-group">  
        <label asp-for="UserName" class="col-md-2 control-label"></label>  
        <div class="col-md-10">  
            <input asp-for="UserName" class="col-md-2 control-label" />  
            <span asp-validation-for="UserName" class="text-danger"></span>  
        </div>  
    </div>  
</form>

ASP.NET Core 不止可以部署在IIS上

14年前,ASP.NET 平台基本只能部署在一种服务器上,那就是 IIS。几年之后,Visual Studio Development Web Server(也叫作“Cassini”)作为一种开发服务被使用,但是它们最终都是调用 System.Web 作为应用程序和 Web 服务器中间的主机层。System.Web 主机与 IIS 耦合度很高,所以要想运行在另一台主机上会非常困难。

后来 OWIN 作为应用程序和 Web 服务器中间的接口出现。 Microsoft 开发了 Katana 作为一个 OWIN 的实现,可以部署 ASP.NET Web API, SignalR 和其他第三方框架,这些框架可以在 IIS 和 IIS Express, Katana’s 自托管主机和自定义主机。

ASP.NET Core 是不强调主机的,它在 Katana 和 OWIN 上行为一致。ASP.NET Core 也可以部署在 IIS, IIS Express 或者自托管在你自己的进程里。另外,ASP.NET Core 也会包含一个叫做 Kestrel 的 Web 服务器,它建立在 libuv 上,主要用于 iOS 和 Linux 操作系统。

新的HTTP请求管道

ASP.NET Core 提供了一种更加模块化的 HTTP 请求管道, 你可以只添加你需要的组件。这个管道不再依赖 System.Web,通过降低管道中的开销,你的 app 性能更加优良,更好的调谐 HTTP 协议栈。新的管道基于 Katana 项目经验,同时支持 OWIN。

动态的Web开发

Visual Studio 2015 中另一个非常酷的特性就是支持动态编译。在过去的 ASP.NET 中,当我们修改了应用的后台代码,我们需要重新编译并且运行才能看到页面的变化。 在新版本的 Visual Studio 中,你不需要再做这些额外的步骤,仅仅是保存你的修改和刷新浏览器即可。

6

这是在刷新页面之后的输出:

7

Attribute Routing: [controller] 和 [action] 标记

在过去的 MVC 和 Web API 中,使用路由属性可能会导致一些问题,尤其是你正在做一些代码重构。这是因为路由必须设定为字符串类型,当你修改了控制器的名字,你就必须修改路由属性的字符串

MVC Core 提供了新的 [controller] 和 [action] 标记,它们可以解决这个问题。下面这篇文章重点说明了这些新标记的用法。 : ASP.NET MVC 6 Attribute Routing.

集成的依赖注入 (DI)

ASP.NET Core 内嵌了对依赖注入和 Service Locator 模式的支持,这意味着你不在需要通过第三方依赖注入框架 Ninject 或 AutoFac。

集成 Grunt, Gulp and Bower

Visual Studio 2015 内嵌了对流行开源 Web 开发工具的支持。 Grunt 和 Gulp 可以帮你自动化构建 Web 开发工作流, 你可以使用它们来编译和压缩 JavaScript 文件。Bower 是一个用于客户端库的管理工具,包含 CSS 和 JavaScript 库。

内置的AngularJs模板

AngularJs 是当前最流行的前端框架之一,用于构建单页面应用程序(SPAs)。Visual Studio 包含了用于创建 AngularJs 模块,控制器,指令和工厂。

8

对 GruntJS 的支持使得 ASP.NET 成为一个用于构建客户端 AngularJs 应用的优秀服务器端框架。 当完成一个版本,你可以自动合并和压缩全部 AngularJs 文件。查看我的关于开始在 ASP.NET 中使用 Angular 和 Angular2 的文章 。

· ASP.NET 5: Jump Start to AngularJS with MVC 6 Web API

· ASP.NET Core:Getting Started with AngularJS 2

SignalR 3

ASP.NET Core 也是以 SignalR 3 为基础,这使得你可以向云连接的应用程序添加实时功能。查看我之前的 SignalR 例子: ASP.Net SignalR: Building a Simple Real-Time Chat Application

Web.Config

在 ASP.NET Core 中,混乱的 web.config 文件被新的云就绪配置文件代替,它称作 “config.json”。微软希望开发人员更容易地在云中部署应用程序,并使得应用能够根据特殊环境自动的读取正确的配置参数。

这是一个新的配置文件的样子:

9

由于 ASP.NET Core 都是插件化的,你需要配置 Stratup 类的源代码,就像下面这样:

 public Startup(IHostingEnvironment env)
        {
            var builder = new ConfigurationBuilder()
                .SetBasePath(env.ContentRootPath);

            builder.AddEnvironmentVariables();
            Configuration = builder.Build();
        }
        public IConfigurationRoot Configuration { get; }
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddMvc();
            services.AddTransient<MVC6Demo.Models.HeroStats>();
        }

        public void Configure(IApplicationBuilder app)
        {
            app.UseDeveloperExceptionPage();


            app.UseMvc(m => {
                m.MapRoute(
                    name: "default",
                    template: "{controller}/{action}/{id?}",
                    defaults: new { controller = "Home", action="Index"});
            });
        }

xUnit.Net: .NET 新的单元测试工具

在之前的 ASP.NET MVC 中,默认的测试框架是 Visual Studio 单元测试框架(有时候也叫作mstest),这个框架使用 [TestClass] 和 [TestMethod] 特性来描述一个单元测试。

ASP.NET Core 使用 xUnit.net 作为它的单元测试框架。这个框架使用 [Fact] 特性来代替 [TestMethod] 特性,也消除了对 [TestClass] 属性的依赖。

绝对的免费和开源

是的,ASP.NET Core 被作为一个开源项目托管到 GitHub上, 你可以查看源代码,并下载并提交你的更改。

我认同开源的 .NET 会产生重大的意义,它产生了积极的商业意义和社区意义,十分感谢微软所做出的工作。

以上 ASP.NET Core 1.0 的新特性和新概念的介绍,是为了更好的帮助我们使用 ASP.NET Core 进行开发,同时在开发过程中,我们还可以借助一些好的工具来提高开发效率,并减少代码量,如 ComponentOne Studio for Asp.net MVC,它兼容 ASP.NET Core RC2 版本,是一款快速轻量级的控件来满足用户的所有需求。

 

文章来源:By Vincent Maverick Durano, 10 Jun 2016 

原文链接:http://www.codeproject.com/Articles/1104668/Introducing-ASP-NET-Core-The-New-ASP-NET-in-Town

葡萄城控件产品网站:http://www.gcpowertools.com.cn/
葡萄城企业软件网站:http://qy.grapecity.cn/
葡萄城技术支持论坛:http://gcdn.gcpowertools.com.cn/forum.php

58HouseSearch项目迁移到asp.net core

作者:李国宝
链接:https://zhuanlan.zhihu.com/p/22764927
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

前言

58HouseSearch这个项目原本是基于ASP.NET MVC 4写的,开发环境是Windows+VS2015,发布平台是linux+mono+jexus,这样看来整个项目基本已经满足跨平台的需求。

这样一来,本来我是没什么动力去做迁移的,好好的东西闲着没事干才迁移呢。

不过,这不国庆了么?穷人不是在家穷游天下么?所以…真的有点闲着没事干了。

迁移可行性探讨

项目迁移前,我们还是先来讨论一下迁移可行性。为嘛要进行可行性探讨呢?原因是.NET CORE是一个跨平台的框架,和上一代的.NET存在不兼容。

个人总结一下,迁移的主要的问题在于:代码不兼容、类库不兼容、严重依赖Windows API或者COM组件等。

代码不兼容

代码不兼容其实不算麻烦。毕竟代码是活的,你我也是活的,不就是一个改字罢了。花点时间慢慢改,总是能搞掂的。

类库不兼容

要不就弃用,要不就找替代品。

严重依赖Windows API或者COM组件

额?找替代品,找不到可用替代品的话。放弃吧,这个项目别考虑迁移了。

这个故事告诉我们,做跨平台项目的时候,少点用系统API或者组建。

回到58HouseSearch项目上面。

这个项目的代码基本都是我写的,所以重写代码没什么问题。
依赖的类库有下面几个:

AngleSharp是用来解析HTML的类库,用linq的方式来操作HTML,用起来实在爽快。

如果这货在.net core上不能跑,我应该立马放弃了。
不过,这个实在给力…


Newtonsoft.Json

在这个项目里面主要是用来记录PV数据的,非核心功能,可有可无。不过看了下nuget上的介绍,也是支持.net core的。

剩下log4net…嗯,并不支持log4net。不过这个就更加是非核心内容了,直接丢了。
PS:考虑后期加入Nlog替代log4net。

至于依赖Windows API之类的,在这个项目里面基本没有,所以略过…

准备工作

友情提示:

  1. Visual Studio Community 2015 with Update 3 下载镜像来安装。

错误操作如下:


正确打开方式:

  1. 安装.NET Core SDK和.NET Core之后再安装.NET Core 1.0.1 – VS 2015 Tooling Preview 2
  2. 安装.NET Core 1.0.1 – VS 2015 Tooling Preview 2 这货的可能会报错0x80072f8a未指定的错误

解决方案见下图:


详细见链接:安装DotNetCore.1.0.1-VS2015Tools.Preview2.0.2出现0x80072f8a未指定的错误

上面都弄好之后,理论上在VS2O15-新建项目里面可以看到ASP.NET CORE的模板了。

如下图:

项目迁移

新建空白ASP.NET CORE项目

新建好了之后如下图:

Nuget获取引用

NuGet Gallery

NuGet Gallery

添加Controllers文件夹

然后把之前项目的Controllers拷贝过来,改掉命名空间,去掉无用代码,添加相应引用。

添加Views文件夹

本项目直接把之前项目的Views拷贝过来是完全没有问题的。

静态文件处理

asp.net core MVC中的文件结构和asp.net mvc的文件结构略有不同。

asp.net core MVC在view中“IMG/Little/PaleGreen.png”对应的文件对应于“项目路径/webroot/IMG/Little/PaleGreen.png”;

asp.net mvc中,对应路径为“项目/IMG/Little/PaleGreen.png”。

因而,我们的所有静态文件都应该放到:webroot文件夹下。

上面的都做完了之后,项目结构如下:


接下来就是改代码了。

代码迁移

Startup.cs添加MVC1

public class Startup
{
    // This method gets called by the runtime. Use this method to add services to the container.
    // For more information on how to configure your application, visit http://go.microsoft.com/fwlink/?LinkID=398940
    public void ConfigureServices(IServiceCollection services)
    {
        //添加MVC框架
        services.AddMvc();

    }

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    public void Configure(IApplicationBuilder app, IHostingEnvironment env,
    ILoggerFactory loggerFactory)
    {
        loggerFactory.AddConsole();

        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        //启用静态文件中间件
        app.UseStaticFiles();
        //启动MVC路由
        app.UseMvcWithDefaultRoute();
        //设置默认页面
        app.UseMvc(routes =>
        {
            routes.MapRoute(
                name: "default",
                template: "{controller=House}/{action=Index}/{id?}"); 
        });


    }
}

改写GetHTMLByURL方法

之前的方法:


.net core重写了HttpWebRequest,变成了WebRequest,所以上面的代码废了。

重写如下:

public static string GetHTMLByURL(string Url, string type = "UTF-8")
{
    try
    {
        Url = Url.ToLower();

        System.Net.WebRequest wReq = System.Net.WebRequest.Create(Url);
        // Get the response instance.
        System.Net.WebResponse wResp = wReq.GetResponseAsync().Result;
        System.IO.Stream respStream = wResp.GetResponseStream();
        using (System.IO.StreamReader reader = new System.IO.
        StreamReader(respStream, Encoding.GetEncoding(type)))
        {
            return reader.ReadToEnd();
        }
    }
    catch (System.Exception ex)
    {

        return string.Empty;
    }

}

改写Controller代码

嗯,换了命名空间,别的一句都没改直接拉过来了…略过。

发布到ubuntu

Install for Ubuntu 14.04, 16.04 & Linux Mint 17

第一步

//Ubuntu 14.04 / Linux Mint 17
sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ trusty main" > /etc/apt/sources.list.d/dotnetdev.list'
sudo apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893
sudo apt-get update


//Ubuntu 16.04
sudo sh -c 'echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet-release/ xenial main" > /etc/apt/sources.list.d/dotnetdev.list'
sudo apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893
sudo apt-get update

第二步

sudo apt-get install dotnet-dev-1.0.0-preview2-003131

安装好了之后,输入 dotnet -v 应该能看到版本信息,如下图:


这样的下,一句完成了ubuntu 运行asp.net core的环境搭建了。

project.json里面隐藏的坑

dependencies

NET Core 1.0.1 – VS 2015 Tooling Preview 2模板的asp.net core 版本和ubuntu 的asp.net core 版本不一致。

根据微软爸给的教程,我们在ubuntu上安装的.NET Core 1.0.0,见上图。

然而我们创建项目的模板是.NET Core 1.0.1,见下图:


怎么办?要不升级ubuntu的asp.net core,要不降级。

由于没找到.NET Core 1.0.1 ubuntu的安装包,所以我选择了降级到.NET Core 1.0.0.

其中需要把Microsoft.NETCore.App version 、Microsoft.AspNetCore.Server.Kestrel、Microsoft.AspNetCore.Mvc 这三个节点都改成“1.0.0”。如下:

"dependencies": {
  "Microsoft.NETCore.App": {
    "version": "1.0.1",
    "type": "platform"
  },
  "Microsoft.AspNetCore.Diagnostics": "1.0.0",
  "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
  "Microsoft.AspNetCore.Server.Kestrel": "1.0.1",
  "Microsoft.Extensions.Logging.Console": "1.0.0",
  "Microsoft.AspNetCore.Mvc": "1.0.1",
  "Microsoft.AspNetCore.StaticFiles": "1.0.0",
  "Newtonsoft.Json": "9.0.1",
  "AngleSharp": "0.9.8.1"
},

publishOptions

发布输出包括Views文件夹

"publishOptions": {
  "include": [
    "wwwroot",
    "web.config",
    "Views"
  ]
},

runtimes

runtimes 配置为模板运行平台。
详细见链接:Project.Json

"runtimes": { "ubuntu.14.04-x64": {} }

上面都弄好之后,跑一下看

dotnet restore

dotnet run

来个请求看看:

jexus转发/反向代理

ASP.NET Core “完整发布,自带运行时” 到jexus

Mac 软件推荐(续)之程序猿篇

在前面一篇文章“Mac 软件推荐续(!程序猿篇)” (文章取名装X失败, 悲伤)中, 我已经介绍了一些大众化的软件, 当然作为程序猿的你也应该参考参考.
本篇文章将介绍一些可以提高程序猿工作效率的一些软件和工具及相关配置.

Mac built-in

首先介绍的就是我觉得应该熟悉 Mac 内置的一些软件及配置.

trackpad 配置

  1. 启用 Tap to click: 在 System Preferences -> Trackpad 中启用, 用 tap 替换 click 的操作, 明明轻轻 tap 就可以完成的, 为何还要用力点击才 OK. 现在偶尔用其他人电脑非得用力 click 就太纠结了.
    同时, 还有 “右键”功能, Secondary click, 用两个手指 tap 弹出右键菜单.
    mac trackpad 设置
  2. 开启单词选词查询:
    选中某个中英文单词后, 三指 tab 会弹出词典释义. 这个在之前一篇文章中也有介绍.
  3. Scroll 方向: 这个道是自己习惯就好. 由于我刚开始从 Win 转向 Mac 的时候习惯用 Win 的那种方式, 于是就没有开启 Scroll direction: natural, 然后也一直沿用至今.
  4. 其他手势: 有必要熟悉一下, 比如知道在 Win 环境下用 win+d 可以显示桌面, 相应的功能在 Mac 下如何做.

快捷键

作为程序猿, 肯定离不开各种快捷键. 对于 Mac 内置的一些快捷键, 我们还是很有必要知道的. 基本的复制/粘贴就不说了, 常用的还有

空格键: 预览
cmd + ,: 设置
cmd + -/=: 缩小/放大
ctrl + u: 删除到行首(与zsh冲突, zsh中是删除整行)
ctrl + k: 删除到行尾
ctrl + p/n: 上/下移动一行或者前/后一个命令
ctrl + b/f: 光标前/后移char
esc + b/f: 光标前/后移word(蛋疼不能连续work)
ctrl + a/e: 到行首/行尾
ctrl + h/d: 删前/后字符
ctrl + y: 粘贴
ctrl + w: 删除前一个单词
esc + d: 删后一个单词
ctrl + _: undo
ctrl + r: bck-i-search/reverse-i-search, 输入关键字搜索历史命令

上面的这些快捷键特别是在敲命令时还是很有用的(可能有的确实是在命令行中才生效), 特别是结合 zsh 自动补全等功能. 比较 DT 的是就是 esc 一起用的时候, 不能连续使用. 举个例子, terminal 中输入了 git push origin source, 光标在末尾, 这时按住ctrl 不放, 按一下 w 即向前删除一个单词, 第一次按 w 删除 source, 再按 w 删除 origin. 而 esc + d 不能这样结合使用(如下 gif连续按就不 work), esc 必须中途释放再按才能 work.

bash自动补全

啥? 你说上面快捷键 ctrl + w 等不太好按? 按键特别别扭?
你需要做的就是将 caps lock 映射为 ctrl, Keyboard -> Modifier Keys修改, 目前我笔记本上的 ctrl 键无效. 不过, 一般情况下我用我的 HHKB, 这种映射方式正好符合 HHKB 的布局. (其实我是在买 HHKB 之前就修改的这个映射)

另外, 借助之前介绍的Karabiner, 可以将一些常用的方向键(上下左右)重新映射一下, 比如我目前是 s + h/j/k/l 来表示方向, 手不用太移动就能直接按方向(HHKB 本身按方向太麻烦, Mac 内置键盘有方向键还需要大幅度移动手), 用起来方便多了.

Mac 内置的更多的快捷键列表可以参考 Mac 官网

其他还有一些常用的软件的快捷键, 可以用之前介绍的软件 cheetsheet, 长按 cmd, 可弹出当前 active 的软件的快捷键.

截图

这个从快捷键中单独列出来了, 就强调下这个功能.

cmd + shift + 3 截取整个屏幕.
cmd + shift + 4 部分窗口, 出现十字供选取, 若此时按空格键(这个技能得点赞), 会选取当前应用的窗口, 再 tap 即可完成截图.

上面快捷键是截图后以文件形式保存在桌面(默认是桌面, 当然你也可以自己修改保存位置), 再上面快捷键基础上再同时按 ctrl 就会把图片保存在内存/剪贴板中, 直接去相应窗口粘贴即可.

home brew

类似 centos 的 yum, ubuntu 的 apt-get, 能够方便管理安装软件包.
Mac 上类似的应用还有port, 我刚开始试用过 port, 貌似 brew 上的源会多一些.
brew-cask 是 brew 的一个加强版, 可以安装一些桌面应用, 例如 chrome 等等之类的.

这里就不多介绍了, 详情可以到官网查看.
brew
brew-cask

iTerm2

iTerm2官网有介绍功能. 以下是觉得可能常用的功能.

  1. 分屏功能
    • cmd + d 竖着分屏, cmd + shift + d 横着分屏
    • cmd + t 新建一个 tab, cmd + num 切换到第 num 个 tab
    • 当前窗口含有分屏时, 通过 cmd + [cmd + ] 来进行切换小的分屏
  2. 热键 设置一个热键, 比如我的是 alt + 空格, 弹出 iTerm2, 且以半透明的方式显示在当前 active 的窗口上面.
    iTerm2 hotkey
  3. 搜索
    • cmd + f搜索输入关键字后, 匹配的会黄色高亮, 此时按 tab 或者 shift + tab 会自动向后/前以word 的方式选中高亮的, 并自动 copy 到剪切板.
    • cmd + alt + e, 在所有的 tab 中全局搜索, 搜索出候选项后, 再选着你想要进入的 tab.

iTerm2 search

  1. 其他
    • 新版本的 iTerm2 还支持直接在控制台里 ls 图片文件(图片显示在控制台里).(如上图下半部分, 连 gif 都支持)
    • 自动识别控制台里的内容, 如含有链接或者本地文件路径可以用 cmd 加点击的方式直接打开链接或者文件(如下图上半部分). 这个功能很重要呢, 比如在编译过程中, 出现了 warning 或者 error, 一般会打印出具体文件路径, 此时直接从控制台就能打开文件进行 fix 了.
    • 自动补全, iTerm2 本身是支持自动补全的(cmd + ;), 不过建议直接结合后面的zsh使用. cmd + shift + h 剪贴板历史(下图最后一行).
    • 一些高级的功能目前可能处于测试版本, 你若用的稳定版是不支持的, 需要到官网下测试版. 还有更多的功能请到 iTerm2 官网探索吧.

iTerm2 imgcat

zsh

这个墙裂推荐啊. 结合 oh my zsh, 丰富的插件资源.

语法高亮, 自动补全等特别好, 在此推荐的几个插件或功能.

  1. git: 当前目录若是在一个 git repo 下面的话, 会自动显示当前的分支信息等等. 然后可以自己搞一些 alias, 简写命令, 比如我常用的一些.
alias gs=’git status’
alias gb=’git branch -va’
alias gco=’git checkout’
alias ga=’git add’
alias gc=’git commit -m’
alias gp=’git push’
alias gfom=’git fetch origin master’
alias gfod=’git fetch origin develop’
alias grod=’git rebase origin/develop’
alias grom=’git rebase origin/master’
  1. autojump: 这个也炒鸡赞. 会自动记录你 cd 过的目录, 下次你直接 j keyword 就会自动 cd 到以 keyword 匹配的目录. 输入 d会展示当前会话访问过的目录, 然后对应目录有标号, 接下来按标号即可跳转.
  2. osx: 举个最简单的例子, 比如你现在正在 finder 中浏览一个很深的目录, 现在突然想 cd 到这个目录去做一些命令操作. 如果你用xtrafinder 这样的软件的话道有这样的功能, 如果配上这个插件, 你直接输入 cdf (cd finder)就自动 cd 到 finder 打开的目录下.
  3. zsh-autosuggestions, 如下图所示, 我在 app-in-mac 这个目录下, 刚输入了 git, 此时光标还在 p 前面, zsh 就已经自动给我补全了 git push origin source, 此时我只要按 ctrl + e 跳转到行尾(所以熟悉上文中的快捷键很有必要啊), 回车即可执行命令了.

iTerm2 zsh plugins

更多的, 还是请到官网查看.

sublime text

文本编辑器, 也有丰富的插件支持, 直接官网看吧. 这个 App, 我用得也不是很多.

这里分享一个小的功能, 怎么在命令行用 sublime 打开特定的文件. 其实就是添加一个软链即可. (直接 open filename 会以文件默认关键的软件打开)

➜ app-in-mac git:(source) ✗ subl dungeon-game.cpp
➜ app-in-mac git:(source) ✗ which subl
/usr/local/bin/subl
➜ app-in-mac git:(source) ✗ ls -la /usr/local/bin/subl
lrwxr-xr-x 1 tanglei admin 62 1 24 2016 /usr/local/bin/subl -> /Applications/Sublime Text.app/Contents/SharedSupport/bin/subl

Vim

介绍 Vim 的文章也很多了. 这里就不详细展开了. 分享下我用的部分插件. (最近被 IntelliJ IDEA 搞得恶心了, 准备尝试抛弃),
为了让多台电脑同步我的 vim 配置/插件等, 我直接放 github 了(ref vimconfigs), 不同电脑只需要再建一个软链到github 中的 vimrc 即可.

vim 自动补全

  • Vundle/Pathogen: 插件管理, 我用的Pathogen, 直接将下面 github repo clone 到 ~/.vim/bundle/ 目录下即可
  • NERDTree: 文件目录树nerdtree github src
  • YouCompleteMe: YouCompleteMe github src 自动补全, 对C系列, 结合其他的可支持 Java/Python/Js 等, 跪求 Scala 支持
  • ctrlp.vim: 快速搜索文件
  • minibufexpl.vim: 会把最近打开的文件列出来方便跳转, github src
  • conque-term: shell 跑在 vim 里面, github src
  • ag: 代码搜索, 可结合 ctrlp.vim, 如果后者搜索太慢的话, github src
  • tagbar/taglist: 标签, 能显示类结构信息等, tagbar github src
  • vim-surround: 处理诸如(), "", [] 等配对信息, github src, ref
  • vim-easymotion: 快速跳转, 关键字后会给匹配到的标记, 再选标记并跳转(类似后文介绍 Chrome 插件的Vimium中的链接标记并跳转功能:按键 f 会将本文所有链接突出显示并用字母标记, 然后按相应的字母则会新开标签页打开). github src, ref
  • vim-powerline: 增强状态栏 github src
  • vim-indent-guides: 缩进可视化, github src

具体效果等配置方法可以参考下面的两篇文章, 插件具体用法可阅读具体插件的 doc.

Reference

Dash

其实介绍前文 介绍 Alfred 已经提到过, 这里再介绍一下. 程序猿应该必备啊. 内置各种语言, 各种环境的各种文档. 该 App 还提供各种 API 供其他工具交互使用. 例如 Vim(不是想象当中自动补全功能, 只是能够快捷地搜索 API), Sublime 等. (p.s 要是有人写了一个 Vim 插件, 能够支持调用 dash 的 API(如果有的话) 自动补全代码, 那应该会很受欢迎的)

dash

其他App

chrome

插件

  • AdBlock: 广告屏蔽;
  • EditThisCookie: 修改 cookie;
  • Evernote Web Clipper: 印象笔记;
  • JSONView and JSONLint for Google Chrome™: 请求返回的json进行beautify方便查看;
  • Markdown Here: 在富文本输入markdown, 渲染成 html;
  • Markdown Preview Plus: 渲染 .md 文件, 相当于 preview markdown;
  • Open Screenshot: 网页截图, 能够自动下拉截长图;
  • Postman: 请求伪造/抓包等, 也可以用curl;
  • Proxy SwitchySharp: proxy 切换;
  • RescueTime: 前文有介绍的RescueTime;
  • undirect: google/baidu 搜索结果, 点击直达网站, 这个貌似不太好用了. 征求替代品;
  • Vimium: 操作 vim 一样操作浏览器, 移动查找等功能, 还有前文提到的快速标记链接并跳转;

Charles

类 Windows 下 Fiddler 抓包应用.

相关命令 tcpdump

其他有用的命令行

一些好用的命令(基本的什么ls/cd/cp/rm之类的这里就直接忽略了), 我觉得作为程序猿还是应该了解, 至少只当某个场景下直接用相应的命令就能解决. 具体参数可以再 --help 或者 man commond 再看.

  • screen: 特别是 ssh 到登录远程时用以管理会话
  • curl: 网络请求, 相关的还有 traceroute, dig
  • find: 文件查找
  • grep/zgrep/zcat: 查看日志的时候用
  • awk: 这个本身就很强大了, 具体编程语法不用太掌握但可以了解一些基本的用法, 比如之前用到过给一个log文件, 能够取里面的参数拼接update 的sql(文件里有相应 update 的值和 where 条件值)
  • sed: 文本替换, 还有 tr, 注意 sed 的语法 Mac 和 一般 Linux 还有些不一样( 比如原文替换的时候 mac 里需要用参数 -i ""), 比如之前迁移 wordpress 到 jekyll 上的时候需要将一些链接整体替换成新的路径.
  • cut: 按列取数据, awk 也可以
  • sort: 这个就不多说了
  • uniq: 一般和 sort 一块用, 只能去重相邻的行
  • diff: 比较文件, 类似的还有 comm (输出3列, 分别是: 只在文件1, 只在文件2 和两个文件都在的行)
  • paste: 两个文件按列拼接
  • od: 以16/8/2进制查看文件
  • wc: 统计文件字节数/字数/行数

结合这些命令可能就能完成某些复杂的功能, 举个例子, 如线上的web 访问日志会记录 请求时间, 请求路径, 参数 等等. 现在需要统计 当天请求路径为 A, 排名前10的参数, 就可以 grep 路径A | cut 取出想要的数据列 | sort | uniq 之类的, 或者比如统计http 404 请求最多的10个路径. 再比如, 随机生成3个长度为8包含字母数字的字符串(偶尔会用到, 比如各种生产 secret key 的时候), 直接用如下命令即可

➜ _includes git:(source) ✗ cat /dev/urandom | sed ‘s/[^a-zA-Z0-9]//g’ | head -n 3 | cut -c 1-8
MaL6nEmZ
00m2Ub19
rsc4AOQm

其他的可能较少用, 但一旦用, 能省不少时间. 网上也有一些 online 的工具, 但哪有这个快准狠.

  • openssl sha1/aes-256-ecb/des/base64 等等: 比如当前我们开发用的 MVC 框架play framework用来加密 session 的算法, 可以方便算出 encoded 的 sessionid 进行 debug.
  • md5/base64: 常见的 md5, base64 编码
  • sips: scriptable image processing system 比如批量处理图片大小, 压缩等等

全文完, 关于 Mac 使用技巧和工具软件推荐, 一共如下3篇文章:

p.s 如果你觉得这文章对你有那么一点点收获, 请不要犹豫扫描下面二维码关注我的公众号, 如果你再能帮忙转发一下就更好了. 么么哒.