Mendix Logging Best Practices: When to Use Logs, When Not To, and How to Avoid Performance Issues

0

Logs are one of the most powerful tools for debugging and monitoring Mendix applications — but if not used wisely, they can quickly become a performance bottleneck. In this blog, let’s break down how to use logs effectively, when to use them, when not to, and their overall impact on your system.

 

What are Logs in Mendix?

In Mendix, logs are runtime messages that provide insight into what your app is doing at any moment. They can include:

• Errors
• Warnings
• Info
• Debug messages
• Custom logs (you define in microflows, Java actions, or Nanoflows)

 

You can view these logs in:

• Studio Pro console (during local development)
• Cloud environments (via Log Levels tab)
• Log files (for on-prem or advanced cloud setups)

How to Use Logs

You can add custom logs using the Log Message activity in microflows or by using logMessage in Java actions.

Examples:

• Logging errors after catching exceptions
• Tracking user behavior (like button clicks, API usage)
• Debugging slow processes or failed validations

You can also set log levels like TRACE, DEBUG, INFO, WARNING, ERROR to control visibility.

 

When to Use Logs

Use logs when:

1. Debugging issues during development or QA
2. Monitoring critical business processes in production (e.g., API calls, failed payments)
3. Tracing performance issues (e.g., how long a microflow takes)
4. Catching unexpected errors with details for investigation
5. Monitoring user actions in complex UI flows

When NOT to Use Logs

Avoid using logs:

1. Inside tight loops or recursive logic (e.g., looping over 1000 records)
2. For every small UI action (e.g., dropdown selection, mouse hover)
3. In production at TRACE/DEBUG level — it clutters logs and slows performance
4. To store business-critical data — logs are for developers, not for auditing
5. Without conditions — logging large objects or associations blindly can hit memory

 

Impact on Performance

Here’s how excessive or careless logging can affect your Mendix app:

🔹 1. System Performance

• Too many logs (especially DEBUG) = increased CPU and memory usage
• Logging in loops = slows down microflows significantly

 

🔹 2. Database

• Mendix doesn’t store logs in the business database, but cloud environments do persist logs temporarily.
• Over-logging increases log storage size, which can exceed quotas in cloud apps.

 

🔹 3. Memory Usage

• If you’re logging large objects or associations using toString, it can cause heap memory spikes
• Leads to Out of Memory errors if logs are frequent and detailed

 

🔹 4. User Interface

• Directly, logs don’t affect UI.
• But if logging causes backend lag (e.g., 2–3 seconds delay due to logging inside a loop), the UI response time degrades and impacts user experience.

Best Practices

• Use INFO level for production logs (errors, important events)
• Use DEBUG only in dev and QA
• Avoid logging sensitive data (passwords, PII)
• Always wrap logs inside conditions if they are inside a loop
• Clean up logs before final release — especially dev/debug statements

 

Posted 2025-08-01

0 comments