Measuring Backend Power Levels: Securing Objectivity by Reflecting Real-time Congestion

Want to reflect real-time congestion when measuring power scale? Or have you questioned the objectivity of existing measurement methods? This post covers how to enhance the objectivity of power scale measurement and reflect real-time congestion using Seoul's urban data.

Attempts and Pitfalls

Initially, I changed the power scale measurement method to simply record the daily maximum value for each date. The goal was to ensure objectivity by using Seoul's urban data as the primary indicator.

However, I realized that it lacked the ability to reflect real-time congestion. For instance, if there was an event on a specific day causing congestion to surge, recording only the daily maximum might make it appear not much different from the usual congestion levels.

So, I considered adding real-time congestion data for Olympic Park as a secondary indicator. I attempted to retrieve real-time congestion information through the Seoul Urban Data API.

# Example: Calling Seoul Urban Data API (Actual API endpoint may vary)
import requests

api_key = "YOUR_API_KEY"
olympic_park_data_url = f"https://api.seoul.go.kr/v1/citydata/olympic_park_congestion?apiKey={api_key}"

try:
    response = requests.get(olympic_park_data_url)
    response.raise_for_status() # Raise an exception for HTTP errors
    congestion_data = response.json()
    print(congestion_data)
except requests.exceptions.RequestException as e:
    print(f"API call error: {e}")

During this process, unexpected issues arose with the API response format and data parsing. Sometimes the data was empty, or it came in a format different from what was expected. After about 3 hours of struggling, I figured out a way to reliably handle the API responses.

The Cause

To improve the objectivity of the power scale measurement method and reflect real-time congestion, both aspects needed to be considered.

1. Ensuring Objectivity of the Primary Indicator: Recording the daily maximum value for each date could enhance objectivity by showing the peak at a specific point in time.
2. Reflecting Real-time Changes: It was necessary to detect and incorporate unexpected congestion situations into the measurement by utilizing real-time congestion data from highly populated areas like Olympic Park as a secondary indicator.

The Solution

Ultimately, I changed the power scale measurement method as follows and updated the related documentation.

• Primary Indicator: Maintain the recording of the daily maximum value for each date.
• Secondary Indicator: Add real-time congestion data for Olympic Park. This data is periodically collected through the Seoul Urban Data API.

# Example: Data collection and storage logic (simplified)
import datetime

def get_olympic_park_congestion():
    # ... (API call and data parsing similar to previous code)
    # Return actual congestion value (e.g., 0.8 - very congested)
    return 0.8

def update_power_scale_measurement():
    today = datetime.date.today()
    current_max_scale = get_daily_max_power_scale(today) # Existing function to get daily max
    current_congestion = get_olympic_park_congestion()

    # Logic to update daily maximum
    if current_congestion > current_max_scale:
        update_daily_max_power_scale(today, current_congestion)

    # Store secondary indicator data (e.g., in a separate table or log)
    log_congestion_data(today, current_congestion)

    print("Power scale measurement data update complete.")

# Call periodically during actual execution
# update_power_scale_measurement()

This approach allows us to understand the usual power scale through the daily maximum while also detecting sudden congestion changes with the secondary indicator, thus increasing the realism of the measurement.

Results

• The objectivity of the power scale measurement method has been improved.
• The realism of the measurement has increased with the incorporation of real-time congestion data.
• The related documentation has been updated to include the latest data reflections and changes in the measurement method.

Summary — To Avoid the Same Pitfalls

• [ ] When measuring power scale, consider real-time congestion data as a secondary indicator in addition to the daily maximum.
• [ ] When integrating external APIs, implement robust exception handling for potential response format issues or data omissions.
• [ ] When restarting WAS (e.g., gunicorn), verify that data collection and measurement logic resume normally. (Previously, there was an issue where data was lost after restarts.)