Hostmonster Performance Test Results

Created a very simple Java math execution loop with Thread.yield() calls after every calculation so it wouldn't hog all the CPU and hurt other user's performance. Executed with java1.6.0_13 with defaults. The program was executed only a few times (< 12) and never more than a few seconds (< 5). The program spawned 8 worker threads with no contention so there was one for each CPU.

Execution times were observed as low as ~900 nS on Hostmonster vs. ~1500 nS on my laptop running Ubuntu 8.10, see additional specs and cpu info below.

Monitoring top, and running the test program very briefly (< 5 sec), the CPU% peaked at 589% - WOW!

Of course as a hosting service, and considering Java and GC, the performance vs. memory utilization, I/O performance, and availability are more important.

Hostmonster system:

From set:
x86_64-redhat-linux-gnu

From top:
Mem:  16473136k total, 15851752k used,   
        621384k free,    653060k buffers
Swap:  8193108k total,   235480k used,  
       7957628k free,   9983168k cached

ifconfig revealed static IP is VIP

cat /proc/cpuinfo revealed 8 CPUs

uname -a
Linux host305.hostmonster.com 2.6.28-9.16.intel.BHsmp #1 
SMP Sat Apr 18 11:41:59 MDT 2009 x86_64 x86_64 x86_64 GNU/Linux

processor : 7 of 0-7
vendor_id : GenuineIntel
cpu family : 6
model  : 23
model name : Intel(R) Xeon(R) CPU           E5420  @ 2.50GHz
stepping : 6
cpu MHz  : 2500.085
cache size : 6144 KB
cpu cores : 4
fpu  : yes
fpu_exception : yes
cpuid level : 10
wp  : yes
flags  : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm tpr_shadow vnmi flexpriority
bogomips : 4999.28
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual


My local system as performance reference:

vendor_id : GenuineIntel
cpu family : 6
model  : 23
model name : Intel(R) Core(TM)2 Duo CPU     T6600  @ 2.20GHz
stepping : 10
cpu MHz  : 1200.000
cache size : 2048 KB
siblings : 2
cpu cores : 2
fpu  : yes
cpuid level : 13
wp  : yes
flags  : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni monitor ds_cpl est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips : 4389.48
clflush size : 64

Comments

Post a Comment

Popular posts from this blog

Sites, Newsletters, and Blogs

BLOGS Java.net Weblogs Martin Fowler's blog Paul Graham Ruminations of a Programmer Form Follows Function Newsletters Core Java Tech Tips Enterprise Java Tech Tips JavaSpecialists.EU TheServerSide.com Sites Java.net Today Hot Java Sites CSS Zen Garden Evernote Hacker News Pragmatic Programmer
Read more

Oracle JDBC ReadTimeout QueryTimeout

If a query exceeds the oracle.jdbc.ReadTimeout without receiving any data, an exception is thrown and the connection is terminated by the Oracle driver on the client. Unfortunately the session will still be queued on the database and continue to wait for locks, hold any current locks, and complete any DML/PL*SQL procedures that are pending on the server-side of the orphaned connection. If an application, on a another connection, due to ReadTimeout exception, retries DML/PL*SQL  which requires locks, those queries will queue behind the initial DML/PL*SQL. This will increase the workload exacerbating the situation. On applications with retries, this can be observed by querying the v$session table  or gv$session on RAC and noting new sessions started periodically based on the ReadTimeout interval. The sessions may often have the same SQL_ID and/or SQL_HASH_VALUE. If stmt.setQueryTimeout(Seconds) is issued and the statement exceeds the timeout, it will atte...
Read more

Locks held on Oracle for hours after sessions abnormally terminated by node failure

If a session holds db locks and is abnormally terminated (no fin/ack), the locks will persist until the db session is closed, typically around 2 hours and 12 minutes with default network tcp_keepalive settings. Abnormally terminated does not include CTRL C or kill -9. The ojdbc6 driver apparently has a shutdown hook thread that closes the connections in graceful shutdowns. The OS apparently closes the connections when processes are killed. Abnormally terminated might include power failure, firewall failures, Out Of Memory, OS/kernel crash, network connection failure, JBoss or other server node failure, etc. This was easily reproduced by creating a  process that connected to the db and updated a record but did not commit. While the first process was waiting, a second process with a contending update was started which blocked on the first update. The first clients network cable was then disconnected. The second clients transaction waited for approximately 2 hours until the databa...
Read more