[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