Our Doctor, always busy.

Christmas 2011: The Doctor, the Widow and the Wardrobe

Ohm, I saw this episode a long time ago, so my memory of it is not that great. I liked the teleporting box and the whole mystery. I usually don’t like the Christmas episodes, but this one was all right.

Our Doctor just loves bow ties

Asylum of the Daleks (S07E01)

The Daleks kidnap the Doctor, Amy and Rory and throw them to a prison plant. On that planet there are Daleks which went crazy, and a souffle backing woman. And somehow the souffles never turn out well. Why does she keep backing souffles? Why did the Daleks send the Doctor to the prison?

I love the craze Dalkes and woman in this episode. Is fun!

The Daleks are also busy.

Dinosaurs on a Spaceship (S07E02)

The Doctor goes to a Spaceship, which has lost it’s pilot. To our surprise there are Dinosaurs on the spaceship. And a bad guy.

I didn’t like the story, but Dinosaurs are always awesome!

Dinosaurs, uuiiihh!

A Town Called Mercy (S07E03)

UUUAAAH, a western episode, with a evil robot, a alien and gun wielding men. Why does the evil robot hates this small city? Why is there a alien in the city?

I love the western with sci-fi genre. The story itself is OK.

The good, the bad and the ugly!

The Power of Three(S07E04)

Boring episode ㅠㅠ. The episode wants to become mysterious. Strange black cubes suddenly appear. The cubes don’t do anything. Therefore our team has to wait, and wait, and wait.

I already said that i found this episode to be boring.

Many boxes!

The Angels Take Manhattan(S07E05)

In New York a private investigator receives a strange case. Angel statues which seem to move. However, no one sees them moving, yet they move. So, the detective goes into a hotel, where he meets a old himself. What is going on?

Ah, I like the Weeping Angels. And this episode. It has a lot of time traveling and Weeping Angels. It’s the best episode of series 7 so far.

Weep, Weep, Weep

Christmas 2012: The Snowmen(S07E06)

Suddenly there are many snowmen and they are evil. Also the souffle making woman is here. Strange!

Hmm, I think the episode is OK.

Love Snowmen

Conclusion

So far I enjoyed series 7. I’m waiting for the new episodes. On March 30th the BBC will start airing the new episodes. Here are some trailers:

Series 7, First Half

Series 7, Second Half

우리 닥터, 항상 바빠요

2011년 크리스마스: The Doctor, the Widow and the Wardrobe

엄, 저는 이 에피소드 오래 봤어서 기억 잘 못 해요. 이 텔레포트 하는 상자하고 미스테리 좋아요. 저는 크리스마스-에피소드 보통 안 좋아요, 근데 이 에피소드 괜찮아요.

우리 닥터는 나비 넥타이 정말 좋아요

Asylum of the Daleks (1회)

다렉들는 (Daleks) 덕터이랑 에이미(Amy)랑 로리(Rory)를 유괴했고 감옥에서 보냈어요. 감옥에는 미친 다렉이 사는데. 그리고 우리 미친 여자도 살아요. 이 여자는 항상 수플레를 만들어봐요. 근데 수플레가 항상 잘 안돼요. 왜 여자 수플레를 뭇 만들어요? 왜 다렉 덕터를 감옥에서 보냈어요?

저는 이 에피소드의 미친 다렉하고 미친 여자 좋아요. 재미있어요.

다렉도 바빠요 ^^

Dinosaurs on a Spaceship (2회)

덕터는 조종사 없는 우주선 갔어요. 우주선에서 공룡이 있고 나쁜 사람 하나 있어요.

음, 저는 그 이야기를 별로 안 좋아요. 근데 공룡은 항상 재미있어요. ^^

공룡이, 우우우이

A Town Called Mercy(3회)

오오오와, 서부극 에피소드예요. 나쁜 로봇이랑, 외계 의사랑, 권총 있는 사람들이랑요. 왜 나쁜 로봇이 이 적은 도시 싫어요? 왜 외계가 있어요?

저는 서부극 장르와 SF 장르 좋아요. 이야기는 괜찮아요.

좋은 사람, 나쁜 사람과, 추한 사람이예요

The Power of Three(4회)

심심한 에피소드예요. ㅠㅠ. 이 에피소드는 미스테리 되고 싶은데. 이상한 검은 상자 갑자기 많이 있어져요. 이 상자는 아무것을 안 해서 우리 팀 기다려야 돼요. 기다리고, 기다리고, 더 기다려야 돼요.

