一切福田,不離方寸,從心而覓,感無不通。

Category Archives: Backend

静态资源缓存控制编译工具

前不久在 知乎 上回答了一个问题:大公司里怎样开发和部署前端代码?。其中讲到了大公司在前端静态资源部署上的一些要求: 配置超长时间的本地缓存 —— 节省带宽,提高性能 采用内容摘要作为缓存更新依据 —— 精确的缓存控制 静态资源CDN部署 —— 优化网络请求 更资源发布路径实现非覆盖式发布 —— 平滑升级 其中比较复杂的部分就是 以文件的摘要信息为依据,控制缓存更新与非覆盖式发布 这个细节。因此基于 fis 包装了一个简单的命令行工具,并设立此项目,用于演示这部分功能。 这个工具基于 fis 的小工具是完全可以用作工程中的,有任何问题可以在 这里 留言。 请跟着下面的步骤来使用这个命令行小工具: 第一步:安装工具 这个命令行小工具依赖 nodejs 环境,因此,请先确保本地安装了它。 使用 nodejs 随带的 npm 包管理工具进行安装:

第二步:创建项目 在 命令行 下clone本仓库,或者自己创建一个新的项目,并进入:

在项目根目录下创建一个空的 fis-conf.js 文件,这是工具配置,什么都不用写,空着就行。 然后开始在项目目录下,随意创建或添加 页面、脚本、样式、图片、字体、音频、视频等等前端资源文件,正常写前端代码吧! 第三步:发布代码 在项目根目录下执行:

然后去到 ../output 目录下去查看一下产出结果吧,所有静态资源都以md5摘要形式发布了出来,所有资源链接,我说 所有链接,包括html中的图片、样式、脚本以及js中的资源地址、css中的资源地址全部都加上了md5戳。 上述命令中,--md5 就是表示要给所有资源定位标记加上摘要信息的意思,不加这个参数就没有摘要信息处理。--dest ../output 表示把代码发布到当前目录上一级的output目录中。整个这条命令还可以简写成:

或者进一步连写成:

在本地服务器中浏览发布代码 你本地安装了诸如 Apache、Nginx、Lighttpd、IIS等服务器么?如果安装了,假设你的服务器 根目录 在 d:\wwwroot,你可以利用rsd工具的release命令,把代码发布过去,比如:

这样就把代码发布到了本地服务器根目录下,然后就可以在浏览器中查看效果了! 如果你本地没有安装任何服务器,你可以使用rsd内置的调试服务器,执行命令:

接下来我们同样要把代码发布到这个内置服务器中,release命令如果省略 --dest <path>参数,就表示把代码发布到内置服务器的根目录下:

在浏览器中访问: http://localhost:8080 即可   一些小技巧 rsd集成了对很多前端编程语言的支持,包括: 类CSS语言:less, sass, scss, stylus 类JS语言:coffee-script 类HTML语言:markdown, jade 前端模板:handlebars-v1.3.0, EJS 内置了压缩器,在release的时候追加 -o 或者 --optimize 参数即可开启,压缩器包括: clean-css: 压缩所有类CSS语言代码 uglify-js: 压缩所有类JS语言代码 html-minifier: 压缩所有类HTML语言代码 还可以给资源加CDN域名,在release的时候追加 -D 或者 --domains 参数即可,域名配置写在fis-conf.js里:

所有常规代码中的资源定位接口都会经过工具处理,包括: 类CSS文件中: 背景图url font-face字体url ie特有的滤镜属性中的src 类JS文件中: 提供了一个叫 __uri('path/to/file') 的编译函数用于定位资源 类HTML文件中: link标签的href属性 script, img, video, audio, object 等标签的src属性 script标签中js代码里的资源定位标记 style标签中css代码里的资源定位标记 所有资源文件可以任意相互引用,工具会处理资源定位标记,使之服从知乎回答中提到的优化策略。 还提供了资源内嵌的编译接口,用于把一个资源的内容以文本、字符串或者base64的形式嵌入到 任意 一个文本文件中。 为了不用每次保存代码就执行一下release命令,工具中提供了文件监听和浏览器自动刷新功能,只要在release的时候在追加上 -w 和 -L 两个参数即可(注意L的大小写),比如:

关于这个小工具 它的原码在 这里。是的,就这么一点点代码,花了大概半小时写完的,因为一切都在 fis 中集成好了,我只是追加几个语言编译插件而已。   from:https://github.com/fouber/static-resource-digest-project

