Best Coding Practices

Knowledge base
, , , , , ,
1

Some of the efficient ways in which you could write your code, this would not just improve memory leaks, I/O overheads, threads blockage, etc. This would make a huge difference in the way your application performs. So enjoy reading and try implementing!!

  1. No Append to Doc List in a loop. Use Vector instead.
  2. Focus on the inner loop and not on the outer loop in case of nested loops
  3. Use reference of docs stops memory leaks, drop variables
  4. Transformer is better than service invoke as it has minimal overhead on pipeline
  5. Use Java svcs in case of CPU intensive like nested loops.
  6. Tune Java Svc by using StringBuffer instead of direct read/write as they call I/O directly or direct string concat ,etc..

Because String buffer creates one object however large the array while string concat and things like that create so many objects and hence inefficient garbage collection and hence memory leaks.

  1. Use Doc stream instead of reading direct xml files.
  2. Use IS XML parser for large file handling, see WmSamples in wiki for examples.
  3. Validate doc once and not in loop.
  4. Parallel processing for huge line items because they can be processed parallely and that required us to create small independent docs instead of large
  5. Guaranteed Vs Volatile persist only if required Guaranteed is memory consuming.
  6. Sending and processing smaller docs is heavier than processing one large example when you are storing them large is better.
  7. Use threads and make them asynchronous. For long running HTTP call we can use another thread instead of retry.
  8. Asynchronous is better
  9. Use data direct db driver over odbc drivers as they are fast and recommended.
  10. Remove disabled services because the flow still checks that step while running. Remove docs and services not being used.
  11. Remove those services which were never called while running a full test suite , you can find that in IS page under service usage services which are never called.
  12. Disabled packages are never loaded by IS so no issues.
  13. Stateless faster than state full as no state or session object needs to be saved. If calls in the same IS then its not stateful.
  14. Throwing an exception is resource intensive. Catching it clones the pipeline and fills error log. Choose no logging in Designer.
  15. If a join condition is there put it at the top because flow goes and check in top to bottom order.
  16. Clear pipeline iterates over all the steps to find what to drop from memory and hence avoid , rather drop variables wherever necessary or Choose only a portion of the pipeline by scope when calling a service.
  17. Avoid event handlers, turn off listeners which are not required ex. FTP , https, email listeners ,etc..
  18. Static data used a lot of times can be put in cache or in terracotta array.
  19. POST is 25 % faster than GET in REST
  20. MTOM is better than XML while passing soap attachments
  21. Stored procedure / views are better than SQL statements if the DB call is duplicate all the time. Also limit the no of connections in DB pool if they are not used.
  22. Reduce document history to save memory as it is used for duplicate checks and once and only once delivery
  23. Flat file adapters better than  writing.
  24. SSL causes performance hit. If the call you are making to an application inside the same network or Organisation then why use SSL because you are already protected by your enterprise security layer?
  25. Use basic auth instead of SAML authentication as it fetches tokens and in case of a load balancer the no of hops are so much that there is no value ad
  26. Minimal logging is very important as it is I/O overhead.
  27. Audit logging is better if it is synchronous unlike web services.

watt.server.auditlog=off in server.cnf for no logging.

  1. Make fewer steps in your BPM process model eligible for resubmission as it saves the entire pipeline. Minimize logging of pipeline variables. DO IT ONLY WHERE IT IS REQUIRED.
  2. Aggregate steps as much as possible rather than having so may steps in your BPM, like write most of the logic in one service and use that service as one step in the BPM.
  3. Do not use pub.remote.gd guaranteed delivery service instead of use pub.remote.invoke.
  4. Divide large services into smaller manageable pieces of code.
  5. Instead of doing dynamic host look-ups rather add those IP addresses and hostname in the /etc/hosts file.
  6. Minimum connections in your Database connection pool should be 1 and not 0. It was suggested to keep that 0 because Db connection pools earlier had a bug and making that 0 would flush all the stale connections which were sitting in the pool but were never available for use but as this is addressed now 0 is not even required.
  7. Use spy property in the JDBC connection pool on the IS page to investigate your connection pool. It will tell you the health of your conn pool and that can be seen in IS server.log
  8. You can use the Oracle AWR report analysis for checking the performance of your database. For e.g concurrent reads, locks can be analyzed using this.
  9. Avoid SELECT * when so many columns. Using joins is better than having multiple selects in one SQL query.
  10. Use EXISTS instead of COUNT(*). Instead of individual SQL statements inside a loop write one that does it all.
  11. Per core(CPU) we can have 150-200 threads but it depends on a lot of factors as well depending on the application. Sometimes decreasing the thread count improves the performance and hence understanding the application is of prime importance as to what are bottlenecks, what are the I/O requests, etc…
  12. Glue in MWS is for web services and Jetty is for connectors
  13. There are two levels of threads we must understand one is CPU level and the other is the application JVM level.
  14. vmstat is a tool used to collect and report data about your system memory
  15. Garbage collection normally kicks in when memory utilization is over or around 72%.When Garbage collection average time is under 1 sec you can believe that your system is efficient and performing well.
  16. Performance test scenario must be as close to real live test data, configurations, software versions along with hardware and resources available. Always test with more data than you would ever have in a real scenario and this must also cover high volume periods(eg. thanksgiving day)
  17. Create thread dumps using below steps and then use http://fastthread.io/. For Garbage collection you can use http://gceasy.io/
  • Jstack
  • Kill -3
  • jVisualVM
  • Windows(Ctrl + Break)
  • Nanoscope (brilliant tool to identify the performance of webmethods services)

Note: to analyze your thread utilization and also understand how your garbage collection works run the below files under the location: C:\SoftwareAG\jvm\jvm\bin. Or else you could also use Universal GC Log Analyzer

1. jvisualvm

2. jconsole

Further read:
For more best practices, please take a look at the guides: