Phoenix's UI performance issues with large traces are known. Improvements include lazy loading of spans and reducing page size from 100 to 50 spans, which can help reduce load times (source). Would you like more details on how to implement these improvements? Sources:
- GitHub Issue #4006
馃挕聽Hint: Mention RunLLM in the thread for followups.
I'm also curious about Jason's question regarding the number of spans. I'm also guessing that you're dealing with very large/ long context spans. Curious how many tokens your LLM calls are using?
I actually have 2 spans for each trace, 1 is ChatCompletion and 2 is Retriever span. so would be double of 550 approx. I also have a lot of text and documents in each span. token count of 1 trace is around 5k-7k, some times 8k.
So the situation is, we have deployed our flask app through azure app services and it has some layers built on top of it which restricts us to use phoenix client direct to push spans using OTLP. To add a bypass(the patch I'm talking about) we're saving the spans to mongodb and then using the graphql query to fetch the data from mongodb and use BulkInserter to insert spans and evaluations into the postgre database.