Comparación de formatos de intercambio de datos JSON y XML: un caso de estudio
Resumen
En este trabajo se comparan dos formatos de
intercambio de datos utilizados actualmente
por las aplicaciones de la industria; XML y
JSON. La elección de un formato adecuado de
intercambio de datos puede tener
consecuencias significativas sobre las tasas de
transmisión de datos y el rendimiento.
Describimos las especificaciones del lenguaje
y su respectiva configuración de uso. A
continuación se realiza un estudio de caso
para comparar la utilización de los recursos y
el rendimiento relativo de las aplicaciones que
utilizan los formatos de intercambio.
Encontramos que JSON es significativamente
más rápido que XML y además registramos
otras métricas relacionadas con los recursos
en nuestros resultados.
1. Introducción.
Los formatos de intercambio de datos
evolucionaron de ser marcados y orientados a
la visualización para apoyar aún más la
codificación de metadatos que describe los
atributos estructurales de la información. Los
requisitos para apoyar el intercambio de datos
de aplicaciones Java llevó al desarrollo de
formatos de intercambio de datos estándar
[2]. JSON y XML son dos formatos de
intercambio de datos con propósitos únicos.
Las secciones dos y tres proporcionan
antecedentes para JSON y XML. La sección
cuatro describe el estudio de caso y la
metodología utilizada para comparar la
velocidad y la utilización de los recursos. La
sección cinco describe los resultados y la
sección seis identifica las amenazas a la validez
de este estudio. Concluimos en la sección siete
y proporcionamos las direcciones para los
refinamientos posibles a este estudio.
2. XML
El XML (Extensible Markup Language) [3] es un
subconjunto del SGML (Standard Generalized
Markup Language) y evolucionado como
resultado de la complejidad de SGML. XML es
considerado el "santo grial" de la informática
debido a su formato de representación de
datos universal [1]. La intención de un
documento XML es evidente por sí misma y
está incrustada en su estructura. Las
consideraciones fundamentales de diseño de
XML incluyen la simplicidad y la legibilidad
humana. Entre los objetivos de diseño de XML,
el W3C especifica que "XML será directamente
utilizable a través de Internet" y que "los
documentos XML deben ser legibles por el
hombre y razonablemente claros". Los usos
principales para XML son Remote Procedure
Calls (RPC) [4] y la serialización de objetos para
la transferencia de datos entre aplicaciones.
XML es un lenguaje utilizado para crear
marcados definidos por el usuario para
documentos y esquemas de codificación. XML
no tiene conjuntos de etiquetas predefinidos y
cada etiqueta válida es definida por un usuario
oa través de otro esquema automatizado.
Varios números de tutoriales y foros de
usuarios ofrecen un amplio soporte para XML
y han ayudado a crear una amplia base de
usuarios. XML es un formato de datos
jerárquico definido por el usuario. Un ejemplo
de un objeto codificado en XML se
proporciona en la figura 1.
Figura 1. Una estructura jerárquica que
describe la codificación de un nombre
 3. JSON
