SJAVA :: HTTP://WWW.SJAVA.NET ::

고성능의 앱을 위한 아키텍처링..

from Thinks 2011/12/21 17:42

아래 내용은 제가 테스트한 내용이 아니라, 경험을 기반으로 제가 생각하는 고성능의 서비스를 위한 아키텍처링에 대한 내용입니다. 그리고, 아래 내용은 앱<->API 서버 간의 성능향상을 위한 방안에 대한 내용입니다.

요즘 상당히 많은 앱들이 네트웍으로 데이터를 전송받아서 랜더링하고, 유저가 만들어낸 데이터를 전송하기도 합니다. 그래서, 네트웍으로 데이터를 주고 받는 앱들은 서버(보통 웹서버)와의 통신에서 JSON을 표준(많이 사용하는 추세) 프로토콜처럼 사용하고 있습니다. JSON을 사용하는 아키텍처가 가지고 있는 성능저하 요소를 살펴보면, 아래의 목록을 예상할 수 있습니다.

- JSON의 사용은 파싱에 드는 비용, 데이터 사이즈로 인한 전송(3G 대비)속도 저하가 예상이 됩니다..
- HTTP/HTTPS 프로토콜을 사용하는 서버(웹 서버)를 사용해서, 연결과 데이터 전송과 수신에 오버헤드(HTTP 프로토콜의 헤더만 읽어봐도 이해가 되실 듯)가 발생합니다.

그래서, 위의 성능저하 요소를 걷어내고 고성능의 앱을 개발하기 위한 방법으로.. 아래의 방식을 고려할 필요가 있습니다.. 아래의 형태로 개발하게 되면, 개발 비용이 증가하는 단점이 있습니다.. 하지만, 네트웍을 많이 사용하는 앱(예로 카카오톡이나 채팅앱)이라면 연결기반의 프로토콜을 서버가 제공하고, 앱이 그 프로토콜을 사용한다면, 매번 연결하지 않고 네트웍으로 데이터를 보내고 받는 것이, 위의 비 연결지향의 프로토콜인 HTTP/HTTPS와는 비교할 수 없을 정도로 빠른것을 알게 될 것입니다..

- JSON 보다는 고 성능의 데이터 직렬화 라이브러리(MessagePack, Thrift, Google Protocol Buffers)를 사용한다.
- 소켓(SSL 적용) 서버(Netty 프레임윅 등으로 개발)로 연결지향 프로토콜 기반에서 데이터를 처리한다. 이 방식의 경우에는 소켓 서버에서 클라이언트의 idle time을 적절하게 계산해서 주기적으로 클라이언트의 소켓을 제거해 주는 로직이 필요합니다.. 이 로직이 없을 경우, file descriptor가 부족해 지겠죠.. ^^

당장은, 필요하다고 느끼지 못하거나, 너무 오버한다고 생각할 수 있으나, 기본적으로 유저가 많은 포털의 앱이나, 이미 많은 유저가 사용하는 앱들은 프로토콜과 데이터 형식만 바꿔도 상당한 성능향상을 가져올 수 있을 것이라 생각합니다.. ^^

'Thinks' 카테고리의 다른 글

2011년에 대한 포스트 모텀.. (0)	2012/01/22
고성능의 앱을 위한 아키텍처링.. (0)	2011/12/21
전 직장(M모사)에 대한 포스트 모텀 (4)	2011/07/21
관계를 좀 더 쉽게 풀어내는 방법 : Activity Stream ???? (0)	2010/11/17
reactor 프레임웍의 socketchannel의 read 메쏘드 호출을 어디에서?? (0)	2010/09/10

Tag // Google Protocol Buffers, http, https, json, messagepack, Netty, thrift, 고성능, 고성능 앱, 앱

받은 트랙백이 없고, 댓글이 없습니다.

JSON Validator/Formatter 사이트들..

from Tools 2011/11/29 10:31

