We conducted our first webinar last week. After we released our public beta, we got some questions and feedback about Thundra. That’s why it was time to make this webinar, with Serkan Özal, our lead engineer, and me as product manager.
This webinar enabled us to introduce Thundra to our customers and to demonstrate Thundra while solving a real life issue with AWS RDS for a Lambda function written in Java.
In the webinar we demonstrated and discussed the following:
- What serverless observability means, and why it is important.
- How to monitor your Lambda functions with Thundra.
- What critical advantages Thundra has to make monitoring more seamless.
- A use-case to discover a code piece that took longer than expected, solve it and see the effect on Thundra.
- What’s next for Thundra?
It was a nice webinar in which we explained “what makes Thundra unique” which are namely:
- Asynchronous monitoring ‒ gathering monitoring data using our additional Lambda asynchronously instead of making HTTP calls. By asynchronous monitoring, Thundra guarantees zero overhead to your invocation and, flexibility to use monitoring for functions under VPC with no additional proxy configuration.
- Automatic Instrumentation ‒ making instrumentation using external audit parameters. This way you can change your instrumentation levels with no need to re-deploy your function.
- Three pillars of observability ‒ the ability to have system level metrics, logs and trace charts all together. This way, it is a lot easier to spot the root cause of abnormalities.
We run a quick demo at the end of our webinar. In the demo, we spotted a well-known N+1 problem of Hibernate in RDS. We followed the below steps:
- We benchmarked a function returning the users with an array of user ids. We observed that the invocation time is increasing with the increasing number of requested user ids although the same query is sent. This was the suspicious point.
- We enabled package based auditing and detected that almost all of the time is taken by service layer while getting retrieved users.
- So, we enabled line by line auditing to spot which line caused the increase in invocation time. It turned out that the line which executes the method for getting users from repository layer over Hibernate caused the problem.
- Then, we enabled JDBC level auditing to see which SQL statements were sent to RDS by Hibernate under the hood. This showed us our one query of selecting users caused N+1 queries in database. N query for joining the cards of each user and one final query to dispatch users.
- After modifying the code by joining users and owned cards on fetch, we saw that the invocation takes normal time as expected.
We also shared our tentative roadmap for improving Thundra even more. You can have a look at the recording here:
We are planning to make our next webinar focusing on Thundra with Node.js AWS Lambda functions. If you’d like a demo, please schedule. Stay tuned for more!