JSON [6] está diseñado para ser un lenguaje de
intercambio de datos que es legible por el
hombre y fácil para las computadoras para
analizar y utilizar. JSON está directamente
soportado dentro de JavaScript [7] y es más
adecuado para aplicaciones JavaScript; Lo que
proporciona ganancias de rendimiento
significativas sobre XML, lo que requiere
bibliotecas adicionales para recuperar datos
de los objetos DOM (Document Object Model)
[12]. Se estima que JSON analiza hasta cien
veces más rápido que XML [6] en los
navegadores modernos, pero a pesar de sus
afirmaciones de desempeño notable, los
argumentos contra JSON incluyen falta de
soporte de espacio de nombres, falta de
validación de entrada y inconvenientes de
extensibilidad. Crockford [6] aborda tales
argumentos alegando que "cada objeto es un
espacio de nombres. Su conjunto de claves es
independiente de todos los demás objetos,
incluso exclusivos de anidamiento. Además,
JSON utiliza el contexto para evitar la
ambigüedad, al igual que los lenguajes de
programación ", que la validación de los
insumos es responsabilidad de las aplicaciones
de dominio individuales, y que la falta de
extensibilidad de las reivindicaciones es
abordada por la flexibilidad de las
construcciones JSON. La sintaxis de JSON es
legible por el ser humano. La Figura 2 describe
un ejemplo en el que JSON se utiliza para
codificar un nombre y un apellido.
Figura 2. Una construcción JSON simple que
describe la codificación de un nombre
4. METODOLOGÍA
Este estudio de caso mide el tiempo de
transmisión y la utilización de los recursos. La
hipótesis nula establece que no hay diferencia
en los tiempos de transmisión y utilización de
recursos entre JSON y XML. El entorno
operativo para este estudio de caso consiste
en un programa cliente / servidor. El cliente se
configura de forma aislada y envía objetos
JSON y XML al servidor para medir el
rendimiento y la utilización de recursos.
Encontramos evidencia significativa para
apoyar el rechazo de la hipótesis nula.
4.1. Programa Cliente / Servidor
Nuestros casos de prueba utilizan un
programa cliente de red simple para transmitir
objetos Java codificados en XML y codificados
en JSON a un servidor. El cliente y el servidor
inician conexiones basadas en TCP / IP donde
el servidor escucha en un puerto y el cliente se
conecta en ese puerto. El cliente y el servidor
utilizan técnicas de codificación similares. Para
simular servidores realistas y potencialmente
ejecutar pruebas de estrés, el servidor es de
múltiples hilos. El servidor descodifica el texto
JSON o XML al recibirlo y luego descarta el
texto.
4.2. Ambiente
El programa cliente envía datos codificados de
JSON y XML en un entorno de workbench
aislado. El hardware consiste en dos
estaciones de trabajo interconectadas por un
conmutador. Los servicios de firewall de
software están deshabilitados. Dado que el
intercambio de datos no implica leer y escribir
en el almacenamiento secundario, la
capacidad de lectura / escritura de disco no es
importante para estas estaciones de trabajo.
Las estaciones de trabajo tienen una
instalación mínima de CentOS 5.2 [14] con
paquetes de software adicionales para
registrar varias medidas del sistema. Las
estaciones de trabajo están conectadas a una
red de área local aislada. El switch soporta
conexiones gigabit y las estaciones de trabajo
tienen tarjetas de interfaz de red de 10/100
megabits. Los cables Cat5e funcionan entre las
tarjetas de interfaz de red de las estaciones de
trabajo y el conmutador, y la topología
completa está dispuesta a poca distancia
(menos de 10 metros). De acuerdo con la
herramienta de monitoreo de red, IPTraf [5],
nuestra red aislada no muestra tráfico
frecuente de red.
4.3. Mediciones
Elegimos medir las siguientes métricas:
número de objetos enviados, tiempo total
para enviar el número de objetos, tiempo
promedio por transmisión de objetos,
utilización de la CPU del usuario, utilización de
la CPU del sistema y utilización de la memoria.
El tiempo total por prueba nos indica cuánto
tarda el servidor en recibir cada objeto del
cliente. El tiempo promedio por objeto
describe cuánto tarda (en promedio) en que el
servidor reciba un objeto del cliente. La
utilización de la CPU del usuario es el
porcentaje de tiempo que se pasa realizando
los procesos del usuario y la utilización de la
CPU del sistema es el porcentaje de tiempo
dedicado a realizar procesos del sistema. De
acuerdo con RedHat [9], altos porcentajes de
CPU de usuario tienden a ser favorable,
mientras que los altos porcentajes del sistema
tienden a apuntar hacia problemas que
requieren más investigación [13]. La
utilización de la memoria mide el porcentaje
de memoria disponible y libre en el sistema.
Nuestras métricas se registran en archivos
utilizando software cliente / servidor
desarrollado internamente y System Activity
Reporter (SAR), una utilidad de grabación
métrica [11]. El programa cliente / servidor
mide el tiempo de transmisión por transmisión
de objetos. SAR mide la utilización de recursos
por tiempo-duración. Las mediciones de
tiempo se calculan de la siguiente manera. El
cliente se conecta y envía un comando de
inicio al servidor. Cuando el servidor recibe el
comando start, inicia un temporizador y envía
un mensaje listo. El cliente recibe el mensaje
listo y comienza la transmisión de objetos.
Cuando el cliente termina de transmitir sus
objetos, envía una señal final al servidor y el
servidor apaga su temporizador y sus métricas
de registro. Las métricas se registran en un
archivo con una marca de tiempo para indicar
cuándo finaliza la prueba.
4.4. Diseño del estudio de caso
Los casos de prueba se diseñan e implementan
para comparar tiempos de transmisión y
utilización de recursos de JSON y XML. El
primer escenario consiste en ejecutar una
única transmisión que consume mucho
tiempo de una gran cantidad de objetos con el
fin de lograr medidas medias precisas. El
segundo escenario consiste en ejecutar una
serie de casos de prueba con un número cada
vez mayor de objetos. Su propósito es
determinar si JSON o XML difieren
estadísticamente a medida que aumenta el
número de objetos codificados enviados al
servidor. El número de objetos transmitidos al
servidor se trata como una variable
independiente. Al aumentar el número de
objetos enviados al servidor a intervalos
discretos igualmente espaciados, añadimos la
varianza a las distribuciones de las mediciones
para la prueba t de comparación de la media.
Además, comparamos el impacto de la
transmisión de un gran número de objetos con
el impacto de transmitir un número bajo de
objetos observando lo que sucede con las
mediciones en grados variables de
granularidad. El primer escenario consiste en
un cliente que envía un millón de objetos a un
servidor utilizando tanto la codificación JSON
como la codificación XML. El segundo
escenario consiste en un cliente que envía
cantidades menores de objetos a un servidor
en cinco intervalos separados. El cliente envía
20.000, 40.000, 60.000, 80.000 y 100.000
objetos codificados al servidor. Nos referimos
a estos intervalos de transmisión como Trial 1,
Trial 2, Trial 3, Trial 4 y Trial 5,
respectivamente.
5. RESULTADOS
Los resultados ilustran las diferencias entre la
codificación JSON y XML en diferentes
escenarios de transmisión. Esta sección
presenta las métricas obtenidas para las
mediciones medias, compara las métricas de
transmisión de alto versus bajo número de
objetos codificados y determina si JSON y XML
son estadísticamente diferentes para cada una
de nuestras mediciones. Presentamos las
mediciones de ambos escenarios y discutimos
sus implicaciones.
5.2. Escenario 2
El escenario 2 se compone de una serie de
ensayos más pequeños que determinan si
JSON y XML son estadísticamente diferentes
según cada una de nuestras medidas. Se utiliza
la prueba t de comparación de la media.
Enviamos 20.000, 40.000, 60.000, 80.000 y
100.000 objetos codificados al servidor y
recopilamos métricas para cada caso. Las
tablas 3, 4 y 5 muestran las métricas obtenidas
de estos ensayos:
Tabla 3. Escenario 2 JSON Vs XML Timing