JSON 포맷으로 데이터를 주고 받는 서버나 클라이언트 혹은 앱을 개발하다 보면, 보내고 받은 데이터의 포맷이 맞는지 그리고 받은 데이터를 디버깅하기 위해서 포맷팅을 해서 가독성있게 바꾸는 작업을 빈번하게 하게 됩니다.. 이 때, 프로그램상에서 로그나 콘솔에 포맷팅을 해서 가독성있게 보여줄 수 있겠지만, 여간 불편한게 아니죠..

보통, 웹 서버를 통해서 JSON 데이터를 받게되면, 스트림으로 주~욱 받게 됩니다.. 그러면, byte[]로 받아서 String으로 변환을 해서 포맷팅을 하든, 아파치 HTTPClient같은 넘을 사용해서 결과로 String을 받아오든지 합니다..

결국, 다시 한번 String을 포맷팅을 해야 가독성이 생기게 됩니다.. 그래서, 받은 String 데이터를 Validate와 Formatting을 해주는 사이트를 찾아서 받은 String 데이터를 넣어서 포맷팅된 JSON으로 보게 되네요..

그래서, 유용한 사이트를 몇개 정리해 봅니다..

1. http://www.freeformatter.com/
지원하는 Formatter와 Validator는 아래와 같이 매우 다양합니다.. 매우 다양한 포맷을 지원하기 때문에 개발하면서 매우 유용한 사이트가 될 것 같습니다..
- JSON Formatter & Validator :

- HTML Formatter & Validator :

- XML Formatter :

- SQL Formatter :

- String Escaper :

- Url Encoder / Url Decoder :

- Base 64 Encoder / Base 64 Decoder :

- JavaScript Minifier - Online YUI Compressor for JavaScript :

- CSS Minifier - Online YUI Compressor for CSS :

- Message Digest :

2. http://jsonlint.com/
JSON Formatter와 Validator로 가장 유명할 것으로 생각이 드는 사이트 입니다..

3. http://jsonformat.com/
JSON Formatter와 Validator를 지원하고 있고, 추가적으로 HTML Formatter도 지원하고 있네요..

4. http://jsonformatter.curiousconcept.com/
JSON Formatter와 Validator를 지원합니다..

위의 사이트중 한개만 즐겨찾기 해 놓으면, JSON 포맷 기반의 프로젝트 하기에 편할 것으로 생각이 듭니다..

'Tools' 카테고리의 다른 글

JSON Validator/Formatter 사이트들.. (0)	2011/11/29
Eclipse에서 XML의 attribute를 한줄로 표시하기.. (0)	2011/07/26
restfb 로그 console에 찍히는거 제거.. (0)	2011/03/08
eclipse의 xml editor plug-in rinzo xml editor (0)	2010/12/27
ant를 이용해서, lib 폴더의 denendency jar file을 manifest의 class-path에 손쉽게 추가하기... (0)	2010/11/09

Tag // css, formatter, json, Validator, XML

받은 트랙백이 없고, 댓글이 없습니다.

데이터 포맷별 성능 비교자료..

from Data 2011/11/21 16:33

요즘 데이터의 풍요속에서 데이터를 처리하기 위해서 필요한 데이터 전송 포맷이 매우 다양하죠..
따라서, 데이터를 네트웍으로 전송하기 위한 포맷을 선택하는 것이 시스템 전체적인 성능이나 유연성을 좌우하기에 매우 중요한 팩트가 되었습니다..

그래서, 데이터 포맷별로 테스트한 자료와 성능에 대한 검색자료를 정리해 봅니다.. ^^

1. Java Serialize Benchmarking

