[vworld-tech] Java scaling

Alex Chacha achacha at hotmail.com
Sat Apr 30 17:35:36 PDT 2005


ceo wrote:
>...but now I *know* you're doing something very, very wrong, or you're 
>running something incredible (like a Euler-esque physics engine, or a 
>distributed raytracer), because java scales fairly effortlessly to 500 
>clients these days (i.e. use the sun tutorials aimed at newcomers to the 
>language, and you should see 500 clients straight away).

Let me give you two scenarios where I have direct experience with java.

1. The MMORPG I am working on part time (labor of love more than anything 
else).  The data transfer is currently TCP/IP based (directx client and 
several backend implementation since I am trying to figure out which would 
work best).  There are 10 worker threads and 1 listener/queue thread.  The 
design works great, but the quest and tradeskill engine is still using 
simple data for testing, so I am not yet CPU bound.  I tried loading up the 
machine in this scenario and hit a wall when I had 50 remote clients.  CPU 
utilization was about 70% but the JVM was spending a lot of time in context 
switches.  I didn't really debug this much but ported the code to C++ and 
it's working much much better, with CPU utilization at 10% for the process 
and about 10th context switches (I forget exact numbers, just remember an 
order of magnitude difference).  This was done using Sun's JVM 1.4.1_06 
originally and not using msvc++.  Python was my early implementation and I 
occasionally use python for quick and dirty simulation.

2. Where I am currently doing time of hard labor, we get about a billion 
hits a day.  With C++ backend the whole thing ran with 40 machines, we 
ported to java and pushing 1500 machines to keep the same response times 
(and this is after EJB was dumped due to dismal performance).  Now before 
you say something is really wrong, we have almost 1000 people working full 
time at optimizing, tuning, debugging and coding (not including the massive 
IT and operations groups).  We commited to java as a way of life, but with 
it we accepted that the performance will be awful give the complexity of the 
system (lots of database interaction, messaging, logging, and tons of 
external services, etc).  I can see a MUD work fine with java, but as long 
as it is not too CPU intensive.

Now for even more issues to note with Java:
1. Client implementation (unless you mean telnet like text emulation) is 
going to be very very tough.  The UI parts change between versions and 
something written for v1.3 will not look right with v1.4 and v1.5 (and vice 
versa).  To add to this, I have ran into more versions of java installed 
than I cared to note.  Trying to enforce a version on the client side is 
also a messy endeavor.  After trying a ver revisions on v1.3 and v1.4, we 
scrapped the java client and wrote 2 versions, one in MFC and another in QT.

2. Not all JVMs are implemented the same.  Recently I ran into a nasty bug 
with a JVM I was using (one from IBM WebSphere). Every time I ran the same 
class (it read a file, looked for a pattern, did some processing and 
returned a count, no randomness anywhere).  I would get slightly different 
results, a non-deterministic JVM was a surprise.  I switched to Sun JVM and 
no problems.  How could code that can be consistently executed on one JVM, 
have non-deterministic behavior on another?  To make things worse, Sun JVM 
1.4 had output A, Sun JVM 1.5 had output B (but both consistent).  IBM JVM 
went between A and B in what appeared a random way.  This one got me 
worried, I'll have to figure out exactly why this occurs.  But determinism 
is important and makes me worry about consistencies between various JVMs.

Again, this is just my experience.

I am a big fan of python, java and c++ as those 3 are my primary languages 
for tasks that suit them (python for scripting, java for some implementation 
that is not speed dependent (like tools, DB access, maintenance, etc) and 
C++ for server engine and client engine.  I try not to use something for the 
sake of technology, different problem requires a different tool (I do keep 
an open mind, who knows maybe JVM 1.5.x will be so good at managing multiple 
threads that I may use that for server design, time and testing will tell).

What type of work do you use java for on the back end?




More information about the vworld-tech mailing list