2

We have in-house a 3rd party java application on a ridiculously hefty Linux box that runs a scheduling algorithm. The application runs far too slow for the load we need. We do not have the code and the vendor won't be making any changes to the application due to monetary reasons, thus I can't improve the code. The application is single threaded and its design does not lend itself to parallelization (so I can't split the load between 2 boxes).

What can I, either software or hardware wise, do to improve performance of the application?

AngryHacker
  • 59,598
  • 102
  • 325
  • 594
  • What is the application doing? Reading/writing some files on disk perhaps? – piokuc Jun 07 '12 at 16:41
  • Try to threaten or bribe it... *"if you don't run faster, I will wipe you off the hard disk!"* / *"if you run faster, you can get some free CPU time and I will introduce you to a nice female program"* :-) – Péter Török Jun 07 '12 at 16:41
  • @piokuc The app reads from a huge file, runs an algorithm for several hours, then writes the results back to the file. The time spent reading/writing to disk is negligible. – AngryHacker Jun 07 '12 at 16:43
  • When you say "the load you need", does this mean you run a lot of jobs against it, or you just run one gigantic job? – Brendan Long Jun 07 '12 at 16:47
  • 1
    @BrendanLong One gigantic job. – AngryHacker Jun 07 '12 at 16:53

4 Answers4

6

  • Get on the newest version of Java (newer versions tend to have performance improvements)

  • Give Java more memory to work with (benchmark to see if this makes any difference)

  • Measure what it's doing with top. Upgrade whatever it's having problems with (more memory, faster CPU, SSD). Some CPUs are better at single threaded work loads than others (read: don't run this on a Bulldozer; something with Turbo Boost might be helpful).

  • Play with other experimental JVM options (benchmark to see if this makes any difference)

  • Remove any other applications running on this machine (benchmark to see if there's any benefit -- no sense wasting money if it doesn't help)

  • Pay the vendor to make it faster or give you the code (ie: give them monetary reasons to fix this)

  • Find an alternative

  • Write your own alternative

Community
  • 1
  • 1
Brendan Long
  • 53,280
  • 21
  • 146
  • 188
  • 1
    It's worth noting that a large portion of the "experimental JVM options" are tuning the garbage collector. I've found based on past experience that the GC and Memory are the two biggest things you can tune to achieve better performance. – Matt Jun 07 '12 at 18:36
  • If this algorithm does use a lot of memory (it's not clear if it does), it could definitely benefit from a larger heap, and maybe the multi-threaded garbage collector. It really depends on what it's doing though. I can imagine useful algorithms that are pretty much entirely CPU-bound. – Brendan Long Jun 07 '12 at 20:06
  • @BrendanLong It takes a massive amount of memory. It maxes out at 100 GB. The heap has already been setup, so I can't do much more there. – AngryHacker Jun 07 '12 at 23:25
1

1) You can improve the hardware that the application runs on. Do this by looking at what resources the application is using. Is it maxing out CPU, or using all the memory (or both)? If so, you can add more CPU power or RAM accordingly.

2) Is there a way you can cache the results from the application? Can you ever avoid using it?

Otherwise, there really isn't much more you can do. If becomes a bigger problem, you might have to write your own scheduling algorithm, or better yet, find a better vendor.

Oleksi
  • 12,947
  • 4
  • 56
  • 80
1

Can you preprocess the input so the application has less work to do?

For example, perhaps the first thing the application does is sort the list of jobs to be scheduled using a merge sort. If you pre-sort the list, then the application's sort will have no work to do. You might be able to sort the list faster than the application can - use many cores, do it ahead of time, etc.

Tom Anderson
  • 46,189
  • 17
  • 92
  • 133
1

Run it on a faster computer. This is probably the cheapest solution of the lot.

user207421
  • 305,947
  • 44
  • 307
  • 483