- 이 테스트 자료는 자바환경에서 https://github.com/eishay/jvm-serializers 프로젝트에서 테스트한 자료입니다.
- 테스트 결과중에 속도에 대한 차트만 첨부했습니다. 예전의 테스트 자료에서는 kryo가 protobuf보다 더 빠른 결과가 나왔었는데, 2011-07-13일 버전의 테스트 자료에서는 역전을 했네요.. ^^ 그리고, 위의 테스트 결과 위키에서의 답글(2011-10-27)을 보면, 테스트 결과에서는 kyro가 상당히 의미있는 결과를 보여주고 있네요.. 그리고 테스트 결과를 바탕으로 json 포맷을 지원하는 라이브러리 선택도 의미가 있을 것 같습니다.
- 이 테스트 자료는 상당히 방대한 자료에 대한 테스트를 진행했기 때문에 정말 유익합니다.. 꼭 자세히 살펴볼 필요가 있습니다.. 하지만, 최근(?)에 사용을 늘려가고 있는 MessagePack과 YAML에 대한 자료가 없는건 아쉽네요..

- 테스트한 결과에 대한 스냅샷을 위해서 .mht 파일로 첨부했습니다..

java seriliazers benchmarks(2011-07-13).mht

2. MessagePack에 대해서 고려한 카산드라..

- 카산드라 0.7버전에서 MessagePack을 thrift의 대안으로 고려를 했었습니다.. 물론 카산드라 버전에서 MessagePack 라이브러리를 살펴볼 수 없기 때문에 채택이 안되었겠죠.. ^^ 카산드라의 JIRA CASSANDRA-1735에서 카산드라 프로젝트의 의장인 Jonathan Ellis의 코멘트를 보면, 의미가 없었다고 하네요..

Gary did some tests in ~~CASSANDRA-1765~~ and found no significant advantage over Thrift. Given that, and our brief experience supporting a second rpc protocol (Avro in the 0.7 series), I don't think this is going anywhere.

- JIRA에서 살펴보면, 테스트 결과는 꽤 성능향상 이점(random read 15%, random write 21%)이 있어 보이긴 하네요.. 흠.. 위의 Jonathan Ellis의 코멘트가 사실이라면, 역시 테스트는 데이타에 따라 결과에 대한 차이가 상당한 것 같습니다..

Performance improvement available with this patch will be the following:

Reducing serialization cost and the data size

Increase throughput between clients and a Cassandra node

I have also measured the performance of MessagePack, from the viewpoints of reducing serialization cost and throughput. I will discuss details below.

== Reduction of serialization cost and the data size ==

(Summary)
MessagePack has proved to be better in reducing serialzation cost and the data size compared to other serialization libraries in the test below.

(Test environment)
I used "jvm-serializers" which is a well-known benchmark and compared performances with Protocol Buffers, Thrift, and Avro. Machine used for this benchmark has Core2 Duo 2GHz with 1GB RAM.

(Results)
　　　　　　create　　ser　+same　deser　+shal　+deep　total　size　+dfl
protobuf 　　　683　6016　2973　　3338　　3454　3759　9775　239　149
thrift 　　　　　572　6287　5565　　3479　　3616　3770　10057　349　197
msgpack 　　　291　4935　4750　　3468　　3545　3708　8748　236　150
avro　　　　　2698　6409　3623　　7480　　9301　10481　16890　221　133

(Comments)
It may be better to compare serialization cost using objects with Cassandra like a Column object. But such objects and sizes vary by users, and is not suitable for comparing serialization cost of various data. According to the above result, the size of MessagePack's serialized data is slightly larger than Avro. But MessagePack has significantly low serialization cost compared to Avro and Thrift.

== Increasing throughput ==

(Summary)
I compared MessagePack based RPC of Cassandra to that of Thrift. Random read throughput of MessagePack based RPC is 15% higher than that of Thrift and random write throughput is 21% higher.

(Test environment)
In this evaluation, Cassandra node ran as a standalone on a machine with Core2 Duo 2GHz and 1GB RAM. Client programs ran on two machines both with Core2 Duo 2GHz and 1GB RAM. Client program was based on ring cache. It created 100 threads per a JVM on each machine and accesses to a Cassandra node with ring cache.

