swagger-ui
swagger-ui copied to clipboard
swagger-api
Very slow loading times
I commented on this in an older issue, but I'm going to open a new one for performance issues.
I've got 45 api endpoints and am running swagger-ui under Swashbuckle (.Net) latest version. It currently uses swagger 2.1.3.
Before I started messing around it was taking over 4 minutes to display the endpoints UI. I went in and set the highlightSizeThreshold to 1, and finally just commended out the highlight-7-3 lib altogether. I did get a speed increase of about 50%, but a 2 minute load time is still very unacceptable.
Are you aware of what is causing the severe performance problems, and have an ideas to solve it? This isn't a huge API yet, but it will become one and I'm concerned about any attempt to support swagger at this rate.
I confirmed the backend is serving the requests in under a second, and the schema is around 1MB.
Hi, the best way to help with this is to share the spec so we can profile it.
sure thing... here it is. I prettyfied it just for readability, but it's minified in the response.
Thanks. we're looking into this now, it may take a bit to sort out the root cause (and yes, I can reproduce it).
There seems to be a huge slowdown from rendering in version 2.1.0 to 2.1.1.
With a Swagger "spec" with 19 operations, from the moment "fetching resource list" message appears to the operations list appearing, it went from almost instant (1 second) in version 2.1.0 to about 23 seconds! in 2.1.1.
As the support for remote references has been added, the slow down usually occurs when something goes wrong in fetching them (i.e. a 404 or inability to resolve a remote reference). The code for rendering a spec has not changed enough to cause what you're seeing.
@collaborator99 do you use remote references? If you have a spec to share, it will help.
It's probably something small as it usually is, if I was familiar with the code base I'd be more help. I'll try to dig in myself this week.
Also suffering from very slow performance on a very fast machine. For now I have attached my chrome timeline which you should be able to load into your timeline to get a full breakdown of what's going on. About 60% of my API is actually added right now and taking 15 seconds or thereabouts.
swaggerTimelineRawData-20160209T085821.zip
I can also provide my swagger json privately if needed.
Also found this - https://github.com/oconics/swagger-ui/commit/e5bf68fd502ca4bb083e2339bceb0f6e0473fb73 seems like it would defer all the rendering and fix our issues.
Update:
I cloned the latest version and loaded my test json into that, and I get a call stack exceeded where it gets stuck in a loop everywhere between createSchemaXML and createObjectXML
Attached the chrome time line data:
callStackOverflowTimelineRawData-20160209T202231.zip
Try setting the highlight threshold lower when initializing swagger-ui:
highlightSizeThreshold: 100
We're currently working on some performance issues around this right now.
@fehguy ran latest version again with highlightSizeThreshold: 1 and still the same issue, call stack exceeded after around three items are shown on the main screen:
Pattern does look a little different though. Unfortunately I don't know a whole lot about backbone views or I'd be of more use. Could I ask why XML is even involved? if its json in? Just for the dropdowns to choose the response view?
@simonmurdock - if you can share your swagger.json with us it would be a huge help for investigating it further.
I'll check out this PR however if you note my initial post, I had disabled highlight completely for my tests. It does indeed slow down the load time by a lot, however it is still painfully slow even without highlight. We're talking minutes of load time here for what is a fairly small API.
Sure thing @replaysMike. There are multiple fixes going on, one was highlight which can now be configured away to be disabled completely. Another with references (https://github.com/swagger-api/swagger-js/pull/710, not yet merged into the UI). I'm hoping those two make a big difference, they will at the very least help us isolate things.
The issue is that everything in signature.js is incredibly slow and is all being processed up-front. It should be deferred until you click that particular path/route. I think these accounted for 50% of the issue.
Those calls being:
getModelSignature
createJSONSample
getParameterModelSignature
createParameterJSONSample
createSchemaXML
createXMLSample
getPrimitiveSignature
I've since started developing my own UI to parse swagger API json files, and do roughly what Swagger-UI does. Admittedly it's not doing any of the model stuff yours is, but it's deferring everything and loading the same json as my screenshots above in < 600ms. Should be possible to get swagger-UI that fast.
Are there any updates on this? Seems that this as well as #1804 are related. Like @simonmurdock above, I was also having extremely slow performance on a much smaller API and the master got stuck in a createSchemaXML loop.
Just ran into this. I can provide my swagger spec privately.
I was running the dist of swagger-ui:2.1.4. I pulled the dist from master and its much better!
+1 releasing a new version of swagger-ui
@Helmsdown - we're close to releasing a new version. If the performance of master is not enough, please share the spec. You know how to reach us ;)
Swagger-ui just received an update which dramatically speeds up loading times. Please try master, which uses swagger-js 2.1.17.
Will be reviewing this today. Would love to be able to go back to using Swagger-UI.
I just pulled the latest swagger-ui from dist on master, and while it's better, I still have painfully slow performance on a REST API with 50 read-only (GET) endpoints. The minimized swagger.json is 94.4 KB and, itself, loads very quickly. But both Firefox and Chrome complain of unresponsive scripts when loading it through the swagger ui. I'm completely new to swagger so mostly wondering if this is a limitation of swagger itself, or related to my REST API.
@michaelrepucci - thanks, that's great. Not great that it gets stuck, but it's it's rather that you provided the spec - that helps us a lot analyzing what's causing these issues and tackling them one by one. I can confirm that this is indeed painfully slow with the current master.
Looks like an issue with XML rendering, I'm getting a max call stack exceeded.