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.
Introduccion.

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.

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

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.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 2. Escenario 1 JSON vs. XML CPU / Mem

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

Tabla 4. Escenario 2 JSON 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.