(Results)

Thrift based RPC part of Cassandra(read: 5,200 query/sec., write: 11,200 query/sec.)

MessagePack based RPC part of Cassandra (read: 6,000 query/sec., write: 13,600 query/sec.)

(Comments)
I measured the max throughput of random access (read/write) after 100 items (size of each item is small) were stored in the Cassandra node. The reason is because I wanted to make the state of CPU bottle neck for the Cassandra node. If the Cassandra node is the state of Disk IO bottle neck, I thought that I cannot properly evaluate max throughput of the RPC part.

I did not measure the amount of data transferred in network during the evaluation directly. But from the benchmark result of jvm-serializers, I believe that the amount of transferred data for MessagePack-based Cassandra would be reduced compared to that of Thrift.

3. Serializing data speed comparison: Marshal vs. JSON vs. Eval vs. YAML

- 이 테스트 자료는 루비로 테스트를 했다고 하네요..

Last night at the NYC Ruby hackfest, I got into a discussion about serializing data. Brian mentioned the Marshal library to me, which for some reason had completely escaped my attention until last night. He said it was wicked fast so we decided to run a quick benchmark comparison.

The test data is designed to roughly approximate what my stored classifier data will look like. The different methods we decided to benchmark were Marshal, json, eval, and yaml. With each one we took the in-memory object and serialized it and then read it back in. With eval we had to convert the object to ruby code to serialize it then run eval against that. Here are the results for 100 iterations on a 10k element array and a hash with 10k key/value pairs run on my Macbook Pro 2.4 GHz Core 2 Duo:
                 user      system     total       realarray marshal  0.210000   0.010000   0.220000 (  0.220701)array json     2.180000   0.050000   2.230000 (  2.288489)array eval     2.090000   0.060000   2.150000 (  2.240443)array yaml    26.650000   0.350000  27.000000 ( 27.810609)

hash marshal   2.000000   0.050000   2.050000 (  2.114950)hash json      3.700000   0.060000   3.760000 (  3.881716)hash eval      5.370000   0.140000   5.510000 (  6.117947)hash yaml     68.220000   0.870000  69.090000 ( 72.370784)
The order in which I tested them is pretty much the order in which they ranked for speed. Marshal was amazingly fast. JSON and eval came out roughly equal on the array with eval trailing quite a bit for the hash. Yaml was just slow as all hell. A note on the json: I used the 1.1.3 library which uses c to parse. I assume it would be quite a bit slower if I used the pure ruby implementation. Here's a gist of the benchmark code if you're curious and want to run it yourself.

If you're serializing user data, be super careful about using eval. It's probably best to avoid it completely. Finally, just for fun I took yaml out (it was too slow) and ran the benchmark again with 1k iterations:
                 user      system     total       realarray marshal  2.080000   0.110000   2.190000 (  2.242235)array json    21.860000   0.500000  22.360000 ( 23.052403)array eval    20.730000   0.570000  21.300000 ( 21.992454)

hash marshal  19.510000   0.500000  20.010000 ( 20.794111)hash json     39.770000   0.670000  40.440000 ( 41.689297)hash eval     51.410000   1.290000  52.700000 ( 54.155711)



시스템을 설계하면서 네트웍으로 데이터를 전송/수신하기 위한 포맷은 위의 자료로 대부분 살펴본 것 같습니다. 

개발하는 시스템의 성격에 따라서 속도와 사이즈 어떤 것이 중요할지는 개발자의 판단이고.. 

이 자료가 매우 도움이 되었으면 좋겠습니다.. ^^

'Data' 카테고리의 다른 글

데이터 포맷별 성능 비교자료.. (0)	2011/11/21
.Net Framework 버전별 비교자료.. (2)	2011/07/18
C# Dataset Java 연동 및 soap vs json 이슈.. (0)	2011/07/18
Java Proactor 문서.. (0)	2011/07/18
microsoft application architecture guide v2 (2)	2010/07/23