저는 이 에피소드 심심해라고 벌써 말했어요. 안 좋아요.

상자 많아요.

The Angels Take Manhattan(5회)

뉴욕에는 탐정이 이상한 사건을 받았어요. 천사 조각상가 움직일 수 있는 것 같아요. 근데 아무도 조각상을 움직이는 것을 보여요, 하지만 조각상이 움직여요. 그리고 탐정은 호텔에서 낡은 탐정의 자신 만나요. 무슨 일이에요?

아, 저는 우는 천사 (weeping angels) 좋아요. 이 에피소드도 좋아요. 시간 여행 많고, 우는 천사 많아요. 시즌 7에 지금까지 에피소드 제일 좋아요.

울어, 울어, 울어.

2012년 크리스마스: The Snowmen(6회)

갑자기 눈사람들은 많아져요. 그리고 나빠요. 그리고도 수플레 하는 여자 다시 있어요. 이상해요.

음, 그 에피소드 괜찮는 것 같아요. 응.

눈사람 좋아요

그럼…

이제까지 전 시즌 7 좋아했어요. 새로운 에피소드를 기다리고 있어요. 4월 30일에 BBC는 새 에피소드를 보낼 거예요. 여기 트레일러도 있어요:

시즌 7, 첫 부분

시즌 7, 둘째 부분

The setup looked like this:

- Amazon EC2: Mysql Extra Large instance
- Two Amazon EC2: M1 Large instance as web tiers. Running the Play Application.
- Two Amazon EC2:M1 Medium instance as load tiers. Using Grinder to run scripts which use the web app.

We take a look at latency and throughput.

Test Setup

Blog-App

First let’s look a small blog app. The app serves posts, which have tags and authors. So the application gets the latest posts and fetches the tags for each post. Also it shows the most popular tags.

A blog

Latency in Blog Application

We can see that with ADBCJ requests are completed faster. For example with JDBC, it takes around 50ms on average to return the result; the ADBCJ version can do it in about 38ms.

Let’s also look at the throughput. In a small, focused test, where we access the index page in JSON format, ADBCJ performs way better. However, in a more realistic scenario, where we access different pages, the throughput of ADBCJ was about the same.

Blog: Latency vs Throughput

So you are now might tempted to use ADBCJ for a blog like application. Think again, a blog is fairly static application. So we can easily use caching to store the rendered pages. A good cache beats JDBCs and ADBCJs asses! Adding a cache boosts throughput and latency.

Blog: Latency vs Throughput

Blog: Latency With Caching

User Content App

Let’s look at a more dynamic application, a “Facebook” clone. The main page lists posts from the people a person follows. Each post has ‘likes’ and comments. Also the site suggests users to follow. Furthermore it also contains messages, which user can send to each other.
About 50% of the requests require complex read operations, the other 50% are simple writes, like inserting a new comment.

First, let’s look again at the latency. We can see that the complex read operation suddenly is three times faster. However, all writes requests are slowed down. This is maybe a tradeoff which you can make. Reading requests are the ones where users have to wait, while write requests can be done in the background via AJAX.

Latency User Content App

So, I wondered if there a fundamental issue with ADBCJ for writes, or if it’s an interaction effect. I ran test with separate read and write requests only. Then ADBCJ has always better latency. So, it seems to be an unfortunate interaction.

Reads / Writes Only

Finally, let’s take a throughput. ADBCJ does way better. Even more, when the system is under pressure, also ADBCJ’s latency for writes start to get better compared to JDBC.

Throughput User Content

Latency under large Load

Stats Collection App

The last application is a ‘stats collection app’, which collections information about the user’s actions. It is very write heavy, with only some rare, long running reads. Here JDBC and ADBCJ latency was about the same. However, the throughput of ADBCJ was much better.

Stats Collecting

Stats App Throughput

Conclusion

So, ADBCJ can speed up your web applications. Of course, only the data serving parts. Keep in mind caching, avoiding requests etc). Of course you need to do your own experiment for your use case. Next time I’m going to explain why ADBCJ can support better latency and throughput, with code examples. Stay tuned!

ADBCJ and Scala, new buddies

Grabbing the Bits