龙生   19 Oct 2018
View Details

C#中HttpClient使用注意:预热与长连接

原文地址:C#中HttpClient使用注意:预热与长连接 最近在测试一个第三方API,准备集成在我们的网站应用中。API的调用使用的是.NET中的HttpClient,由于这个API会在关键业务中用到,对调用API的整体响应速度有严格要求,所以对HttpClient有了格外的关注。 开始测试的时候,只在客户端通过HttpClient用PostAsync发了一个http post请求。测试时发现,从创建HttpClient实例,到发出请求,到读取到服务器的响应数据总耗时在2s左右,而且多次测试都是这样。2s的响应速度当然是无法让人接受的,我们希望至少控制在100ms以内。于是开始追查这个问题的原因。 在API的返回数据中包含了该请求在服务端执行的耗时,这个耗时都在20ms以内,问题与服务端API无关。于是把怀疑点放到了网络延迟上,但ping服务器的响应时间都在10ms左右,网络延迟的可能性也不大。 当我们正准备换一个网络环境进行测试时,突然想到,我们的测试方式有些问题。我们只通过HttpClient发了一个PostAsync请求,假如HttpClient在第一次调用时存在某种预热机制(比如在EF中就有这样的机制),现在2s的总耗时可能大多消耗在HttpClient的预热上。 于是修改测试代码,将调用由1次改为100次,然后恍然大悟地发现——只有第1次是2s,接下来的99次都在100ms以内。果然是HttpClient的某种预热机制在搞鬼! 既然知道了是HttpClient预热机制的原因,那我们可以帮HttpClient进行热身,减少第一次请求的耗时。我们尝试了一种预热方式,在正式发http post请求之前,先发一个http head请求,代码如下:

经测试,通过这种热身方法,可以将第一次请求的耗时由2s左右降到1s以内(测试结果是700多ms)。 在知道第1次HttpClient请求耗时2s的真相之后,我们将目光转向了剩下的99次耗时100ms以内的请求,发现绝大部分请求都在50ms以上。有没有可能将之降至50ms以下?而且,之前一直有这样的纠结:每次调用是不是一定要对HttpClient进行Dispose()?是不是要将HttpClient单例或者静态化(声明为静态变量)?借此机会一起研究一下。 在HttpClient的背后,有一个对请求响应速度有着不容忽视影响的东东——TCP连接。一个HttpClient实例会关联一个TCP连接,在对HttpClient进行Dispose时,会关闭TCP连接(我们用Wireshark进行网络抓包也验证了这一点)。 在之前的测试中,我们每次用HttpClient发请求时,都是新建一个HttpClient实例,用完就对它进行Dispose,代码如下:

所以每次请求时都要经历新建TCP连接->传数据->关闭连接(也就是通常所说的短连接),而且雪上加霜的是请求用的是https,建立TCP连接时还需要一个基于公私钥加解密的key exchange过程:Client Hello -> Server Hello -> Certificate -> Client Key Exchange -> New Session Ticket。 如果我们想将请求响应时间降至50ms以下,就必须从这个地方下手——重用TCP连接(也就是通常所说的长连接)。要实现长连接,首先需要的就是在HttpClient第1次请求后不关闭TCP连接(不调用Dispose方法);而要让后续的请求继续使用这个未关闭的TCP连接,我们必须要使用同一个HttpClient实例;而要使用同一个HttpClient实例,就得实现HttpClient的单例或者静态化。之前的3 个问题,由于要解决第1个问题,后2个问题变成了别无选择。 为了实现长连接,我们将HttpClient的调用代码改为如下的样子:

然后测试一下请求响应时间:

除了第1次请求,接下来的99次请求绝大多数都在50ms以内。TCP长连接的效果必须的! 通过Wireshak抓包也验证了长连接的效果: 这时,你也许会产生这样的疑问:将HttpClient声明为静态变量,会不会存在线程安全问题?我们当时也有这样的疑问,后来在stackoverflow上找到了答案:

HttpClient的所有异步方法都是线程安全的,放心使用。 到这里,HttpClient的问题是不是可以完美收官了?。。。稍等,还有一个问题。 客户端虽然保持着TCP连接,但TCP连接是两口子的事,服务器端呢?你不告诉服务器,服务器怎么知道你要一直保持TCP连接呢?对于客户端,保持TCP连接的开销不大;但是对于服务器,则完全不一样的,如果默认都保持TCP连接,那可是要保持成千上万客户端的连接啊。所以,一般的Web服务器都会根据客户端的诉求来决定是否保持TCP连接,这就是keep-alive存在的理由。 所以,我们还要给HttpClient增加一个Connection:keep-alive的请求头,代码如下:

