자바 성능 강의
DESCRIPTION
자바 성능 튜닝 강의TRANSCRIPT
Java Perfor-mance Tuning조대협
인사 !!
조대협
• 개발자• 웹로직 기술 지원 엔지니어• 장애 진단 , 성능 튜닝• 컨설턴트 (SOA,EAI,ALM,Enterprise 2.0)• 아키텍트 ( 대용량 분산 시스템 )• APAC 클라우드 수석 아키텍트• 프리렌서• 지금은 Chief(Cheap?) 아키텍트
블로그 : http://bcho.tistory.com이메일 : [email protected]
ICEBREAK
질문 : 성능이란 ??
• 안나오면 파트장님한테 깨지는 것• 다음은 그룹장님에게 깨지는 것• 막판은 실장님에게 소환 당하는 것• 동시에 처리할 수 있는 트렌젝션의 양과 ,
응답시간 . (TPS & Response Time)
오늘은 ?
• 성능 엔지니어링• 자바 애플리케이션의 병목 구간 발견• JVM 튜닝• 잡다한 자바 성능팁
성능 엔지니어링
• 언제 ?
성능 엔지니어링
• 접근 방법• 문제의 정의 : 느려요 (X)
• Break down ( 구간 )• Isolate• Narrow down• Bottleneck 발견• 해결
성능 엔지니어링
• 필요한것은 ? 도구 : 부하테스트 도구 , 모니터링 도구 , 프로파일링 도구
역량 : FIN_WAIT 가 모지 ?
전문 지식 : 내부구조가 어떻게 되지 ?
경험 그리고 집요함 !! 이것이 포인트 !! ( 여기서
다 갈림 )
Chapter 1. 자바 애플리케이션의 병목 구간 찾아내기
일반적인 자바 서버 애플리케이션의 구조
User AP
WAS
JVM DBMSWeb Server
Network
Client
Legacy
기본지식
• 쓰레드 풀링
Thread Pool
Idle Thread(Waiting)
request
Thread Pool
Working Thread(Handling request)
request
response
Thread Pool
Working Thread
기본 지식
• 자바 쓰레드 상태 전이
Runnable
newstart
BlockedSleep/done sleep
Wait/no-tifySuspend/Re-sume
Block on IO/IO complete
dead
stop
<< Thread State Diagram >>
- Runnable : running- Suspended,Locked : waiting on monitor entry / waiting on condition /MW- Wait : Object.Wait()
일반적인 자바 서버의 구조
• 대부분 비슷WebServerOR BrowserOR Client
Dispatcher
Request Queue
ThreadPool
ConnectionPool
Thread Queue
JMS Thread Queue
APP1 Thread Queue
APP2 Thread Queue
Other ResourcesConnector
Working Thread
IdleThread
대부분 Queue + Thread Pool 구조(Tomcat,Jboss,WebLogic 등 )
쓰레드 덤프
• Thread dump– Snapshot of java ap (X-ray)– We can recognize thread running
tread state by “continuous thread dump”
Slow down in WAS & User AP
• Getting Thread Dump– Unix : kill –3 pid , Windows : Ctrl + Break– Get thread dump about 3~5 times be-
tween 3~5secsThreads
Time
Working thread
Thread dump
Slow down in WAS & User AP
• Thread dump– It displays all of thread state by
“THREAD STACK”
"ExecuteThread: '42' for queue: 'default'" daemon prio=5 tid=0x3504b0 nid=0x34 runnable [0x9607e000..0x9607fc68]
at java.net.SocketInputStream.read(SocketInputStream.java:85) at oracle.net.ns.Packet.receive(Unknown Source) at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:730) at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:702) at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:373) at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1427) at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java:911) at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:1948) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2137) at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:404) at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:344) at weblogic.jdbc.pool.PreparedStatement.executeQuery(PreparedStatement.java:51) at weblogic.jdbc.rmi.internal.PreparedStatementImpl.executeQuery(PreparedStatementImpl.java:56)
Thread name Thread id (signature)Thread State
Program stack of this thread
Sun JVM
Slow down in WAS & User AP
• How to analysis thread dumpMYTHREAD_RUN(){ 1 call methodA();} methodA(){
//doSomething(); 2 call methodB();} methodB(){
//call methodC(); 3}
methodC(){
// doSomething 4 for(;;){// infinite loop } 5}
“MYTHREAD” runnable 1at …MYTHREAD_RUN(): “MYTHREAD” runnable 2at …methodA() at …MYTHREAD_RUN(): “MYTHREAD” runnable 3at …methodB()at …methodA()at …MYTHREAD_RUN(): “MYTHREAD” runnable 4at …methodC()at …methodB()at …methodA()at …MYTHREAD_RUN():
“MYTHREAD” runnable at …methodC()at …methodB()at …methodA()at …MYTHREAD_RUN():
계속 이모양이반복됨
Source codeThread dumps
Slow down in WAS & User AP
• CASE 1. Lock contention– In the java application java thread wait
for lock in synchronized method– Occurred in multi threaded program– Reduce frequency of synchronized
method– Synchronized block must be imple-
mented to be end as soon as possible (※ IO? )
public void synchronized methodA(Object param){ //do something while(1){}}
< sample code >
Slow down in WAS & User AP
• CASE 1. Lock contention
Thread1 Thread3
Thread2
Thread4
Sychronized MethodA
Threads
Time
Thread1 – That has a lock
Thread 2.3.4 – waiting for lock
Slow down in WAS & User AP
• CASE 1. Lock contention : Thread dump example"ExecuteThread: '12' for queue: 'weblogic.kernel.Default'" daemon prio=10 tid=0x0055ae20 nid=23 lwp_id=3722788 waiting for monitor entry [0x2fb6e000..0x2fb6d530]
:at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
:at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)at org.apache.axis.utils.XMLUtils.getSAXParser(XMLUtils.java:252)- locked <0x329fcf50> (a java.lang.Class)
"ExecuteThread: '13' for queue: 'weblogic.kernel.Default'" daemon prio=10 tid=0x0055bde0 nid=24 lwp_id=3722789 waiting for monitor entry [0x2faec000..0x2faec530]
at org.apache.axis.utils.XMLUtils.getSAXParser(XMLUtils.java:247)- waiting to lock <0x329fcf50> (a java.lang.Class) :
"ExecuteThread: '15' for queue: 'weblogic.kernel.Default'" daemon prio=10 tid=0x0061dc20 nid=26 lwp_id=3722791 waiting for monitor entry [0x2f9ea000..0x2f9ea530]
at org.apache.axis.utils.XMLUtils.releaseSAXParser(XMLUtils.java:283)- waiting to lock <0x329fcf50> (a java.lang.Class)at
Slow down in WAS & User AP
• CASE 2. Dead lock– CWC “Circular waiting condition”– Commonly it makes WAS hang up– Remove CWC by changing lock direction– Some kind of JVM detects dead lock au-
tomatically
sychronized methodA(){ call methodB();}sychronized methodB(){ call methodC();}sychronized methodC(){ call methodA();}
< sample code >
Slow down in WAS & User AP
• CASE 2. Dead lock
Thread1
Sychronized MethodA
Thread2
Sychronized MethodB
Thread3
Sychronized MethodC
Threads
Time
Thread 1
Thread 2
Thread 3
Circular waiting condition
Slow down in WAS & User AP
• CASE 2. Dead lockFOUND A JAVA LEVEL DEADLOCK:----------------------------"ExecuteThread: '12' for queue: 'default'": waiting to lock monitor 0xf96e0 (object 0xbd2e1a20, a weblogic.servlet.jsp.JspStub), which is locked by "ExecuteThread: '5' for queue: 'default'""ExecuteThread: '5' for queue: 'default'": waiting to lock monitor 0xf8c60 (object 0xbd9dc460, a weblogic.servlet.internal.We-bAppServletContext), which is locked by "ExecuteThread: '12' for queue: 'default'" JAVA STACK INFORMATION FOR THREADS LISTED ABOVE:------------------------------------------------Java Stack for "ExecuteThread: '12' for queue: 'default'":========== at weblogic.servlet.internal.ServletStubImpl.destroyServlet(ServletStubImpl.java:434) - waiting to lock <bd2e1a20> (a weblogic.servlet.jsp.JspStub) at weblogic.servlet.internal.WebAppServletContext.removeServletStub(WebAppServletContext.java:2377) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:207) : Java Stack for "ExecuteThread: '5' for queue: 'default'":========== at weblogic.servlet.internal.WebAppServletContext.removeServletStub(WebAppServletContext.java:2370) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:207) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:154) - locked <bd2e1a20> (a weblogic.servlet.jsp.JspStub) at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:368) : Found 1 deadlock.========================================================
Deadlock auto detect in Sun JVM
Slow down in WAS & User AP
• CASE 2. Dead lock"ExecuteThread-6" (TID:0x30098180, sys_thread_t:0x39658e50, state:MW, native ID:0xf10) prio=5at oracle.jdbc.driver.OracleStatement.close(OracleStatement.java(Compiled Code))at weblogic.jdbc.common.internal.ConnectionEnv.cleanup(ConnectionEnv.java(Compiled :
"ExecuteThread-8" (TID:0x30098090, sys_thread_t:0x396eb890, state:MW, native ID:0x1112) prio=5at oracle.jdbc.driver.OracleConnection.commit(OracleConnection.java(Compiled Code))at weblogic.jdbcbase.pool.Connection.commit(Connection.java(Compiled Code)) :
sys_mon_t:0x39d75b38 infl_mon_t: 0x39d6e288: oracle.jdbc.driver.OracleConnection@310BC380/310BC388: owner "ExecuteThread-8" (0x396eb890) 1 entry 1)
Waiting to enter: "ExecuteThread-10" (0x3977e2d0) "ExecuteThread-6" (0x39658e50)
sys_mon_t:0x39d75bb8 infl_mon_t: 0x39d6e2a8: \ oracle.jdbc.driver.OracleStatement@33AA1BD0/33AA1BD8: owner "ExecuteThread-6" (0x39658e50) 1 entry 2)
Waiting to enter: "ExecuteThread-8" (0x396eb890
Deadlock trace in AIX JVM
Slow down in WAS & User AP
• CASE 3. Wait for IO Response– Situation in waiting for IO response
(DB,Network)– Commonly occurred caused by DB lock-
ing or slow responseThreads
Time
Wait for IO response
Slow down in WAS & User AP
• CASE 3. Wait for IO Response"ExecuteThread: '42' for queue: 'default'" daemon prio=5 tid=0x3504b0 nid=0x34 runnable [0x9607e000..0x9607fc68] at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:85) at oracle.net.ns.Packet.receive(Unknown Source) at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.net.ns.NetInputStream.read(Unknown Source) at oracle.jdbc.ttc7.MAREngine.unmarshalUB1(MAREngine.java:730) at oracle.jdbc.ttc7.MAREngine.unmarshalSB1(MAREngine.java:702) at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:373) at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1427) at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java:911) at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:1948) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2137) at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:404) at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:344) at weblogic.jdbc.pool.PreparedStatement.executeQuery(PreparedStatement.java:51) at weblogic.jdbc.rmi.internal.PreparedStatementImpl.executeQuery(PreparedStatementImpl.java:56) at weblogic.jdbc.rmi.SerialPreparedStatement.executeQuery(SerialPreparedStatement.java:42) at com.XXXX 생략 at ……..
Slow down in WAS & User AP
• CASE 4. High CPU usage– When monitoring CPU usage by
top,glance. WAS process consumes a lot of CPU - almost 90~100%
– Find it using tools below• Sun : prstat,pstack,thread dump• AIX : ps –mp,dbx,thread dump• HP : glance,thread dump• See a document “How to find bottleneck in
J2EE application “ in http://www.j2eestudy.co.kr
Slow down in WAS & User AP
• CASE 4. High CPU usage– Example in HP UX
HP glance
1. Start “glance”2. Press “G” and enter the
WAS PID3. Find the TID that con-
sumes a lot of CPU re-source
4. Get a thread dump5. Find the thread in Thread
dump that has a matched LWID with this TID
6. And find the reason and fix it
Slow down in WAS & User AP
• Summarize– Thread dump is snapshot of Java Appli-
cation.– If u meet a slowdown situation, Get a
thread dump.– Analysis thread dump.– And fix it..
결론은…
이것저것 어려우시면 그냥 툴을 사서 쓰세요 . !!Jennifer APM
Chapter 2. JVM 튜닝
Generational Garbage Collection
JVM Memory Layout
• New/Young – Recently created object• Old – Long lived object• Perm – JVM classes and methods
Eden Old Perm
New/Young Old
Used in Application App binary
Total Heap Size
SS1 SS2
Garbage Collection
• Garbage Collection– Collecting unused java object– Cleaning memory– Minor GC
• Collection memory in New/Young generation
– Major GC (Full GC)• Collection memory in Old generation
Minor GC
• Minor Collection– New/Young Generation– Copy and Scavenge – Very Fast
Minor GC
Eden SS1 SS1
Copy live objects to Survivor area
New Object
Garbage
Lived Object
1st Minor GC
Old
Old
Old
Minor GC
2nd Minor GC
Old
Old
Old
New Object
Garbage
Lived Object
Minor GC
OLD
3rd Minor GC
Objects moved old space when they become tenured
New Object
Garbage
Lived Object
Major GC
• Major Collection– Old Generation– Mark and compact– Slow
• 1st – goes through the entire heap, marking unreachable objects• 2nd – unreachable objects are compacted
Major GC
Eden SS1 SS2
Eden SS1 SS2
Mark the objects to be removed
Eden SS1 SS2
Compact the objects to be removed
Server option versus Client option
• -X:NewRatio=2 (1.3) , -Xmn128m(1.4), -XX:NewSize=<size> -XX:MaxNewSize=<size>
GC Tuning Parameter
• Memory Tuning Parameter– Perm Size : -XX:MaxPermSize=64m– Total Heap Size : -ms512m –mx 512m– New Size
• -XX:NewRatio=2 Old/New Size• -XX:NewSize=128m• -Xmn128m (JDK 1.4)
– Survivor Size : -XX:SurvivorRatio=64 (eden/survivor)– Heap Ratio
• -XX:MaxHeapFreeRatio=70• -XX:MinHeapFreeRatio=40
– Suvivor Ratio• -XX:TargetSurvivorRatio=50
Support for –XX Option
• Options that begin with -X are nonstandard (not guaran-teed to be supported on all VM implementations), and are subject to change without notice in subsequent releases of the Java 2 SDK.
• Because the -XX options have specific system require-ments for correct operation and may require privileged ac-cess to system configuration parameters, they are not rec-ommended for casual use. These options are also subject
to change without notice.
Garbage Collection Model
• New type of GC– Default Collector– Parallel GC for young generation - JDK 1.4– Concurrent GC for old generation - JDK 1.4 – Incremental Low Pause Collector (Train GC)
Parallel GC
• Parallel GC– Improve performance of GC– For young generation (Minor GC)– More than 4CPU and 256MB Physical
memory required
threads
timegc
threads
Default GC Parallel GC
Young Generation
Parallel GC
• Two Parallel Collectors– Low-pause : -XX:+UseParNewGC
• Near real-time or pause dependent application• Works with
– Mark and compact collector– Concurrent old area collector
– Throughput : -XX:+UseParallelGC• Enterprise or throughput oriented application• Works only with the mark and compact collector
Parallel GC
• Throughput Collector– –XX:+UseParallelGC– -XX:ParallelGCThreads=<desired number>– -XX:+UseAdaptiveSizePolicy
• Adaptive resizing of the young generation
Parallel GC
• Throughput Collector– AggressiveHeap
• Enabled By-XX:+AggresiveHeap• Inspect machine resources and attempts to set various parameters to be op-
timal for long-running,memory-intensive jobs– Useful in more than 4 CPU machine, more than 256M– Useful in Server Application– Do not use with –ms and –mx
• Example) HP Itanium 1.4.2 java -XX:+ServerApp -XX:+AggresiveHeap -Xm-n3400m -spec.jbb.JBBmain -propfile Test1
Concurrent GC
• Concurrent GC– Reduce pause time to collect
Old Generation– For old generation (Full GC)
– Enabled by -XX:+UseConcMark-SweepGC
threads
timegc
threads
Default GC Concurrent GC
OldGeneration
Incremental GC
• Incremental GC– Enabled by –XIncgc (from JDK 1.3)– Collect Old generation whenever collect young generation– Reduce pause time for collect old generation– Disadvantage
• More frequently young generation GC has occurred.• More resource is needed• Do not use with –XX:+UseParallelGC and –XX:+UseParNewGC
Incremental GC
• Incremental GC
Minor GC
After many time of Minor GC
Full GC
Minor GC
Minor GC
Old Generation is collected in Minor GC
Default GC Incremental GC
Young Generation
OldGeneration
Incremental GC
• Incremental GC-client –XX:+PrintGCDetails -Xincgc –ms32m –mx32m
[GC [DefNew: 540K->35K(576K), 0.0053557 secs][Train: 3495K->3493K(32128K), 0.0043531 secs] 4036K->3529K(32704K), 0.0099856 secs][GC [DefNew: 547K->64K(576K), 0.0048216 secs][Train: 3529K->3540K(32128K), 0.0058683 secs] 4041K->3604K(32704K), 0.0109779 secs][GC [DefNew: 575K->64K(576K), 0.0164904 secs] 4116K->3670K(32704K), 0.0169019 secs][GC [DefNew: 576K->64K(576K), 0.0057541 secs][Train: 3671K->3651K(32128K), 0.0051286 secs] 4182K->3715K(32704K), 0.0113042 secs][GC [DefNew: 575K->56K(576K), 0.0114559 secs] 4227K->3745K(32704K), 0.0191390 secs][Full GC [Train MSC: 3689K->3280K(32128K), 0.0909523 secs] 4038K->3378K(32704K), 0.0910213 secs][GC [DefNew: 502K->64K(576K), 0.0173220 secs][Train: 3329K->3329K(32128K), 0.0066279 secs] 3782K->3393K(32704K), 0.0325125 secs
Young Generation GC Old Generation GC in Minor GC TimeMinor GC
Full GC
Sun JVM 1.4.1 in Windows OS
Garbage Collection Measurement
• -verbosegc (All Platform)• -XX:+PrintGCDetails ( JDK 1.4)• -Xverbosegc (HP)
Garbage Collection Measurement
• -verbosegc
[GC 40549K->20909K(64768K), 0.0484179 secs][GC 41197K->21405K(64768K), 0.0411095 secs][GC 41693K->22995K(64768K), 0.0846190 secs][GC 43283K->23672K(64768K), 0.0492838 secs][Full GC 43960K->1749K(64768K), 0.1452965 secs][GC 22037K->2810K(64768K), 0.0310949 secs][GC 23098K->3657K(64768K), 0.0469624 secs][GC 23945K->4847K(64768K), 0.0580108 secs]
Full GC
Total Heap Size
GC Time
Heap size after GC
Heap size before GC
GC Log analysis using AWK script
• Awk script
BEGIN{ printf("Minor\tMajor\tAlive\tFree\n");}{ if( substr($0,1,4) == "[GC "){ split($0,array," "); printf("%s\t0.0\t",array[3])
split(array[2],barray,"K") before=barray[1] after=substr(barray[2],3) reclaim=before-after printf("%s\t%s\n",after,reclaim) }
if( substr($0,1,9) == "[Full GC "){ split($0,array," "); printf("0.0\t%s\t",array[4])
split(array[3],barray,"K") before = barray[1] after = substr(barray[2],3) reclaim = before - after printf("%s\t%s\n",after,reclaim) } next;}
% awk –f gc.awk gc.log
※ Usage
gc.awk
Minor Major Alive Freed0.0484179 0.0 20909 196400.0411095 0.0 21405 197920.0846190 0.0 22995 186980.0492838 0.0 23672 196110.0 0.1452965 1749 422110.0310949 0.0 2810 192270.0469624 0.0 3657 194410.0580108 0.0 4847 19098
gc.log
GC Log analysis using AWK script
< GC Time >
GC Log analysis using HPJtune
※ http://www.hp.com/products1/unix/java/java2/hpjtune/index.html
GC Log analysis using AWK script
< GC Amount >
Garbage Collection Tuning
• GC Tuning– Find Most Important factor
• Low pause? Or High performance?• Select appropriate GC model (New Model has risk!!)
– Select “server” or “client”– Find appropriate Heap size by reviewing GC log– Find ratio of young and old generation
Garbage Collection Tuning
• GC Tuning– Full GC Most important factor in GC tuning
• How frequently ? How long ?• Short and Frequently decrease old space• Long and Sometimes increase old space• Short and Sometimes decrease throughput by Load balancing
– Fix Heap size• Set “ms” and “mx” as same• Remove shrinking and growing overhead
– Don’t• Don’t make heap size bigger than physical memory (SWAP)• Don’t make new generation bigger than half the heap
Tools
• Visual VM
Tools
• Visual VM
쓰레드 상태 모니터링
Tools
• Visual VM
패키지별 , CPU 사용량 모니터링
Example
Example
2004-01-08 오후 7:14
2004-01-09 오전 8 시 전후
2004-01-09 오후 7 시 전후
금요일 업무시간
2004-01-10오전 10 시 전후
2004-01-10오후 6 시 전후
PEAK TIME52000~56000 sec9 시 ~ 1 시간 가량
Before TunedOld Area
Example
Peak Time 시에 Old GC 시간이 4~8 sec 로 이로 인한 Hang 현상 유발이 가능함
Before TunedGC Time
Example
12 일 03:38A12 일 05:58P13 일 07:18A13 일 09:38P14 일 11:58A15 일 01:18A15 일 03:38P16 일 05:58A16 일 07:18P17 일 08:38A17 일 10:58P
Weekend
Mon Office
Our
Tue Office
Our
Thur Office
Our
Fri Office
Our
After AP TunedGC Time
Example
12 일 03:38A12 일 05:58P13 일 07:18A13 일 09:38P14 일 11:58A15 일 01:18A15 일 03:38P16 일 05:58A16 일 07:18P17 일 08:38A17 일 10:58P
Weekend
Mon Office
Our
Tue Office
Our
Thur Office
Our
Fri Office
Our
Chapter 3. 잡다한 자바 코딩 성능 팁들 .
자바 코딩팁
• 잡다하지만 기본 적인 것들 적절한 Synchronized StringBuffer ( “+” vs append) Collection (Vector,List) 등은 사이즈를 초기화 하여 사용 Collection 보다는 Array. (Collection 은 사이즈가 변동되는
경우만 ) Collection 은 편하지만 알고 쓰세요 .!! (Synchronized 되어
있을 수 있음 ) DB 는 Index 필수 (DBA 에게 Profiling 부탁 !!. Slow
Query 튜닝 ) DB 는 Connection Pooling 필수 고성능은 DB Write/Read DB 분리 캐쉬 !! ( 할수있는건 다하자 !!- 파일 , 데이타… ) 대부분 IO 문제 - 파일 , 네트워크 ,DB 마이크로 벤치 마크 !! 필수 !!
자바 코딩팁
• Logging!!!! FILE IO. 전체 성능의 5~10% SL4J + LogBack 이 대세
• FILE IO FileWriter + BufferedWriter. ( 테스트해보고 하세요 ..)
Application Server
• HTTP 1.1 Keep Alive• DB Connection Pooling• 적절한 Working Thread 수• 불필요한 Logging 자제 !!
감사합니다 . :)