This is a new list of things to look at to help you when working with DWR. Please add comments on the things that have helped you...
The useLoadingMessage() function in DWR 1.0 has some flaws (like you can't customize the message and you need to be a bit careful when you call it) You can fix these flaws with some simple cut and paste of a new version of this function. The documentation for useLoadingMessage() has more details.
DWR does some fairly verbose error reporting, which can help a lot in working out what has gone wrong with your application. If there is anything wrong you should take careful note of messages when your container is starting and when the error happens. Generally errors will be output at the WARNING or ERROR levels, but reading INFO level messages might help too.
If you do get log message telling you something is wrong, but need to know more, make sure you can read INFO level messages because DWR sometimes outputs informational log messages with background information when something has gone wrong.
Another useful helper when something is broken is the debug/test pages (See http://localhost:8080/[YOUR-WEBAPP]/dwr). Basic use of these pages is covered in the getting started guide, but it's worth remembering when things are broken because sometimes these pages will give you more information about what is going wrong.
You can access HttpServletRequest and associated objects.
It's common to need to pass extra information to a callback method, but since all callback methods have only one parameter (the return code from the remote method) this can be tricky. There is a whole page dedicated to helping you with this problem.
CPU bottlenecks: DWR has been looked at by some fairly serious performance gurus who told us that DWR was basically irrelevant to performance. Time spent inside DWR is swamped by the web server and by the network. If you really need to tighten things up then you should reduce logging to error and fatal levels only, but the main job will be looking at your own code.
Network bottlenecks: Starting with version 2.0 DWR manages cache lifetime so the browser does not read more data than it needs to. Previous versions of DWR may leave the browser assuming that it needs to re-read the DWR javascript more often than it really does.
There is a simple solution to this issue in version 1 - copy the JavaScript files into your web-app and refer to them from there so the webserver can do what it is good at. You could also consider merging all your JavaScript files into a single file and running the DOJO compressor on them to save more space.
The situation in DWR 2.0 is slightly more complex because engine.js is dynamically generated, so you should not include this file in any compression scheme when using 2.0. We hope to remove the need for the dynamic parts of engine.js in version 2.1 and to add an inline script compressor.