Of course, first we need to grab the bits. We can get it via SBT. Currently there are only snapshots available on my snapshot repository. We pull the Scala ADBCJ API, the ADBCJ connection pool and the MySQL driver.

Getting Access to the Database

The next step is to get access the the database. We do this with the Database object, by passing in the connection URL, username and password. This create a instance which is used to access this database. Usually you should have one instance only per database in your application.

Then we can create new connections. The most basic way is to create a connection directly. However, you are then responsible for closing the connection.

Closing Connections Automatically

Now closing the connection manually can be error prone and tedious. Therefore helper methods exists. One for using a connection and one for using a connection with a new transaction.
The closure has to return a future. Since everything is asynchronously, we cannot close the connection when we leave the future. Instead we need to close it when everything is done. So, the connection will be close, when the future returned by the closure is completed.

Some Real Work

Let’s do some real work. We create the schema if it doesn’t exist and then insert a few items. In general, I highly recommend to read the Akka documentation about futures, which gives an idea how to deal with tem.

Query

Let’s also query for some data. When running queries, your future will contain a immutable result set, which supports the standard collection operations.

Prepared Statements

Of course, there prepared statement support:

One Last Hint, Debugging

So, this was a small tour through the API. However I want to share one last important thing, which helps you dealing with failures.

Let’s assume you ran a back query:

org.adbcj.mysql.codec.MysqlException: 42S02Table 'adbcj-demo.thistabledoesnotexist' doesn't exis 
  at org.adbcj.mysql.codec.packets.ErrorResponse.toException(ErrorResponse.java:49)
	at org.adbcj.mysql.codec.decoding.ExpectQueryResult.handleError(ExpectQueryResult.java:31)
	at org.adbcj.mysql.codec.decoding.ResponseStart.parse(ResponseStart.java:33)
	at org.adbcj.mysql.codec.decoding.AcceptNextResponse.parse(AcceptNextResponse.java:26)
	at org.adbcj.mysql.codec.MySqlClientDecoder.doDecode(MySqlClientDecoder.java:96)
	at org.adbcj.mysql.codec.MySqlClientDecoder.decode(MySqlClientDecoder.java:67)
	at org.adbcj.mysql.netty.Decoder.decode(MysqlConnectionManager.java:177)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:113)
	...

Then you get a future which contain the error. However, the stack trace of the error does not contain any hint where in the code the query was issues. It just contains a stack trace with the internal event loop:

You can use the debug flat to get a stack trace which points at the location which sent the request. Either add -Dorg.adbcj.debug=true to the JVM flags. Or set the appropriate property when crating the database access. Note that this feature is quite expensive, so I recommend to use it while developing or during an investigation.

So, that’s it for now. Future posts will go into more aspects of ADBCJ the interaction with Scala.

I’ve been continuing work on this, mainly on the basics, the ADBCJ driver implementation . Here’s a overview of the updates:

• Simple connection pool: This helps to avoid the costs of creating connections. It also gives a nice control how many connections are used.
• H2-Support: Implemented a driver for the H2 database
• MySQL Driver Restructuring: The driver has been massively simplified, mainly in term of synchronization. This makes it easier to debug and reason about it.
• DBFuture implementation moved to CAS operations instead of locks: Less overhead, simplifies implementation and avoids potential dead locks
• Dropped PostgreSQL driver for now: I never maintained that driver, so I dropped it for now. If someone has interrest in a PostgreSQL driver, talk to me.
• Countless bugfixes

H2? What? Ah, the database.

Connection Pool

In the JDBC world connection pools are the standard. And this has it’s reasons. Connection to a database needs some initial work. With a connection pool this overhead is avoided. Plus it gives you control how many connections are used. ADBCJ has now a connection-pool too.

First you need to add the pool implementation to your project:

libraryDependencies += "org.adbcj" % "adbcj-connection-pool" % "0.5-SNAPSHOT"

After that you add the prefix pooled to the connection string. This will load the ADBCJ connection pool. For examples:

ConnectionManager plainMysql 
      = ConnectionManagerProvider.createConnectionManager(
            "adbcj:mysql://localhost/adbcjtck", "root", "");

ConnectionManager pooledMysql 
      = ConnectionManagerProvider.createConnectionManager(
            "adbcj:pooled:mysql://localhost/adbcjtck", "root", "");

The connection pool can be configured by providing properties for it. Here are the supported properties with the defaults:

