2. Редактор Mail.Ru?
• Beta-тестирование с сентября, Почта и Облако
• xlsx и pptx – MS Office Web App
• doc/docx – сделали сами!
3.
4.
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 файлы: docx и doc
• 1 год чтобы хорошо читать все три типа документов
• до сих пор находим что-то новое
10. Велосипед?
Да. И именной такой как нам надо.
• Высокая скорость чтения: в среднем < 1 секунды
• Вычитываем те данные которые нам нужны
• Легко вносить изменения
• Низкий процент ошибок при чтении: ~ 0.7%
Но вначале все было совсем не так хорошо.
11. Просмотрщик изнутри
• Backend получает запрос, планирует чтение и отдает html
• Файл асинхронно скачивается и читается в очереди заданий
• Client периодически опрашивает сервер о готовности документа
• Client рендерит документ из json
12. Запуск просмотра
• Все прогнозы были не верны. Кроме одного - насчет прогнозов.
• Не беда – пользователи этого просто не видели
• На запуске довольно много ошибок чтения документов
• Надо больше разных файлов для исправления!
• Читаем пока неудовлетворительно
Как быть?
13. Главное – не попадаться
Надо строить превью документов (thumbnail’ы)
• Не сломает то что уже работало
• Очень большое количество запросов
• Легко сделать используя js просмотра и phantomjs
• Server-side JS
14.
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
• Но не ошибки работы с конкретным браузером
• Часть превью строится через NodeJS
21. Редактирование
Логично, но:
• Качество html рендеринга не лучшее
• Нужна нормальная печать документов
• Формат, в который читаем, не удобен
• Сможем сохранять только в docx
• Не храним данные. Документ сохраняется в Облако.
22. Рендеринг
• Html -> Canvas или SVG. Выбираем Canvas
• Высокая точность рендеринга
• Форма обратной связи делает скриншот того что видит пользователь
• Некоторые проблемы с браузерами
23. Печать документов
• HTML не передает всех деталей
• Добавляет хедеры/футеры
• Canvas позволяет генерировать pdf на сервере
• Для показа диалога печати встраиваем JS в pdf
• Иногда может не работать
24. Протокол
• Древовидные JSON-структуры это плохо
• Нужно уметь передавать документ по частям
• Нужно обращаться по индексам
• Строка + элементы на ней
• Приходится менять логику чтения и показа – дублируем код!
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