摘要：常公司的开发环境都会布置在内网，然后会有公共的服务器让大家在上面进行开发，测试，所以经常会有ssh连接服务器，或者本地mysql client连接服务器的需求，我个人经历过的公司经常会发生ssh/mysql连接公共服务器非常慢的现象，这是由于ssh服务和mysql服务默认都会在登录时进行DNS反向解析的过程，而内网通常我们没有配备DNS服务，那么这时就只能等这些服务自己超时，然后才能允许我们的登录通过，解决方案也很简单，只要关闭相应服务的解析就行了。 阅读全文

摘要：昨天和某人聊到算命，我借此发表了一下自己对这方面的看法（虽然我才说了几句对方就睡了过去），我自己之前一向是对这些东西嗤之以鼻的，但今年经过一些思考，对这方面的态度有了一些改变，不过从本质上来讲我仍然是一个无神论者，只是自己用数学和计算机方面的知识去理解命运这回事。 我们好似每天身边都在发生或是经历一些不可预知的事情，有时候我们常会陷于纠结某个决定的时刻，这些抉择时刻或对自己的未来很重要，也或者轻描淡写，但有时候两种不同的抉择确实会影响到人的一生，但倘若我们的这些“抉择时刻”，以及最终的抉择都是必然的呢（也就是大多数江湖术士口中的“定数”）？很多从事互联网工作的朋友包括我，也许都不信这一套，不过如果从某些科学的角度去解读，发觉倒也不全无道理。 阅读全文

摘要：在上家公司曾写过这样一个服务，用户通过我的应用（以下简称fri_svr）索取自己的好友信息，而fri_svr需要向第三方平台（如：人人，Facebook）通过http协议批量请求用户数据，由于用户数据可能很大（几k几十k的级别），所以整个req/rep的过程通常会很慢，平均大概会在 1s – 10s 之间，这样当瞬时请求量到一定级别后，就会造成fri_svr的内存暴涨且响应不了前端的请求，原因在于fri_svr会对前端的每个请求hash到（根据user_id）专门用于http请求的线程队列中（也即是one thread per queue模型），当前端向fri_svr的请求速率大于平台响应fri_svr的，那么就会造成fri_svr中队列的积攒，内存的暴涨，且无法在超时时间内响应前端请求。 阅读全文