Map<String,String> poolConfig = new HashMap<String, String>();
poolConfig.put("pool.maxConnections","50");
poolConfig.put("pool.maxWaitForConnection","500");

ConnectionManager pooledMysql
  	= ConnectionManagerProvider.createConnectionManager(
  		"adbcj:pooled:mysql://localhost/adbcjtck",
		"root",
		"",
		poolConfig);

H2-Support

I really like the H2 database. It’s simply to handle, embed, run and operate. I often use it for smaller projects, testing, default embedded database and so on. So no wonder, I’ve added support for it. You can add it via Maven/sbt.

First you need to add the driver to your project:

libraryDependencies += "org.adbcj" % "h2-async-driver" % "0.5-SNAPSHOT"

And then you can use the driver:

// Plain connection
ConnectionManager h2 
       = ConnectionManagerProvider.createConnectionManager(
       	  "adbcj:h2://localhost:14242/adbcjtck;MVCC=TRUE",
  	  "sa",
	  "sa");

// With connection pool, recommended
ConnectionManager h2Pooled 
       = ConnectionManagerProvider.createConnectionManager(
       	   "adbcj:pooled:h2://localhost:14242/adbcjtck;MVCC=TRUE",
	   "sa",
	   "sa");

Restructuring Synchronization of MySQL driver

The synchronization of the requests and running operations in the MySQL driver was quite complex. This caused a lot of head aches fixing race conditions and finding errors. I’ve rewritten the internal synchronization of the MySQL driver to be simpler and more understandable.
Another side effect is, that the driver now pipelines request much more aggressively. This should improve performance in some scenario drastically. The cost of this is that most requests cannot be cancelled anymore for now.

Source, etc.

The source is still on GitHub (https://github.com/gamlerhart/adbcj). Also remember that I’ve a improved Scala-API here.

The stuff is on my Maven-Repo:
https://github.com/gamlerhart/gamlor-mvn/raw/master/snapshots

Group-ID and Version for all ADBCJ projects:
GroupID: org.adbcj
Version: 0.5.0-SNAPSHOT

API:
ArtifactID: adbcj-api

Mysql:
ArtifactID: mysql-async-driver

H2:
ArtifactID: h2-async-driver

Connection-Pool:
ArtifactID: adbcj-connection-pool

That’s it for now =)

Testing Collections, Ahoi

The Google Guava Testlib brings a whole test suite which tests the behavior of Set, List and Map implementations. You can specify which features your collections support and then profit from the hundreds of tests Google has written for you.

Getting Started

First we need to get the library. The easiest way to get it is with Maven:

<dependency>
	<groupId>com.google.guava</groupId>
	<artifactId>guava-testlib</artifactId>
	<version>13.0</version>
	<scope>test</scope>
</dependency>

After that we can start to write a test suite. There are test-suite builders for this purpose, the most important ones are ListTestSuiteBuilder, SetTestSuiteBuilder and MapTestSuiteBuilder. These builder allow you to create a test-suite according to your needs.
First you specify the collection to be used and the test data with the using-method. Afterwards you can specify what features are implemented by your collection. Here’s an example:

Take a good look into the available constants in CollectionFeature, ListFeature and MapFeature for the features sets to test.
Anyway, BAAAMM! Now I’ve already a huge suite of test running, which cover a lot of dirty details. For example my implementation seems to have issues with the equals method of the returned sub-lists:

Oh Oh

Setup/Tear-Down, Suppressing Tests

Now the actual tests do run in already written test classes. So what if your collection needs some setup- / tear down code? For example I use the test-suite to test collections which are backed up by a database. That means I need a setup- / tear down phase.
This can be done by providing a runnable for the setup and tear down:

You also can suppress very specific methods of the test suite. This is done by giving the methods which should be suppressed:

Your Own TestData

Perhaps your collection implementation can only hold very specialized elements. In that case you might need to generate the test-items yourself, which are added to the list. Instead of using the Google test data provider, you can use your own. Here’s an example, which tests the collection with a custom type:

Other Types

Above I’ve shown examples for a List implementation. For Sets and Maps it works more or less exactly the same way. Instead of ListSomeThingSomething the classes are called SetSomethingSomething or MapSomethingSomething. Otherwise the same principals apply.

Conclusion

If you ever implement your own Java collections, take a look at the Guava Test lib. It saves you a ton of work!

