> From: Cristian S [mailto:[EMAIL PROTECTED]
> Frankly I have no ideea what's the point of loading almost
> 400M of data in memory in a HashMap.
> Maybe this very approach has a design flaw when it comes to JAVA.
If it's expensive to generate / load that data and the app has tight
response time restrictions, and if there's enough RAM to keep the data
in main memory without paging, and if the heap is large enough to allow
other processing to take place, and if the map is set up so that there
are few collisions, then the map is a very sensible approach.
That's a lot of ifs.
I'd try the following:
- Check for paging traffic on your server. Are other apps causing
Tomcat to be paged out, leading to expensive disk I/O when the map is
accessed?
- Follow Chuck's suggestion to check for garbage collection activity.
If possible, try increasing the Java heap size (and check for paging
activity on the server).
- Talk to your dev team to find out how well or badly the map is keyed.
A HashMap with a lot of entries can be slow if the hash for the key is
poor. I'd expect to see high CPU usage *or* high paging activity if
this was the case, as the server will either spend a lot of its time
hashing or have to load a lot of pages from backing store to examine
them for hash keys. Neither is pleasant.
Java HashMaps aren't inherently slow; something's poorly configured.
Those are a few guesses, no more than that. I also suspect it's *not*
your CPU cache size. Yes, going to RAM is slower than loading from a
processor cache line, but it's still a *lot* faster than retrieving a
row from the database. I'd be looking elsewhere. Intel have spent a
lot of money making people think that the CPU is the only contributor to
overall system speed; RAM and disk I/O speeds play a much larger part
these days.
- Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
