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 object and hence inefficient garbage
collection and hence memory leaks.

7. Use Doc stream instead of reading direct xml files.

8. Use IS XML parser for large file handling, see WmSamples in wiki for
examples.

9. Validate doc once and not in loop.

10. Parallel processing for huge line items because they can be processed
parallely and that required us to create small independent docs instead of large

11. Guaranteed Vs Volatile persist only if required Guaranteed is memory

consuming.
12. Sending and processing smaller docs is heavier than processing one large
example when you are storing them large is better.
13. Use threads and make them asynchronous. For long running HTTP call we
can use another thread instead of retry.

14. Asynchronous is better

15. Use data direct db driver over odbc drivers as they are fast and
recommended.

16. Remove disabled services because the flow still checks that step while
running. Remove docs and services not being used.
17. 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.
18. Disabled packages are never loaded by IS so no issues.
19. 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.
20. Throwing an exception is resource intensive. Catching it clones the pipeline
and fills error log. Choose no logging in Designer.
21. If a join condition is there put it at the top because flow goes and check in top
to bottom order.
22. 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.
23. Avoid event handlers, turn off listeners which are not required ex. FTP , https,
email listeners ,etc..
24. Static data used a lot of times can be put in cache or in terracotta array.
25. POST is 25 % faster than GET in REST
26. MTOM is better than XML while passing soap attachments
27. 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.
28. Reduce document history to save memory as it is used for duplicate checks
and once and only once delivery
29. Flat file adapters better than  writing.
30. 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?
31. 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
32. Minimal logging is very important as it is I/O overhead.
33. Audit logging is better if it is synchronous unlike web services.

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

34. Make less steps in your BPM process model eligible for resubmission as it
saves entire pipeline. Minimize logging of pipeline variables. DO IT ONLY
WHERE IT IS REQUIRED.
35. 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.
36. Do not use pub.remote.gd guaranteed delivery service instead use
pub.remote.invoke.
37. Divide large services in to smaller manageable pieces of code.
38. Instead of doing dynamic host look ups rather add those IP address and
hostname in the /etc/hosts file.
39. 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.
40. 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
41. 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.
42. Avoid SELECT * when so many columns. Using joins in better that having
multiple selects in one SQL query.
43. Use EXISTS instead of COUNT(*). Instead of individual SQL statements
inside a loop write one that does it all.
44. 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…
45. Glue in MWS is for web services and Jetty is for connectors
46. There are two level of threads we must understand one is CPU level and the
other is the application JVM level.
47. vmstat is a tool used to collect and report data about your system memory
48. 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 systems is efficient and performing well.
49. 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 real scenario
and this must also cover high volume periods(eg. thanks giving day)
50. 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 untilization and also understand how your garbage
collection works run the below files under the location : C:\SoftwareAG\jvm\jvm\bin.
1. jvisualvm
2. jconsole