I just recently started to look into some J2EE stuff. Still feels super scary. Don’t want to say much more about it. Yes,  J2EE got a lot better, but is still a giant monster. And don’t worry, there are tons of other monsters out there which are as scary as J2EE.

Misfits 3 (Wikipedia, Trailer)

I’ve already covered Misfits here. And Misfits it still damn good, I really can recommend it. The third season is maybe even the best one. I especially love the Zombie episode. If you like fantasy series, and haven’t tried Misfits yet, give it a watch.

Star-O-Meter: (4.5/5) (Yes, I even slightly increased it).

Zombies! Run!

It’s Always Sunny in Philadelphia (Wikipedia, Trailer)

May people really like this sitcom. Therefore I’ve watched one season. However I didn’t really like it. Usually I enjoy black comedy. This series is for me just average, but not great. So I stopped watching after the first season.

Star-O-Meter: (2.5/5)

You don’t wanna go to this bar.

Psych (Wikipedia, Trailer)

In this series a guy who can remember anything pretends to be a psychic. With his abilities he help the police solving difficult cases. Psych is a humor-full detective series, which I quite like. When it’s boring this series is nice to kill a hour or two.

Star-O-Meter: (3/5)

There are no ghosts, but big lies

Pretty Little Liars (Wikipedia, Trailer)

After a young woman dies, her 4 friends receive strange texts on their phones from a unknown person. These message contain secrets and lies of them. Who sends those messages? Who does he or she know all secrets? The plot sounds interesting, but the series isn’t. I found it rather boring.

Star-O-Meter: (2/5)

Hello. Hello? Hello??!!??

Mad Man (Wikipedia, Trailer)

Mad Man is boring. Don’t know why people like it.

Star-O-Meter: (1.5/5)

In Mad Man people really don’t work

Life Special Investigation Team (DramaWiki)

Life Special Investigation Team is another of these countless crime stories series. This time about insurance fraud. It’s alright. However it has really strange poop/fart ‘jokes’ in there. The aren’t even jokes, just strange scenes.
Star-O-Meter: (2.5/5)

People go crazy because of insurance money

Dream High 1 and 2 (Wikipedia, Trailer)

I really like Glee . Dream High is a series about music, so I expected something like Glee. However Glee is way better than Dream High. The first season is alright, but not great. The second season is the worse than the first one.

Star-O-Meter: (2.0/5)

Dreaming

When It’s At Night (DramaWiki)

In this series Heo Cho Hwi searches for old national treasures to then put them in museum. I really like the first episode, which is quite awesome. However after the first episode it gets more and more boring.

Star-O-Meter: (1.5/5) (However, for the first episode 3.5/5)

Catch the thief!

Mary stayed out all Night (Wikipedia)

I first though this drama revolves around some kind of marriage frauds. However it’s about an arranged marriage and love and so I lost interest. And the lead actress looks like a 14 old girl and not like the 20-25ish she’s supposed to be. Totally miss casted for this role.

Star-O-Meter: (0.5/5)

A fraud marriage is fun

Secret Garden (Wikipedia)

o.O, WOW, this thing is horrible, horrible, horrible. I cannot believe how bad this thing is (In fact, I watched the whole thing, just to see if it stays that bad). The story is a mess, I hate every character in it, the story makes no sense. Only Ha Ji Won’s character is alright. I probably could rage an hour about how bad it is.

Star-O-Meter: (0.0/5)

The secret garden is in the secret forest.

Office Girls (Wikipedia)

Office Girls is also bad. Especially the music is obnoxious, it always the some crappy song. And also the sound mix is horrible. The volume between voices, music and background is inconsistent and often ill balanced. Only the comic relief characters Liu Yu Le(劉禹樂) and Shi Ta Long(史特龍) are a little bit funny.

Star-O-Meter: (0.0/5)

Yep, who want’s to work?

Korean Peninsula (Wikipedia, Trailer)

In this series North- and South Korea together try to research on a new fuel source. However this dangerous project suffers an terror attack and all people are having a hard time.
I found this thing boring and stopped watching it quickly. (Maybe it get more interesting later on?)

Star-O-Meter: (1.5/5)

Three, Two, One….BAAAAAAAAMMMMM!

Conclusion

I watch to many TV series.

Misfits 3시즌 (Wikipedia, 트레일러)