Tag // avro, Cassandra, google protocol buffer, json, messagepack, protocol buffer, thirft, XML, YAML

받은 트랙백이 없고, 댓글이 없습니다.

C# Dataset Java 연동 및 soap vs json 이슈..

from Data 2011/07/18 18:45

예전에 C#의 Dataset을 Java와 연동하는 이슈로 soap vs json 포맷의 성능을 비교했던 자료입니다.

dataset_java_c#_.pdf

'Data' 카테고리의 다른 글

데이터 포맷별 성능 비교자료.. (0)	2011/11/21
.Net Framework 버전별 비교자료.. (2)	2011/07/18
C# Dataset Java 연동 및 soap vs json 이슈.. (0)	2011/07/18
Java Proactor 문서.. (0)	2011/07/18
microsoft application architecture guide v2 (2)	2010/07/23

Tag // c#, dataset, java, json, SOAP

받은 트랙백이 없고, 댓글이 없습니다.

json java 라이브러리 google-gson의 기본 캐릭터셋은 utf-8 이군요..

from Tools 2010/11/04 22:14

웹에 데이타를 전송해 주기 위해서, 데이타를 캐시하고 있는 서버에서 데이타를 json 포맷으로 가지고 있습니다.
라이브러리는 google-gson을 사용합니다.. json simple이나 jacson json processor에 비해서 속도는 뒤 떨어지지만, library의 사용성(?), 편리함(?) 때문에 사용을 하고 있습니다.. 데이타 저장을 위해서 json 포맷이다 보니, character set에 따라 크기, 즉 메모리나 데이타의 전송량이 달라지기 때문에, utf-8로 인코딩을 하고 byte[]의 길이를 체크해 보니.. 사이즈가 똑 같네요.. ^^;;
흠.. 소스 뒤져보니, utf-8로 인코딩을 하네요.. ㅋㅋ

http://code.google.com/p/google-gson/

http://google-gson.googlecode.com/svn/tags/1.5/docs/javadocs/index.html
http://sites.google.com/site/gson/gson-user-guide

'Tools' 카테고리의 다른 글

eclipse의 xml editor plug-in rinzo xml editor (0)	2010/12/27
ant를 이용해서, lib 폴더의 denendency jar file을 manifest의 class-path에 손쉽게 추가하기... (0)	2010/11/09
json java 라이브러리 google-gson의 기본 캐릭터셋은 utf-8 이군요.. (1)	2010/11/04
ROME Library를 이용한 Atom/RSS 읽어오기.. (0)	2010/10/26
eclipse에서 toString()을 자동으로 해 주네요.. ^^;; (0)	2010/10/25

Tag // google-gson, java, json, Library

받은 트랙백이 없고, 댓글 하나가 달렸습니다.

간단한 SOAP 메시지 콜

from Java 2010/05/26 15:34

아래처럼 SAAJ를 이용해서 SOAP 1.1 버전의 메소드를 호출해서 사용할 수 있다..
흠.. soap 보다는 json with rest 방식으로.. ^^;;

import java.io.ByteArrayInputStream;

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.soap.MessageFactory;
import javax.xml.soap.SOAPBody;
import javax.xml.soap.SOAPConnection;
import javax.xml.soap.SOAPConnectionFactory;
import javax.xml.soap.SOAPElement;
import javax.xml.soap.SOAPMessage;
import javax.xml.soap.SOAPHeader;
import javax.xml.soap.SOAPHeaderElement;
import javax.xml.transform.dom.DOMSource;

import org.w3c.dom.Document;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;

