Computing firebase message size

Question

Я пытаюсь вычислить размер сообщений в firebase, чтобы точно оценить стоимость моего приложения.

Я заметил при запуске, что калькулятор базы данных реального времени показывает больший, чем ожидалось, размер данных. Чтобы проверить это, я начал приложение игрушка, которая имеет один реф называемый «тест» с данными:

{"foo": "bar"} 

Идущий на другие ответы, моя оценка, что эти данные до 20 байт.

Извлечение данных с помощью этого кода:

firebase.database().ref("test").once("value", function(snapshot) { 
    console.log(snapshot.val()); 
}); 

Вот jsfiddle showing this toy example.

Я хватаю ref и console.log данные. Я получил доступ к этому примеру в 10 раз. Когда я смотрю на вкладку использования базы данных приложения для игрушек, она показывает примерно такую ​​же ширину полосы пропускания 30 КБ.

Какие другие данные отправляются на счет этого большого разрыва в ожидаемом использовании данных (10 * 20 байтов = 200 байт) против фактического 30 КБ отправленного?

Есть ли начальные накладные расходы при инициализации приложения, которое добавляет к использованию данных?

EDIT:

Следуя совету cartant, я вошел кадры отправляются с WebSocket. Вот что я нашел (До этого я вижу некоторые инициализации сообщения от около 200 байт):

 Data              Length  
    {"t":"d","d":{"r":22,"a":"q","b":{"p":"/test","h":""}}}  55 
    {"t":"d","d":{"b":{"p":"test","d":{"foo":"bar"}},"a":"d"}} 58 
    {"t":"d","d":{"r":23,"a":"n","b":{"p":"/test"}}}   48 
    {"t":"d","d":{"r":22,"b":{"s":"ok","d":{}}}}    44 
    {"t":"d","d":{"r":23,"b":{"s":"ok","d":""}}}    44 

Так что похоже есть ~ 200-250 байт накладные расходы для любого сообщения. Может ли кто-нибудь подтвердить это? Это все еще не полностью объясняет тот пробел, который я упомянул ранее (10 сообщений * 250 байт = 2,5 КБ против записанного 30 КБ).

UPDATE:

Текущее использование полосы пропускания до 155 Кбайт. Я не уверен, как это число возможно с 35 зрителями на этом посту. Для того, чтобы попытаться получить ощущение этого (я до сих пор не знаю, как пропускная способность фактически вычисляется), вот мои мысли:

200 bytes to initialize/connect 
220 bytes per message (200 bytes of overhead + 20 bytes in message) 
100 times sent (this is probably an overestimate, as there are 35 views on this post, but I have viewed it around 10 times myself) 

(200 bytes + 220 bytes) * 100 views = 42000 bytes or 42 KB. 

Так, чтобы добраться до 155 КБ либо это было направлено гораздо больше, чем в 100 раз , или есть некоторые необъяснимые накладные расходы. Кроме того, я предполагаю (что я не знаю), что служебные данные для инициализации составляют 200 байт, а служебные данные для отправки любого сообщения - 200 байт.

Answer 1

Я проверил еще несколько тестов (чтение 22 байта) и думаю, что есть возможная ошибка при расчете полосы пропускания. Если нет, то полосы пропускания при перезагрузке очень велики. Вот мои тесты:

Test 1 (600 requests of 22 bytes with only one initial connect to the page) 

83 KB total for 600 requests 
83 KB = 83,000 bytes/600 requests = 138.33 bytes per request 
data sent = 22 bytes 
138.33 bytes - 22 bytes = 116.33 bytes overhead per message sent 

Что является разумным и довольно хорошо (хотя это, кажется, не будет учитываться на ценовой странице firbase в).

Я проверил второе испытание после ожидания в течение полутора часов, чтобы обновление базы данных в реальном времени могло обновляться.

Test 2 содержит то, что я думаю, что может быть ошибкой:

Test 2 (20 page reloads sending one request) 

96 KB total for 20 page reloads + 20 requests 
96 KB/20 = 4.8 KB per reload 

Я не думаю, что это может быть правильным, что приводит меня к мысли, что есть ошибка в части использования данных из базы данных в режиме реального времени , Я заметил, что при обновлении данные будут расти примерно на 2-4 килобайта (у меня осталось только 22 байта).

Я уверен, что этот прецедент легко воспроизводится. Я не собираюсь повышать это, так как это не ответ, он просто дает больше вопросов, но это то, что я нашел при запуске этих тестовых примеров.

Thanks