forked from urfu-2016/markup-task-1
-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
309 lines (307 loc) · 17.9 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
<!doctype html>
<html lang="ru">
<head>
<meta charset="utf-8">
<title>Блог компании Яндекс</title>
</head>
<body>
<header>
<h2>ЯНДЕКС.ПОЧТА: КАК МЫ ИЗМЕРЯЕМ СКОРОСТЬ ЗАГРУЗКИ И УЛУЧШАЕМ ЕЁ</h2>
</header>
<main>
<section>
<article>
<p>
Если ваш сайт медленно грузится, вы рискуете тем, что люди не оценят ни то,
какой он красивый, ни то, какой он удобный. Никому не понравится, когда все
тормозит. Мы регулярно добавляем в Яндекс.Почту новую функциональность,
иногда — исправляем ошибки, а это значит, у нас постоянно появляются новый код
и новая логика. Всё это напрямую влияет на скорость работы интерфейса.
</p>
</article>
</section>
<section>
<header>
<h3>Что мы измеряем</h3>
</header>
<article>
<div>
<span>Этапы первой загрузки:</span>
<ul>
<li>подготовка;</li>
<li>загрузка статики (HTTP-запрос и парсинг);</li>
<li>исполнение модулей;</li>
<li>инициализация базовых объектов;</li>
<li>отрисовка.</li>
</ul>
</div>
<div>
<span>Этапы отрисовки любой страницы:</span>
<ul>
<li>подготовка к запросу на сервер;</li>
<li>запрос данных с сервера;</li>
<li>шаблонизация;</li>
<li>обновление DOM.</li>
</ul>
</div>
<p>
-<q>Ок, теперь у нас есть метрики, мы можем отправить их на сервер</q> - говорим мы<br>
-<q>Что же дальше?</q> - вопрошаете вы<br>
-<q>А давай посторим график!</q> - отвечаем мы<br>
-<q>А что будем считать?</q> - уточняете вы<br>
</p>
<p>
Как вы знаете, <dfn>медиана</dfn> – это серединное, а не среднее значение в выборке.
Если у нас имеются числа 1, 2, 2, 3, 8, 10, 20, то медиана – 3, а среднее – 6,5.
В общем случае медиана отлично показывает, сколько грузится средний пользователь.
</p>
<p>
В случае ускорения или замедления медиана, конечно, изменится. Но она не может
рассказать, сколько пользователей ускорилось, а сколько замедлилось.
</p>
<p>
APDEX – метрика, которая сразу говорит: хорошо или плохо. Метрика
работает очень просто. Мы выбираем временной интервал [0; t], такой, что если
время показа страницы попало в него, то пользователь счастлив. Берем еще один
интервал, (t; 4t] (в четыре раза больше первого), и считаем, что если страница
показана за это время, то пользователь в целом удовлетворен скоростью работы,
но уже не настолько счастлив. И применяем формулу:
</p>
<p>
(кол-во счастливых пользователей + кол-во удовлетворенных / 2) / (кол-во всех).<br>
Получается значение от нуля до единицы, которое, видимо, лучше всего показывает,
хорошо или плохо работает почта.
</p>
</article>
</section>
<section>
<header>
<h3>Как мы измеряем</h3>
</header>
<article>
<p>
Сейчас модуль обновления сам логирует все свои стадии, и можно легко понять
причину замедления: медленнее стал отвечать сервер либо слишком долго
выполняется JavaScript. Выглядит это примерно так:
</p>
<p>
<code>
this.timings['look-ma-im-start'] = Date.now();<br>
this.timings['look-ma-finish'] = Date.now();
</code>
</p>
<p>
C помощью <var>Date.now()</var> мы получаем текущее время. Все тайминги собираются и при
отправке рассчитываются. На этапах разница между “end” и “start” не считается,
а все вычисления производятся в конце:
</p>
<p>
<code>
var totalTime = this.timings['look-ma-finish'] - this.timings['look-ma-im-start'];
</code>
</p>
<p>И на сервер прилетают подобные записи:</p>
<p>
<samp>serverResponse=50&domUpdate=60</samp>
</p>
</article>
</section>
<section>
<header>
<h3>Как мы ускоряем</h3>
</header>
<article>
<p>
Чтобы снизить время загрузки почты при выходе новых версий,
мы уже делаем следующее:
</p>
<div>
<ul>
<li>включаем gzip;</li>
<li>выставляем заголовки кэширования;</li>
<li>фризим CSS, JS, шаблоны и картинки;</li>
<li>используем CDN;</li>
</ul>
</div>
<p>
Мы подумали: <q>А что если хранить где-то старую версию файлов, а при выходе новой
передавать только diff между ней и той, которая сохранена у пользователя?</q>
В браузере же останется просто наложить патч на клиенте.
</p>
<p>
На самое деле эта идея не нова. Уже существуют стандарты для HTTP — например,
RFC 3229 «Delta encoding in HTTP» и «Google SDHC», — но по разным причинам они
не получили должного распространения в браузерах и на серверах.
</p>
<p>
Мы же решили сделать свой аналог на JS. Чтобы реализовать этот метод обновления,
начали искать реализации diff на <abbr>JS</abbr>. На популярных хостингах кода нашли
библиотеки:<br>
- VCDiff<br>
- google-diff-patch-match
</p>
<p>Для окончательного выбора библиотеки нам нужно сравнить:</p>
<div>
<table>
<thead>
<tr>
<th>Библиотека</th>
<th><abbr>IE</abbr> 9</th>
<th>Opera 12</th>
</tr>
</thead>
<tbody>
<tr>
<td>vcdiff</td>
<td>8</td>
<td>5</td>
</tr>
<tr>
<td>google diff</td>
<td>1363</td>
<td>76</td>
</tr>
</tbody>
</table>
</div>
<p>
После того как мы определились с библиотекой для диффа, нужно определиться с тем,
где и как хранить статику на клиенте.
</p>
<p>
Формат файла с патчами для проекта выглядит так:
<code>
[<br>
{<br>
"k": "jane.css",<br>
"p": [patch],<br>
"s": 4554<br>
},<br>
{<br>
"k": "jane.css",<br>
"p": [patch],<br>
"s": 4554<br>
}<br>
]<br>
</code>
</p>
<p>
То есть это обычный массив из объектов. Каждый объект — отдельный ресурс. У
каждого объекта есть три свойства. <var>k</var> — названия ключа в localStorage для этого
ресурса. <var>p</var> — патч для ресурса, который сгенерировал vcdiff. <var>s</var>
— чексумма для ресурса актуальной версии, чтобы потом можно было проверить правильность
наложения патча на клиенте. Чексумма вычисляется по <dfn>алгоритму Флетчера</dfn>.
</p>
<div>
<dl>
<dt>Алгоритм Бройдена — Флетчера — Гольдфарба — Шанно (BFGS)</dt>
<dd>- итерационный метод численной оптимизации, предназначенный для
нахождения локального максимума/минимума нелинейного функционала
без ограничений.
Дано ε,x<sub>0</sub><br>
Инициализировать H<sub>0</sub><br>
k = 0<br>
while || ∇ƒ<sub>k</sub>|| > ε<br>
найти направление p<sub>k</sub> = -C<sub>k</sub>∇ƒ<sub>k</sub><br>
<div class="nows">вычислить x<sub>k+1</sub> = x<sub>k</sub> + α<sub>k</sub>
p<sub>k</sub>, α<sub>k</sub> удовлетворяет условию Вольфе</div><br>
<div class="nows">обозначить s<sub>k</sub> = x<sub>k+1</sub> - x<sub>k</sub> и y
<sub>k</sub> = ∇ƒ<sub>k+1</sub> - ∇ƒ<sub>k</sub></div><br>
вычислить C<sub>k+1</sub><br>
k = k+1<br>
end
</dd>
</dl>
</div>
<p>
Почему именно алгоритм Флетчера, а не другие популярные алгоритмы вроде:<br>
CRC16/32 - алгоритм нахождения контрольной суммы, предназначенный для проверки
целостности данных<br>
md5 - 128-битный алгоритм хеширования. Предназначен для создания «отпечатков»
или дайджестов сообщения произвольной длины и последующей проверки
их подлинности.
</p>
<p>Потому что он быстрый, компактный и легок в реализации.</p>
</article>
</section>
<section>
<header>
<h3>Итог</h3>
</header>
<article>
<p>Фактически мы экономим 80-90% трафика. Размер загружаемой статитки в байтах:</p>
<div>
<table>
<thead>
<tr>
<th>Релиз</th>
<th>С патчем</th>
<th>Без патча</th>
</tr>
</thead>
<tbody>
<tr>
<td>7.7.20</td>
<td>397</td>
<td>174 549</td>
</tr>
<tr>
<td>7.7.21</td>
<td>383</td>
<td>53 995</td>
</tr>
<tr>
<td>7.7.22</td>
<td>483</td>
<td>3 995</td>
</tr>
</tbody>
</table>
</div>
</article>
<footer>
<div>
Автор: @doochik<br>
С++ разработик<br>
<address>Электронная почта: ([email protected])</address>
Компания: Яндекс
</div>
</footer>
</section>
<section>
<header>
<h3>Комментарии (3):</h3>
</header>
<article>
<p>- Mogaika ([email protected])30 ноября 2014 в 17:05</p>
<p>А можете привести сравнение, на сколько быстрее грузится lite версия?</p>
</article>
<article>
<p>- JIguse ([email protected]) 29 ноября 2014 в 21:30</p>
<p>Спасибо за статью, познавательно. Здорово, что Яндекс делится некоторыми
подробностями о внутренней работе сервисов.
</p>
</article>
<article>
<p>- Brister ([email protected]) 24 ноября 2014 в 13:13</p>
<div>
<blockquote>(кол-во счастливых пользователей + кол-во удовлетворенных / 2) /
(кол-во всех).<br>Получается значение от нуля до единицы, которое, видимо,
лучше всего показывает, хорошо или плохо работает почта.</blockquote>
</div>
<p>наверное все-таки от 0.5 до 1</p>
</article>
</section>
<small>
- alexeimois ([email protected]) 22 ноября 2014 в 17:35<br>
Мы измеряем скорость загрузки с помощью Яндекс.Метрики:
<a href="help.yandex.ru/metrika/reports/monitoring_timing.xml">
help.yandex.ru/metrika/reports/monitoring_timing.xml
</a>
</small>
</main>
<footer>
© Яндекс, [email protected], Хохрякова, 10
</footer>
</body>
</html>