난 벌써 Misfits에 대해 여기에서 썼어요. 그리고 Misfits는 아직 매우 재미있고 좋아하는데, 이 시리즈 추천해요. 3시즌도 아마 가장 좋은 시즌이 있어요. 특히 그 좀비-삽화 너마 재미있어요. 당신 판타지 시리즈를 좋아하고 Misfits 아직 보지 않았으면 봐보세요.

제 평가: (4.5/5) (네, 난 평가를 조금 조금 늘어났어요).

좀비야! 빨리 가!

It’s Always Sunny in Philadelphia (Wikipedia, 트레일러)

많이 살암들은 이 코미디 시리즈를 매우 좋아하는데, 그래서 난 시즌을 하나 봤어요. 근데 별로 안 좋아해요. 난 블랙 유머를 자주 즐겨요. 근데 이 시리즈가 괜찮지만 놀랍지 않나요. 그래서 난 1시즌 후에 보는걸 끝냈어요.

제 평가: (2.5/5)

그 술집에서 가고 안 싶어요!

Psych (Wikipedia, 트레일러)

이 시리즈에서 다 기억한 남자는 심령술사 사람인 척하고 경찰 도와요. 그리고 어려운 범죄 사건 풀어 도와요. Psych는 유머로 범죄물 있는데 넌 꽤 좋아해요. 혹시 심심할 때 이 시리즈 보는 것 괜찮아요.

제 평가: (3/5)

귀신이 없어요. 근데 근 거짓말해요.

Pretty Little Liars (Wikipedia, 트레일러)

이 시리즈에서 어린 여자가 죽은 후에 친구 4명은 모른 사람한테서 이상은 핸드폰에 메시지를 받아요. 그 메시지에 비밀과 거짓말이 있어요. 누구 그 메시지를 보내고 있어요? 왜 다 비밀이 알아요? 이 이아기가 흥미있는 것 같지만 흥미가 없어요. 난 이 시리즈에 심심했어요.

제 평가: (2/5)

여보세요? 여보세요? 여보세요?!!!!

Mad Man (Wikipedia, 트레일러)

Mad Man도 매우 심심해요. 왜 많이 사람 이 시리즈 좋아한 걸 말라요.

제 평가: (1.5/5)

Mad Men에서 사람들은 절대 일을 안해요

라이프 특별조사팀 (위키백과)

라이프 특별조사팀는 범죄물 이고 보험 속이 얘기하는데. 이 드라마도 괜찮아요. 근데 이상 똥-장면 몇개 있어요.

제 평가: (2.5/5)

사람은 보험 돈 때문에 미쳤어요

드림하이(Dream High) 1하고 2 (위키백과, 트레일러)

나는 Glee 아주 좋아해요. 드림하이 음악 관한 드라마에요, 그래서 드림하이 Glee처럼 기대했어요. 근데 Glee가 드림하이보다 더 좋아하는데. 드림하이 1는 괜찮아요, 하지만 대단 안 해요. 그리고 드림하이 2가 드림하이 1보다 더 나빠요.

제 평가: (2/5)

꿈 꾸다

밤이면 밤마다 (위키백과)

이 드라마에서 허초희씨 오래 된 국보를 찾아보고 박물관에서 가져가요. 난 1삽화를 매우 좋아했어요. 근데 1삽화 후에 이 드라마가 점점 심심해져요.

제 평가: (1.5/5) (하지만 1삽화의 평가 3.5/5 이다)

도둑이 잡아라!

매리는 외박중(위키백과)

나는 처음에 이 드라마가 속이 관한 이야기이라고 생각했는데. 근데 중매 결혼하고 사랑이 이야기 있어서 내가 관심 없어요. 심심한 것 같아요. 그리고 이끌 여자배우 14살 아이처럼 보이지만, 20-25살된 여자가 연기해요. 그 출연 나빠요.

제 평가: (0.5/5)

속인 결혼이 재미있어요.

시크릿 가든 (위키백과)

(O.o) 이 드라마가 너무 너무 너무 나빠요! 나는 시크릿 가든이 나쁜것 못 믿어요. 이야기 나쁜데, 난 모든 캐릭터를 너무 싫어하고, 이야기 이해하지 않아요. 하지원씨의 캐릭터만 괜찮아요.

제 평가: (0/5)

비밀 정원은 비밀 숲에 있어요

Office Girls (Wikipedia)