现在终于可以收官了。但是肯定不完美,分享的只是解决问题的过程。   from:https://www.cnblogs.com/JustYong/p/5872296.html

龙生   07 Oct 2018
View Details

Github 修正上传时“this exceeds GitHub’s file size limit of 100 MB”错误

Github只允许上传最大100MB的文件,如果超过,则会被server reject 则需: git filter-branch --force --index-filter "git rm --cached --ignore-unmatch FILEPATH"  --prune-empty --tag-name-filter VERSION — --all git commit --amend -CHEAD git push origin master 注意要在.git文件夹目录下执行以上命令 http://www.walbrix.com/jp/blog/2013-10-github-large-files.html from:https://blog.csdn.net/fightforyourdream/article/details/25357121

龙生   07 Oct 2018
View Details

C# HttpClient请求

  from:https://www.cnblogs.com/louby/p/8021527.html

龙生   07 Oct 2018
View Details

c# Http请求之HttpClient

利用HttpClient进行Http请求,基于此,简单地封装了下:

有关更多的Http请求,请看这里:https://github.com/wangqiang3311/HttpRequestDemo from:http://www.cnblogs.com/wangqiang3311/p/8991214.html

龙生   07 Oct 2018
View Details

C# 中使用System.Net.Http.HttpClient 模拟登录博客园 (GET/POST)

一、 System.Net.Http.HttpClient简介 System.Net.Http 是微软.net4.5中推出的HTTP 应用程序的编程接口, 微软称之为“现代化的 HTTP 编程接口”, 主要提供如下内容: 1. 用户通过 HTTP 使用现代化的 Web Service 的客户端组件; 2. 能够同时在客户端与服务端同时使用的 HTTP 组件(比如处理 HTTP 标头和消息), 为客户端和服务端提供一致的编程模型。 个人看来是抄袭apache http client ,目前网上用的人好像不多,个人认为使用httpclient最大的好处是:不用自己管理cookie,只要负责写好请求即可。 由于网上资料不多,这里借登录博客园网站做个简单的总结其get和post请求的用法。 查看微软的api可以发现其属性方法:http://msdn.microsoft.com/zh-cn/library/system.net.http.httpclient.aspx 由其api可以看出如果想设置请求头只需要在DefaultRequestHeaders里进行设置 创建httpcliet可以直接new HttpClient() 发送请求可以按发送方式分别调用其方法,如get调用GetAsync(Uri),post调用PostAsync(Uri, HttpContent),其它依此类推。。。 二、实例(模拟post登录博客园) 首先,需要说明的是,本实例环境是win7 64位+vs 2013+ .net 4.5框架。 1.使用vs2013新建一个控制台程序,或者窗体程序,如下图所示: 2.必须引入System.Net.Http框架,否则将不能使用httpclient 3.实现代码

代码分析: 首先,从Main函数开始,调用LoginCnblogs方法; 其次,使用GET方法:

再者,使用POST方法:

最后,注意其返回值可以是string,也可以是byte[],和stream的方式,这里看你需要什么吧。   4.登录成功后的截图 1).使用浏览器登录后的截图: 2).使用Httpcliet登录后的截图:   总结,可以发现C#中HttpClient的用法和Java中非常相似,所以,说其抄袭确实不为过。   from:https://www.cnblogs.com/amosli/p/3918538.html

龙生   07 Oct 2018
View Details

C# HttpClient设置cookies的两种办法 (转发)

一般有两种办法 第一种handler.UseCookies=true(默认为true),默认的会自己带上cookies,例如

这种情况post请求登陆成功后,重定向到别的页面,也会自动带上cookies。如果把handler.UseCookies设置为false,登陆后重定向的话不会自动带上cookies,则又会跳转到登陆页面。   第二种设置 handler.UseCookies = false时,则需要手动给headers上加入cookies.

如果使用场景是:抓取需要登陆后才能看到的网页数据,建议使用第一种,不需要设置任何cookies,httpclient会自动把登陆后的cookies放置到后面的请求中。   原贴 : http://www.cnblogs.com/xiaozhu39505/p/8033108.html from:https://www.cnblogs.com/refuge/p/8060142.html

龙生   07 Oct 2018
View Details

重启IIS某个站点脚本

