Static analysis for performance – the server side java symposium

Overall, I was disappointed by the session. Most of it was about the performance anti-patterns and i was expecting more about the static analysis tool. There was only one slide with an example of how to detect a pattern using static analysis and I found it hard to understand,  It is easy to say to tell new developers not to do something.  It is hard to detect programatically.   Nevertheless, the points made are valid and here are the notes.

Is Java slow? Not on Intel for C at least.

What are root causes of performance issues?

  • Bad architecture, code or design
  • Configuration
  • [or database/network and not java at all, but that’s out of scope here]
  • Many ways to write incorrect code. Static analysis is not a replacement for traditional performance tuning

Types of analysis:

  • Code query systems – Explore relationships among program elements, Codequest and jquery in this space
  • Semantic code query systens – focus on behavior in addition to structure.  Yonita is in this space.  Yonita starts with bytecode to capture all detail. Then query in sql or prolog to find anti-patterns
  • Note that yonita is a prototype and not yet publicly available

Redundant work
Examples

  • JSF calling output text and the getXXX<> method makes a database call each time
  • get value for key several time.  Ok if took like Hibernate is caching it for you
  • make the same ajax call twice and then do something different than the result

Fix by caching the value
Showed patterns for detecting, it looks complicated!

Other anti-patterns

  • Fine grained remote calls – entity beans versions 1 and 2
  • One by one processing – adding one at a time instead of batching so the transaction, authorization and database all happen repeatedly
  • Return a lot of records and discard the results

I asked if the static analysis tools could detect all of the anti-patterns shown. The answer was that it is library specific. I didn’t get a clear yes or no as to whether one could write a rule.

Someone asked about complex configurations. The answer was the tools struggle with dynamic configuration like Spring and specific support of the tool is required.

Making MySQL Use More Memory: Part 2

In a previous article, I discussed how to get the most out of your memory usage in MySQL systems using the InnoDB storage engine. To review, MySQL has overly conservative memory usage by default. Your MySQL instance may be using only a small fraction of the available memory, leading to unnecessarily poor application performance. In this article, I’ll discuss how to accomplish the same feat in a MyISAM storage engine.

One of the main variables for increasing the memory usage in MyISAM is the “key_buffer_size”, which is the key cache for MyISAM systems. Set “key_buffer_size” to be up to 25% of RAM, or at least a few hundred megabytes. For example, if you have 2GB of RAM, you may want to set it as follows:

key_buffer_size=500M

You can set this value up to 50% of available memory, although be careful to keep (key_buffer_size + innodb_buffer_pool_size) < 80% of available memory. Assuming your system is primarily an InnoDB xor a MyISAM system, only one of these values should be set large. Next, increase the size of the MyISAM sort buffer size. I don't really have a recommended size here, but a few hundred megabytes should suffice such as: myisam_sort_buffer_size=256M Some other less used parameters with suggested values: read_buffer_size=4M sort_buffer_size=4M myisam_max_sort_file_size=20G Note that the last parameter increases the temporary file space, not memory, but may lead to improved performance.

Making MySQL Use More Memory

Unlike a lot of database servers, MySQL is strangely conservative (by default) on how much memory it will allocate. If you’re not careful, you can have 16GB of RAM on your machine with MySQL only using 50MBs, leading to extremely poor performance under heavy load. I know firsthand that navigating MySQL configuration guides can be a daunting task, so I’ve prepared this post for those looking for a ‘quick fix’ to encourage MySQL to use a more healthy amount of memory.

Which database storage engine do you use primarily?

Many beginner users may not understand this, but with MySQL you have a choice in which storage engine implementation your database runs on. This is where performance tuning begins to get complicated, as you have to set the configuration variables that correspond to the storage engine you are using! You can see what engine you are relying on by opening MySQL Administrator and viewing your schema under the Catalogs tab. Each table should should have an engine associated with it, which likely says either MyISAM or InnoDB.

In this post, I’ll cover how to increase general memory usage for InnoDB:

Set “innodb_buffer_pool_size” to be up to 80% of RAM, or at least a few hundred megabytes. The default is 8MB and I imagine anyone running a MySQL server these days can at least spare 200 megabytes of memory, so it should at look like this:

innodb_buffer_pool_size=200M

Again, the default is 8M! So, if you’re not setting this variable, you’re choking your database. Feel free to give it 1-2GB if you have the available memory, but the most gain will be made by just going above the default.

There are more InnoDB settings you could set, but their benefits pale in comparison with the value you’ll gain by increasing this from the default of 8M.