Office Girls도 너무 나빠요. 음악도 나쁜데, 같은 나쁜 노래 항상 들려요. 그래도 소리의 볼륨 나쁘게 믹스했어요. 코믹 릴리프있은 Liu Yu Le(劉禹樂)하고 Shi Ta Long(史特龍)가 조금 재미있어요.

제 평가: (0.5/5)

그럼, 누구 일하고 싶어요?

한반도 (위키백과, 트레일러)

이 드라마에서 한국과 북한 함께 과학로 연료 연구하는데. 그 위험한 프로젝트가 테러 행위 받았는데 모두 사람들이 힘들어 시간이 보내요.
난 그 드라마를 심심한 것 같아요. 난 빨리 그만 봤어요.

제 평가: (1.5/5)

셋, 돌, 하나, 파아아아암~~~~~~~~~~~~~~~~~

결론은

난 너무 시리즈를 보고 있어요.

Racing Stuff

Good Benchmarking, Science for itself

Good benchmarking is a small science for itself. Creating a balanced benchmark, ensure equal conditions for multiple runs, cranking out usable numbers, do proper analysis etc. I didn’t do that. I just wrote some code, ran that stuff and compared the numbers.
In the end it heavily depends on your scenario anyway. For example when you run trivial queries against a local database, then JDBC will probably win, since it only blocks a thread very briefly. If you add web-like latencies to the database communication, then my ADBCJ solution has an huge advantage.

The Benchmark Scenario

This is basically the benchmark scenario which I measured. It simulates a web like application.

• A request comes in
• We query for the most important data. Also we query for some less important data. The more important data is returned asynchronously to the client first, while the other queries are still running. This should simulate a page, which first shows the important stuff and loads the rest in the back ground, like many websites do.
• When the first part of the result arrives at the client, another request is sent, which updates some data
• When all queries, updates and operations complete, we’re done. We measure the time between issuing the request and completing everything

For the plain JDBC implementation I used the Akka future API, to run that work in the background and continue with the other operations. The ADBCJ implementation relies on its asynchronous API.
For these number I ran the database locally, so there is no huge round trip overhead. Only the queries need a bit of time to complete, from sub milliseconds up the around 6 milliseconds.

Result, JDBC vs ADBCJ

Well ADBCJ is as expected faster for this task. Mainly because it can send new queries, while processing the in streaming result of previous queries. Maybe the JDBC implementation also ends up exhausting the thread pool with blocked threads, but I didn’t check it if that’s the case:

Here’s also a box plot of the data. There is quite a high variance in the data, and a few latency spikes:

JDBC vs ADBCJ

JDBC with Connection Pool, ADBCJ via JDBC bridge

Now this is a little unfair, since you usually use a connection pool for JDBC. And we didn’t check out the ADBCJ via JDBC fallback driver. So I ran the benchmark as well with the BoneCP connection pool and ADBCJ via JDBC.
Guess what, JDBC with a connection pool reacts the fastest. This means that a connection pool has a huge effect in this benchmark, since it opens and closes database connection often. The conclusion is that ADBCJ desperately needs its own connect pool implementation, to handle similar scenarios.
Another interesting fact is that ADBCJ via JDBC performs the worst here. It’s clear that it is probably a bit slower the JDBC version, because I manually split the JDBC calls reasonably across threads. The ADBCJ to JDBC bridge has no insight how to smartly dispatch the blocking calls. However the huge difference between JDBC and ADBCJ via JDBC is surprising. This could indicate that there are some implementation issues present in the ADBCJ to JDBC bridge.

Again a box plot of this data. Again high variance and quite a few spikes:

JDBC Connection Pool, ADBCJ via JDBC

High Load Performance

Well, I wanted to see if the picture doesn’t change if the load is much higher. So I cranked the executed request up, so that the machine is fairly busy. The database is still running locally. The picture doesn’t change much, maybe there is a tendency that the performance advantage of ADBCJ gets bigger. But I didn’t to more scaling testing to verify that.
Also the ADBCJ to JDBC bridge crashed, because it just issued way to many connections. Well, as mentioned, the ADBCJ to JDBC bridge is more testing facility anyway.

And again in a box plot:

Higher Load: JDBC vs ADBCJ

Conclusion

Well, don’t draw to many conclusion from these numbers. We certainly can see that ADBCJ can be faster for some scenarios. We also can clearly see, that the missing connection pool for ADBCJ is a huge performance penalty for many applications.