[▲ Vercel Community](/) · [Categories](/categories) · [Latest](/latest) · [Top](/top) · [Live](/live) [Discussions](/c/community/4) # Monitoring Fluid performance 75 views · 0 likes · 1 post Dbauszus (@dbauszus) · 2025-03-11 We'd like some help to better understand how we can monitor fluid/static serverless [function] performance and associated costs. I have setup two identical projects to access spatial data through a serverless node run time. https://4-13-static.vercel.app https://4-13-fluid.vercel.app If I enable a lot of vector [tile] layers at the same time I feel that the fluid application is generally more responsible. https://4-13-static.vercel.app/geodata?layers=mapbox_base,mapbox_label,retail_points,food_to_go,grocery_demand,poi,road_traffic,seamless_towns,town_suburb,Urbanity,Workers&locale=London&z=16.45&lat=51.49472&lng=0.07579 https://4-13-fluid.vercel.app/geodata?layers=mapbox_base,mapbox_label,retail_points,food_to_go,grocery_demand,poi,road_traffic,seamless_towns,town_suburb,Urbanity,Workers&locale=London&z=16.45&lat=51.49472&lng=0.07579 I would expect this to be a good test for the capabilities of fluid processes. Changing the viewport of the map window will require dozens of queries being sent async to the same process.  Every query will pass through the process to a linked Neon Postgres Database. I'd assume that the static project will spin up more processes / serverless function while waiting for the postgres query to resolve with data to be sent back to the client. I have had a look at the various metrics available for Monitoring and only found a significant difference in the [average] Function CPU Time. For the static project this was about 13ms; For the fluid project this was about 33ms on average. I don't really know what these numbers mean. Any help run addtional tests to generate some metrics which give us a better understanding of fluid compute would be greatly appreciated.