5.1. Escenario 1

El escenario 1 es una transmisión de mucho

tiempo de una gran cantidad de objetos. Se
usan grandes cantidades de objetos para
lograr medidas medias precisas. El cliente
envía un millón de objetos codificados al
servidor para JSON y XML. Medimos el tiempo
y la utilización de los recursos. En las Tablas 1
y 2 se enumeran las mediciones y los valores
respectivos obtenidos de este ensayo:

Tabla 1. Escenario 1 JSON vs. XML Timming

Tabla 4. Escenario 2 JSON CPU / Mem

Tabla 2. Escenario 1 JSON vs. XML CPU / Mem

Tabla 5. Escenario 2 XML CPU / Mem
La Figura 3 ilustra las utilidades promedio de
JSON para CPU y memoria por ensayo. La
Figura 4 ilustra la utilización promedio de la
CPU y la memoria de XML por ensayo. La
Figura 5 ilustra las diferencias entre las
utilizaciones de recursos de JSON y las
utilizaciones de recursos de XML, trazando la
Figura 3 y la Figura 4 en el mismo gráfico.
Las figuras 3-5 indican que XML parece utilizar
menos la utilización de la CPU del usuario que
JSON. Las transmisiones codificadas JSON y
XML utilizan casi la misma cantidad de
memoria en el servidor.
Figura 3. Escenario 2 Utilización de recursos de
JSON
Figura 4. Escenario 2 Utilización de recursos
XML
Figura 5. Escenario 2, JSON Vs XML (Utilización
de recursos)
5.3. Discusión
Para analizar nuestros resultados hacemos
observaciones cualitativas de alto nivel y
analizamos cada vez más el significado de cada
medida mediante pruebas estadísticas. Esta
sección explica las diferencias observadas
usando una prueba t tradicional.
Observaciones cualitativas de alto nivel entre
JSON y XML se observan en ambos escenarios
de prueba. El escenario 1 ilustra mediciones
medias precisas debido al gran número de
transmisiones de objetos codificados. El
Escenario 2 proporciona observaciones de
grano fino de los impactos de menos
transmisiones para cada medición. La Tabla 6
enumera las diferencias entre JSON y XML
basadas en las observaciones y los resultados
de cada escenario. Los valores medios de las
mediciones del escenario 1 indican que enviar
datos en codificación JSON es en general más
rápido que usar la codificación XML. Las
mediciones de tiempo medio y tiempo total
proporcionan una indicación de que la
velocidad de JSON supera la velocidad de XML.
Además, JSON utiliza más recursos de CPU de
usuario que XML en el escenario 1. La
memoria depende del estado de los sistemas
antes de un escenario o ejecución de prueba;
Sin embargo, el uso es similar entre JSON y
XML. De acuerdo con nuestras observaciones
y las métricas obtenidas de ambos escenarios,
los tiempos de transmisión de XML son
menores cuando se transmiten menos objetos
y los tiempos de transmisión de JSON son los
mismos cuando se transmiten menos objetos.
Tabla 6. Resultados y observaciones de alto
nivel
La transmisión de una menor cantidad de
objetos codificados por JSON no parece
afectar a la medida de utilización de la CPU del
usuario cuando se compara con la transmisión
de una cantidad mayor de objetos. La prueba
t es una manera de comparar las medias de
dos distribuciones y determinar si son
estadísticamente diferentes. Ejecutamos una
ttest no apareada de dos caras sobre los
resultados del escenario 2 para comparar
JSON y XML con respecto a cada medida. El
nivel de significación se establece en α = 0,05
[10]. La distribución de cada medida es el
conjunto que comprende las cinco
observaciones que vienen de cada uno de los
cinco ensayos en el escenario 2. Hacemos la
suposición hipótesis nula de que JSON y XML
tienen los mismos medios para cada
distribución de medida. Luego, usamos la
prueba t para calcular la probabilidad que
proporcionaría evidencia para apoyar una
hipótesis alternativa. La Tabla 7 enumera las
distribuciones de muestras utilizadas en las
pruebas t para comparar cada medida. Los
valores de distribución provienen de las tablas
3, 4 y 5.
Tabla 7. Las poblaciones de muestras JSON y
XML utilizadas en la prueba t
Tabla 8. JSON y XML t-test p-valores con α =
0,05
La tabla 8 enumera las probabilidades (p-
valores) que habríamos llegado a nuestros
resultados bajo la hipótesis de hipótesis nula.
Los resultados de la prueba T muestran que
JSON y XML tienen tiempo total
estadísticamente diferente por ensayo,
tiempo medio por ensayo y la utilización
promedio de la CPU del sistema por ensayo. 6.
AMENAZAS A LA VALIDEZ Los estudios de caso
están sujetos a amenazas de validez,
específicamente, validez interna, validez
externa, validez de constructo y validez de
contenido. Utilizamos medidas que
representan adecuadamente las nociones de
rendimiento y utilización de recursos como se
describe en la sección 4.3, proporcionando así
métricas significativas de validez de
constructo. La configuración de nuestros
escenarios de prueba donde los programas
cliente y servidor están aislados del tráfico de
difusión en una red proporcionan confianza
adicional de que nuestras métricas no se
confunden con variables adicionales. Se
utilizan diversas medidas para entender las
diferencias entre JSON y XML; Aumentando así
la validez del contenido del estudio. La validez
interna se refiere a la relación que existe entre
variables independientes y dependientes. Las
medidas descritas en la sección 4.3
representan las variables dependientes de
nuestro estudio y las únicas variables
independientes son los programas de casos de
prueba que se ejecutan en los escenarios 1 o
2. La homogeneidad y el aislamiento de los
casos de prueba que corren bajo JSON o XML
aumenta la validez interna del estudio . La
validez externa se refiere a la capacidad de
generalizar los resultados de este estudio de
caso. Es evidente que esto no es posible ya que
se necesitarían casos de prueba adicionales
para tener en cuenta los diferentes sistemas
operativos, el contenido de los datos, los
tamaños de los paquetes transmitidos a través
de la red, etc. Este estudio de caso sirve como
punto de datos único para demostrar las
diferencias de desempeño y utilización de
recursos entre JSON Y XML para los casos de
prueba específicos dados.
7. CONCLUSIÓN
Este estudio de caso comparó las diferencias
entre dos formatos de intercambio de datos
actuales. Los resultados indican que JSON es
más rápido y utiliza menos recursos que su
contraparte XML; Proporcionando así
evidencia significativa para refutar la hipótesis
nula. JSON y XML proporcionan fortalezas
únicas, pero la importancia del rendimiento y
la utilización de los recursos debe entenderse
al tomar decisiones entre los formatos de
intercambio de datos. Este estudio de caso ha
proporcionado un punto de referencia claro
que puede utilizarse para comparar estos
formatos al seleccionar un mecanismo de
transporte. Tenemos la intención de continuar
y mejorar nuestras investigaciones de la
siguiente manera: 1) eliminar el cuello de
botella potencial en la red en nuestros
escenarios de prueba mediante el uso de
tarjetas de red Gigabit. Las tarjetas de red
Gigabit nos dan la capacidad de realizar casos
basados en el estrés para ver qué formato de
intercambio de datos maneja conexiones
múltiples de manera más efectiva. Las tarjetas
de red Gigabit también nos dan la capacidad
de obtener métricas de casos mientras el
servidor está bajo carga pesada, y 2) realizar
una encuesta para comparar los tiempos de
aprendizaje de JSON y XML para ver qué
formato tiene una curva de aprendizaje más
pronunciada.