public class SoapClient implements IClient {

public static String soapActionUrl = "http://localhost/soap_http/test.asmx?op=GetPurchaseListWBC";

private SoapClient(){};

public static SoapClient newInstance() {
  return new SoapClient();
}

public static String getRequestMessage(int serviceCode, int uuid) {
  String query = "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n"
   + "<soap:Envelope xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" "
   +  "xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" "
   +  "xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\" >\n"
   //+  "xmlns:SOAP-ENC=\"http://schemas.xmlsoap.org/soap/encoding/\">\n"
   + " <soap:Body>\n"
   + "  <GetPurchaseListWBC xmlns=\"http://tempuri.org/\">\n"
      + "   <serviceCode>"+String.valueOf(serviceCode)+"</serviceCode>\n"
      + "   <uuid>"+ String.valueOf(uuid) +"</uuid>\n"
      + " </GetPurchaseListWBC>\n"
   + " </soap:Body>\n"
   + "</soap:Envelope>";
  return query;
}

public SOAPMessage request(String soapActionUrl) throws Exception {
  Document doc = null;
  DocumentBuilder docBuilder = null;
  DOMSource domSource = null;
  SOAPConnection connection = null;

  SOAPMessage resultMessage = null;

  try {
   docBuilder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
   doc = docBuilder.parse(new ByteArrayInputStream(getRequestMessage(1,2).getBytes()));
   domSource = new DOMSource(doc);

   SOAPMessage message = MessageFactory.newInstance().createMessage();
   message.setProperty(SOAPMessage.CHARACTER_SET_ENCODING, "utf-8");
   message.setProperty(SOAPMessage.WRITE_XML_DECLARATION, "true");
   message.getSOAPPart().setContent(domSource);
   message.getMimeHeaders().addHeader("SOAPAction", "http://tempuri.org/GetPurchaseListWBC");

   //String url = "http://localhost:1351/test.asmx?op=GetPurchaseListWBC";
   connection = SOAPConnectionFactory.newInstance().createConnection();
   resultMessage = connection.call(message, soapActionUrl);

   NodeList nodes = resultMessage.getSOAPBody().getChildNodes();

   for (int i = 0; i < nodes.getLength() ; i++) {
    Node node = nodes.item(i);
    this.traverse(node);
   }

  } finally {
   connection.close();
  }

  return resultMessage;
}

public void traverse (Node node) {
  String nodeName = node.getNodeName();
     String nodeValue = node.getNodeValue();

     if(!"#text".equals(nodeName))
     System.out.println("<" + nodeName +">");

     if (node.hasChildNodes()) {
     NodeList nodes= node.getChildNodes();
     for (int i=0; i<nodes.getLength(); i++) {
       traverse (nodes.item(i));
     }
     } else {
      System.out.println(nodeValue);
     }

     if(!"#text".equals(nodeName))
     System.out.println ("</" + nodeName +">");
}

}

'Java' 카테고리의 다른 글

#ifdef #ifndef in Java (0)	2010/06/15
멀티쓰레드 프로그램 평가기준 (0)	2010/06/01
간단한 SOAP 메시지 콜 (0)	2010/05/26
garbage collector (0)	2010/04/29
Circular Dependency Problem (0)	2010/03/26

Tag // json, Rest, saaj, SOAP

받은 트랙백이 없고, 댓글이 없습니다.

json simple library

from Tools 2010/05/18 17:13

헐 좋네용.. ^^

C#은 3.5버전부터 API 수준에서 json 포맷을 지원하니..
자바도 7부터는 지원을 했으면 좋겠네요.. ^^

http://code.google.com/p/json-simple/

'Tools' 카테고리의 다른 글

eclipse에서 apache ivy로 binary 의존성 확인 (0)	2010/06/22
무료 CAPTCHA 서비스 (0)	2010/06/16
json simple library (0)	2010/05/18
java c/c++, c# 호출방식 (0)	2010/04/29
eclipse에서 java source 보기 (0)	2010/03/16

Tag // json, Library

받은 트랙백이 없고, 댓글이 없습니다.