修改siteName为需要的重启的网站名字,将代码拷入bat文件 @echo off cd  c:\Windows\System32\inetsrv appcmd stop  site  "siteName" appcmd start  site  "siteName"   from:https://blog.csdn.net/a980433875/article/details/52088252

龙生   07 Oct 2018
View Details

Redis 避不开的五种数据结构

Redis 中有 5 种数据结构,分别是字符串(String)、哈希(Hash)、列表(List)、集合(Set)和有序集合(Sorted Set),因为使用 Redis 场景的开发中肯定是无法避开这些基础结构的,所以熟练掌握它们也就成了一项必不可少的能力。本文章精要地介绍了 Redis 的这几种数据结构,主要覆盖了它们各自的定义、基本用法与相关要点。 字符串类型 字符串是 Redis 中的最基础的数据结构,我们保存到 Redis 中的 key,也就是键,就是字符串结构的。除此之外,Redis 中其它数据结构也是在字符串的基础上设计的,可见字符串结构对于 Redis 是多么重要。 Redis 中的字符串结构可以保存多种数据类型,如:简单的字符串、JSON、XML、二进制等,但有一点要特别注意:在 Redis 中字符串类型的值最大只能保存 512 MB。 命令 下面通过命令了解一下对字符串类型的操作: 1.设置值

set 命令有几个非必须的选项,下面我们看一下它们的具体说明: EX seconds:为键设置秒级过期时间 PX milliseconds:为键设置毫秒级过期时间 NX:键必须不存在,才可以设置成功,用于添加 XX:键必须存在,才可以设置成功,用于更新 set 命令带上可选参数 NX 和 XX 在实际开发中的作用与 setnx 和 setxx 命令相同。我们知道 setnx 命令只有当 key 不存在的时候才能设置成功,换句话说,也就是同一个 key 在执行 setnx 命令时,只能成功一次,并且由于 Redis 的单线程命令处理机制,即使多个客户端同时执行 setnx 命令,也只有一个客户端执行成功。所以,基于 setnx 这种特性,setnx 命令可以作为分布式锁的一种解决方案。 而 setxx 命令则可以在安全性比较高的场景中使用,因为 set 命令执行时,会执行覆盖的操作,而 setxx 在更新 key 时可以确保该 key 已经存在了,所以为了保证 key 中数据类型的正确性,可以使用 setxx 命令。 2.获取值

3.批量设置值

4.批量获取值

如果有些键不存在,那么它的值将为 nil,也就是空,并且返回结果的顺序与传入时相同。 5.计数

incr 命令用于对值做自增操作,返回的结果分为 […]

龙生   26 Sep 2018
View Details

记聊天服务宕机事件

9月23日,农历8月14,中秋假期。 上午9点,领导微信语音通话说聊天服务挂了。 然后打开网站,果然挂了。 看异常日志,提示程序错误。 然后,果断回滚到上一个版本,还是错误。 然后,再恢复了前一个版本,依然不行。 连接到公司办公环境…… 那只有分析异常日志了,可异常日志记录的堆栈信息只是说那个方法错误,没有具体的信息。 果断去掉异常捕捉try-catch,编译,上线。 服务器日志有错误,已经具体到底层方法和行数了,是log4net写日志错误。 然后恢复日志模块以前的版本,不行,依然写日志错误。 没办法,动手修改这个方法,上传。 这次写日志没错了。 再看操作系统日志,这次提示redis连接对象错误,然后怀疑redis连不上了。 由于是新服务器,没有安装redis客户端;然后下载RedisDesktopManager,从国外站点下载10MB真不容易,30KB/s;然后想把办公电脑的安装程序传到服务器上,总是断开(可能公司的路由器太垃圾);试了几次不行。然后就用winrar压缩成多个小的包,终于传到服务器上了。 安装,测试,………………redis果然不通…………¥!@##@#!@#@##¥@#¥%¥&…………%& 告诉领导redis服务不通…… 领导看了阿云控制台,说忘了续费了,233233~ 续费后,测试redis通了,聊天服务也一切正常了,真折腾啊!! 此时,3个小时已经过去了……本来中秋只放了两天假,这又少了半天,早饭还没吃……不饿。   总结: 主因是redis过期没有续费的原因。 redis不通时,写log4net日志方法确实有错误。 异常日志记录的不够详细,如果记录了redis连不通异常,那就简单多了,也不用那么折腾;

龙生   23 Sep 2018
View Details
1 126 127 128 282