troubleshooting.rst 2.5 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758
  1. .. raw:: html
  2. <div id="banner"><a href="https://github.com/jcbrand/converse.js/blob/master/docs/source/setup.rst">Edit me on GitHub</a></div>
  3. =============================
  4. Troubleshooting and debugging
  5. =============================
  6. General tips on debugging Converse
  7. ==================================
  8. When debugging Converse, always make sure that you pass in ``debug: true`` to
  9. the ``converse.initialize`` call.
  10. Converse will then log debug information to the browser's developer console.
  11. Open the developer console and study the data that is logged to it.
  12. `Strope.js <http://strophe.im/>`_ the underlying XMPP library which Converse
  13. uses, swallows errors, so that messaging can continue in cases where
  14. non-critical errors occur.
  15. This is a useful feature and provides more stability, but it makes debugging
  16. trickier, because the app doesn't crash when something goes wrong somewhere.
  17. That's why checking the debug output in the browser console is so important. If
  18. something goes wrong somewhere, the error will be logged there and you'll be
  19. able to see it.
  20. Additionally, Converse will in debug mode also log all XMPP stanzas
  21. (the XML snippets being sent between it and the server) to the console.
  22. This is very useful for debugging issues relating to the XMPP protocol.
  23. For example, if a message or presence update doesn't appear, one of the first
  24. things you can do is to set ``debug: true`` and then to check in the console
  25. whether the relevant XMPP stanzas are actually logged (which would mean that
  26. they were received by Converse). If they're not logged, then the problem is
  27. more likely on the XMPP server's end (perhaps a misconfiguration?). If they
  28. **are** logged, then there might be a bug or misconfiguration in Converse.
  29. Performance issues with large rosters
  30. =====================================
  31. Effort has been made to benchmark and optimize Converse to work with large
  32. rosters.
  33. See for example the benchmarking tests in `spec/profiling.js
  34. <https://github.com/jcbrand/converse.js/blob/master/spec/profiling.js>`_ which
  35. can be used together with the `profiling features of
  36. Chrome <https://developer.chrome.com/devtools/docs/cpu-profiling>`_ to find
  37. bottlenecks in the code.
  38. However, with large rosters (more than 1000 contacts), rendering in
  39. Converse slows down a lot and it may become intolerably slow.
  40. One simple trick to improve performance is to set ``show_only_online_users: true``.
  41. This will (usually) reduce the amount of contacts that get rendered in the
  42. roster, which eases one of the remaining performance bottlenecks.