internet 发表于 Feb 17, 2017 performance 他山之石 performance

LinkedIn serves more than 467 million members on a global computing infrastructure through hundreds of internal services. During processes such as new feature releases, capacity planning for traffic growth, and data center failover analysis, the following questions are raised frequently:

• “What is the maximum QPS (queries per second) that my service can sustain with its current setup?”
• “Can the current number of servers handle 50% more traffic volume than the current level of peak traffic?”
• “What infrastructure elements are the potential capacity bottlenecks for my service?”

As LinkedIn’s performance team, it’s our job to provide accurate answers to these questions in a timely fashion.

internet 发表于 Feb 2, 2017 performance 他山之石 performance

Introduction

Improving site speed is one of the major technology initiatives at LinkedIn because it is highly correlated with the engagement members have on our website. Real User Monitoring (RUM) is an approach where we use data from real users, instead of a synthetic lab environment, to measure performance, and this is the primary way we measure site speed at LinkedIn. In this blog post, we present how we measure performance of single-page applications at LinkedIn using RUM, and how we used RUM data to make our new LinkedIn web application faster by 20%.

Page Load Time (PLT) is the key metric that we measure for every page at LinkedIn in order to capture the user’s perception of when the page is ready. It is not easy to measure this metric uniformly across all pages because it is highly subjective depending on the content of the page and on the end user’s perception. Speed Index is a good indicator for the user’s perception of when the page is rendered, and we use it for measuring performance in synthetic environments. But it is not possible to calculate this metric accurately using RUM. So, we needed to find a good proxy for PLT that could be easily measured using RUM. For traditional web applications, which are mostly server-side rendered, window.onload() event is a reasonably good proxy for PLT. Most traditional RUM libraries use the Navigation Timing API to detect when window.onload() event is fired and thereby measure PLT for the page. However, as we discuss below, we ran into several obstacles when trying to use window.onload() as a proxy for PLT for single-page applications.

liyan 发表于 Dec 1, 2016 社会 杂文 daily

这两天“罗一笑事件“占据各大社交平台和新闻媒体，这件事从最初的朋友圈类似‘不转不是中国人’似的的温情爱心接力，到事件主角罗一笑父亲罗尔身家被扒皮曝光，进而一场全民献爱心活动演变成网友的口诛笔伐，最终成为一场史无前例的退还全部捐款的闹剧，实在是“热闹非凡”。然而此时此刻罗一笑小朋友还在和病魔坚强地作斗争，应该不会知道外面围绕自己发生的这一切。

这件看似普通的互联网众筹医疗款事件，本身很普通不过而且类似的众筹早在两年前已有先例，而且近两年来不在少数，但是没有任何一次像“罗一笑事件”这样引起全民的关注和讨论，什么原因？

1）性质不纯
不纯粹是简单的筹款治病。这件事从一开始的动机就是不纯的，罗尔本可以简单的通过自己的公众号发出这篇筹款的文章，不带有任何其他目的的，只是为孩子治病筹钱，这是无可非议的做法。但是，错就错在罗尔选择了和商业公司合作，采取了强行推广的方式，这也是事件闹大的最重要原因之一。这就带来一个问题，事件性质从个人事件变成了商业事件，明显带有广告和商业利益诉求，作为曾经担任杂志《新故事》10余年的主编，罗尔不会不知道这一点，可他还是这么做了，拿自己女儿的痛苦“营销”了一把。我想罗尔的本意应该是单纯的想利用自己的文笔筹到一笔医药费，殊不知被自己的朋友和公司利用了。

internet 发表于 Dec 10, 2015 api design restful performance

Your data model has started to stabilize and you’re in a position to create a public API for your web app. You realize it’s hard to make significant changes to your API once it’s released and want to get as much right as possible up front. Now, the internet has no shortage on opinions on API design. But, since there’s no one widely adopted standard that works in all cases, you’re left with a bunch of choices: What formats should you accept? How should you authenticate? Should your API be versioned?

In designing an API for Enchant (a Zendesk Alternative), I’ve tried to come up with pragmatic answers to these questions. My goal is for the Enchant API to be easy to use, easy to adopt and flexible enough to dogfood for our own user interfaces.

TL;DR

• An API is a user interface for a developer - so put some effort into making it pleasant
• Use RESTful URLs and actions
• Use SSL everywhere, no exceptions
• An API is only as good as its documentation - so have great documentation
• Version via the URL, not via headers
• Use query parameters for advanced filtering, sorting & searching
• Provide a way to limit which fields are returned from the API
• Return something useful from POST, PATCH & PUT requests
• HATEOAS isn’t practical just yet
• Use JSON where possible, XML only if you have to
• You should use camelCase with JSON, but snake_case is 20% easier to read
• Pretty print by default & ensure gzip is supported
• Don’t use response envelopes by default
• Consider using JSON for POST, PUT and PATCH request bodies
• Paginate using Link headers
• Provide a way to autoload related resource representations
• Provide a way to override the HTTP method
• Provide useful response headers for rate limiting
• Use token based authentication, transported over OAuth2 where delegation is needed
• Include response headers that facilitate caching
• Define a consumable error payload
• Effectively use HTTP Status codes

Key requirements for the API

Many of the API design opinions found on the web are academic discussions revolving around subjective interpretations of fuzzy standards as opposed to what makes sense in the real world. My goal with this post is to describe best practices for a pragmatic API designed for today’s web applications. I make no attempt to satisfy a standard if it doesn’t feel right. To help guide the decision making process, I’ve written down some requirements that the API must strive for:

liyan 发表于 Feb 24, 2015 java performance book java

目录

• 1章 介绍
• 2章 常用的测试java应用的方法以及经常遇到的陷阱
• 3章 java应用常用的监控工具
• 4章 JIT编译器
• 5&6章 GC
• 7章 jvm堆内存
• 8章 原生内存
• 9章 线程性能
• 10章 JavaEE API
• 11章 JPA和JDBC
• 12章 JavaSE API建议
• 附录A 所有的调优参数注解

1章

liyan 发表于 Jul 21, 2014 ruby tool ruby

Ruby_Bundler（中文参考）bundler.io

Bundler 是什么？

Bundler能够跟踪并安装所需的特定版本的gem，以此来为Ruby项目提供一致的运行环境。
Bundler是Ruby依赖管理的一根救命稻草，它可以保证你所要依赖的gem如你所愿地出现在开发、测试和生产环境中。利用Bundler启动项目简单到只用一条命令： bundle install

快速上手

Bundler使用起来非常简单。

第一步：打开命令行输入如下命令：

$ gem install bundler