Чтобы подсчитать поведение пользователя в приложении или собрать некоторые данные о продукте, приложению часто требуется отчет журнала, а отчет журнала часто требует большого трафика.Как ваше приложение сообщает журнал?
Голос за кадром: Основная часть пользовательского трафика приходится на отчеты журналов?
Может ли приложение не сообщать журналы и собирать данные о поведении пользователей и продукте только из журналов сервера?
Нет, некоторые действия пользователей не будут взаимодействовать с сервером, например «переключение карты», и журнал сервера не может отображать всю статистику.
Как приложения обычно сообщают журналы?
Существует несколько распространенных методов.
(1) Использовать сторонние инструменты, аналогичные Google Analytics;
Плюсы: Не требует разработки
Недостаток: нельзя вести персонализированную статистику.
(2) разработать частные соглашения для отчетности;
Преимущество: экономия трафика
Недостаток: высокая стоимость разработки.
Голос за кадром: например, бинарный протокол TCP, который можно настраивать и экономить трафик.
(3) Используйте протокол HTTP для передачи данных, которые необходимо сообщить, через параметры GET.
Как отчитаться по протоколу HTTP?
Файл может быть размещен на веб-сервере, приложение инициирует HTTP-запрос для доступа к файлу, передает данные через параметр GET и получает нужные данные, анализируя журнал доступа.
Как передать данные через GET-параметры?
Обычно есть два пути:
(1) метод согласованного формата;
(2) метод КВ.
Что такое «обычный формат»?
Метод условного формата: разделитель условного обозначения, заполнитель условного обозначения, условное обозначение каждого поля, например:
Соглашение заключается в следующем:
(1) Доступ к файлу открыт;
(2) разделитель [];
(3) Первое поле [bj] представляет город, второе поле представляет дату, третье поле представляет время, четвертое поле представляет идентификатор пользователя, а пятое поле представляет поведение.
Этот методнедостатокДа: масштабируемость плохая.Иногда некоторые поля не имеют значения, и плейсхолдеры должны быть зарезервированы в соответствующих позициях, потому что значение каждого поля заранее оговаривается.Чтобы добавить элемент статистики, вы можете только использовать GET Add[ ] после этого.
Что такое «метод КВ»?
Метод KV: сообщайте данные с помощью самообъясняемого метода KV параметров GET.
В приведенном выше примере для отчета используется метод KV, а форма отчета:
методапреимуществоДа: хорошая масштабируемость.
недостатокДа: объем сообщаемых данных относительно велик, что требует большого объема трафика.
Почему он потребляет так много трафика?
Основные причины потребления трафика следующие:
(1) много недопустимого трафика, а в HTTP-сообщении много недопустимых данных;
(2) URL-адрес является избыточным, и URL-адрес необходимо сообщать каждый раз;
(3) КЛЮЧ является избыточным, и КЛЮЧ необходимо сообщать каждый раз;
(4) Частота отчетов высока.Если пользователю необходимо сообщать журнал каждый раз, когда он работает, объем отчетов очень велик.
Есть ли способ сэкономить трафик?
Для вышеуказанных пунктов 1-4 общие схемы оптимизации следующие.
Проблема 1: в HTTP-запросе много неверных данных.
Решение. Создайте HTTP-запросы вручную, чтобы удалить как можно больше неверных данных в HTTP.
Голос за кадром:
Если вы используете стороннюю библиотеку для создания HTTP-запроса, она может принести данные UA, которые вам не нужны.
Если вы создадите его самостоятельно, вы можете сохранить только необходимые данные, переданные GET /up HTTP/1.1 и GET;
Проблема 2: избыточность URL.
Решение. Используйте максимально короткое доменное имя для получения отчетов журналов.
Голос за кадром: например, s.daojia.cn/a
Болевая точка 3: КЛЮЧЕВАЯ избыточность.
Решение. Используйте максимально короткий KEY для идентификации данных, а сборщик журналов должен единообразно стандартизировать KEY.
Голос за кадром: Например, city=bj можно оптимизировать до c=bj.
ПЛОХОЙ СЛУЧАЙ, потому что нет спецификации, когда-то отдел сообщил идентификатор пользователя, а точки неоднократно были зарыты в разных проектах, и сообщалось 4 раза:
name=shenjian&user_id=123&uid=123&user_name=shenjian
Приведенное выше имя, user_id, uid и user_name — повторяющиеся отчеты.
Болевая точка 4: Частота сообщений высока.
Решение: сначала сохраните данные в локальном хранилище приложения, а затем регулярно сообщайте об этом.Такой вид оптимизации особенно эффективен для статистики PV, SUM и AVG.
Например, чтобы подсчитать количество кликов по кнопке входа в систему, три клика, традиционную статистику может потребоваться сообщить три раза:
uphome.com/up?dart=201…
uphome.com/up?dart=201…
uphome.com/up?dart=201…
После оптимизации добавляется параметр, который нужно сообщить только один раз:
Отчеты не в режиме реального времени, когда следует выполнять отчет журнала?
Если отчет объединен или сообщается в пакетах, своевременность данных будет иметь определенное влияние.
Голос за кадром: Если стратегия разумна, ошибка данных будет очень маленькой.
Для оптимизации об этом будет сообщено в некоторые из следующих моментов времени:
(1) Отчетность в определенные моменты времени: например, когда приложение открывается, закрывается и фон становится активным;
(2) Пакетная отчетность по времени: например, отчет только один раз каждые 10 минут;
(3) Пакетная отчетность в соответствии с объемом данных: например, отчет только один раз каждые 10 собранных записей;
Какие еще есть оптимизации?
Пакетная отчетность, сжатие данных.
Надеюсь, логика статьи понятна.
Путь архитектора — делитесь простыми для понимания техническими статьями
Исследование:
Есть ли у вашей компании спецификация захоронения?
Было ли дублирование в разных проектах?