Редактор Mail.Ru или скорочтение за полчаса

Highload++ 2014

Transcript

1. Редактор Mail.Ru или скорочтение за полчаса Павел Зиновкин
2. Редактор Mail.Ru? •  Beta-тестирование с сентября, Почта и Облако •  xlsx и pptx – MS Office Web App •  doc/docx – сделали сами!
5. Не только редактор! Свое функциональное ядро. Оно дает: •  Просмотр документов: doc, docx, xls, xlsx, ppt, pptx, rtf •  Построение для них thumbnail’ов •  Онлайн редактирование doc и docx документов
6. Как все начиналось Почта использовала просмотр документов от MS. •  Он медленный •  Нестабильный •  Black box А что если сделать свой просмотрщик?
7. Как читаем документы? Решаем читать документы сами, не через OpenOffice! •  OO тяжелый, java •  Тяжело прогнозировать масштабируемость •  Невозможно прогнозировать гибкость решения
8. Читаем сами Минусы •  Бинарные форматы •  Объем работ для чтения Плюсы •  350 MB документации по MS форматам •  X–форматы от MS это xml в zip-архиве •  Гибкость лимитирована только нашим упорством
9. Учимся читая •  Документация описывает структуры •  Телепатия помогает понять логику их взаимодействия •  2 месяца чтобы сносно читать Word файлы •  1 год чтобы хорошо читать все три типа: Word, Excel, PowerPoint •  до сих пор находим что-то новое
10. Велосипед? Да. И именной такой как нам надо. •  Скорость чтения полного документа в среднем < 1 секунды •  Вычитываем те данные которые нам нужны •  Легко вносить изменения •  Низкий процент ошибок при чтении: ~ 0.7% Но вначале все было совсем не так хорошо.
11. Просмотрщик изнутри •  Backend получает запрос, планирует чтение и отдает html •  Файл асинхронно скачивается и читается в очереди заданий •  Client периодически опрашивает сервер о готовности документа •  Client рендерит документ из json
12. Запуск просмотра •  Все прогнозы были не верны. Кроме одного - насчет прогнозов. •  Не беда – пользователи этого просто не видели •  На запуске довольно много ошибок чтения документов •  Надо больше разных файлов для исправления! •  Читаем пока неудовлетворительно Как быть?
13. Главное – не попадаться Надо строить превью документов (thumbnail’ы) •  Не сломает то что уже работало •  Очень большое количество запросов •  Легко сделать используя js просмотра и phantomjs •  Server-side JS
15. Как сделаны превью •  Backend скачивает, читает и рендерит документ через PhantomJS •  PhantomJS вызывается через командную строку (subprocess) •  Читается только первая страница документа
16. Едем в бой •  Приложение не оптимально, и это ок •  Не пытаемся прогнозировать нагрузку •  Оптимизируем по реальным данным •  Даем трафик и чиним то что не выдерживает
17. Что не покажет профайлер? •  Все что вы не профилируете! •  Невозможно профилировать весь стек приложения •  Помогут графики/таймеры на разных уровнях
18. Оптимизируем •  Эмбедим js и css, прекомпилируем django-шаблон •  Передаем отрендеренный шаблон на stdin •  Выключаем индентацию json-данных - 7% (!) ускорения рендеринга •  Inline base64 изображения •  Выдаем данные в bmp вместо jpeg - все равно масштабировать •  Теперь можно профилировать
19. SOA can kill you •  Сервис-провайдер может легко вас положить •  Как и вы его •  Таймауты на все внешние запросы •  Графики на все •  Помните – это симбиоз, а не паразитирование!
20. Превью сейчас •  Один код для чтения документов и превью! •  Время построения превью в диапазоне 480-800 ms •  30 серверов, более 700 запросов в секунду •  Позволяют отловить ошибки логики JS •  Но не ошибки работы с конкретным браузером
21. Редактирование Логично, но: •  Качество html рендеринга не лучшее •  Нужна нормальная печать документов •  Формат, в который читаем, не удобен •  Сможем сохранять только в docx •  Не храним данные. Документ сохраняется в Облако.
22. Рендеринг •  Html -> Canvas или SVG. Выбираем Canvas •  Высокая точность рендеринга •  Форма обратной связи делает скриншот того что видит пользователь •  Некоторые проблемы с браузерами
23. Печать документов •  HTML не передает всех деталей •  Добавляет хедеры/футеры •  Canvas позволяет генерировать pdf на сервере •  Для показа диалога печати встраиваем JS в pdf •  Иногда может не работать
24. Протокол •  Древовидные JSON-структуры это плохо •  Нужно уметь передавать документ по частям •  Нужно обращаться по индексам •  Строка + элементы на ней •  Приходится менять логику чтения и показа – дублируем код!
25. Редактирование сейчас •  Beta •  Более 200 человек онлайн •  Ведется интенсивная разработка
26. О качестве •  Простота кода •  Документация •  Надежность, точность и гибкость инструментов
27. Тесты •  Unit-тесты, в том числе и для js •  Сложно писать тесты для форматов. Используем регрессии •  Resave: json1 -> document -> json2, json1 == json2 ? •  Делаем скриншоты между ветками и сравниваем их
28. Инструменты •  Sentry и graphite/statsd для графиков из приложений •  Diamond для графиков с серверов •  Jenkins: тесты на каждый комит, регрессии •  Phabricator для код-ревью
29. Вопросы? Павел Зиновкин Руководитель группы разработки, Почта@Mail.Ru p.zinovkin@corp.mail.ru