Very slow loading times

[replaysMike]

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.

[fehguy]

Hi, the best way to help with this is to share the spec so we can profile it.

[replaysMike]

sure thing... here it is. I prettyfied it just for readability, but it's minified in the response.

[replaysMike]

I tried myself to profile it, but it just locks up the chrome tab.

[fehguy]

Thanks. we're looking into this now, it may take a bit to sort out the root cause (and yes, I can reproduce it).

[collaborator99]

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.

[fehguy]

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.

[replaysMike]

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.

[simonmurdock]

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 - novaworksau@e5bf68f 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

[fehguy]

Try setting the highlight threshold lower when initializing swagger-ui:

highlightSizeThreshold: 100

We're currently working on some performance issues around this right now.

[simonmurdock]

@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?

[webron]

@simonmurdock - if you can share your swagger.json with us it would be a huge help for investigating it further.

[simonmurdock]

Hi @webron I've emailed it

[simonmurdock]

Any updates? @webron

I'd be happy to try them out

[webron]

@bodnia? :)

[bodnia]

@webron it wasn't merged into master yet

[bodnia]

PR for this issue is #1956

[replaysMike]

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.

[fehguy]

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 (swagger-api/swagger-js#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.

[simonmurdock]

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.

[MisterWil]

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.

[simonmurdock]

I've just abandoned swagger completely.

[ponelat]

That's very sad

[Helmsdown]

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

[webron]

@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 ;)

[fehguy]

Swagger-ui just received an update which dramatically speeds up loading times. Please try master, which uses swagger-js 2.1.17.

[replaysMike]

Will be reviewing this today. Would love to be able to go back to using Swagger-UI.

[fehguy]

Please do share your findings

[michaelrepucci]

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.

[webron]

@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.

[nijinillath]

Thanks @freemahn for the response, but using docExpansion: "none" also the UI page unresponsive.

[nijinillath]

Hi Team, did you get a chance to re-check on the UI page unresponsive issue due to the size of json ?
Is there any new option to hide the models from the UI ?

[webron]

We regularly investigate and provide small performance improvements over time. This ticket encompasses a range of such improvement. We can't say which improvement will fix whose issue, so it's best to keep checking with newer releases.

[shockey]

FYI: if the Models section is your performance bottleneck, the most recent release (3.4.4) contains improvements that are likely to improve your experience.

[nijinillath]

Thanks Team, appreciate the response.. Will check on the newer releases. As of now "SwaggerUI-Angular" worked for my load.

[webron]

Time for an update on this long thread. We've recently pushed some updates to the UI that should present with increased performance. They are mostly focused on lazy-loading, but not only. This means that if you start your swagger-ui with collapsed entries, it would load fairly fast, and the additional parts will load as they are expanded.

We encourage you to give a try to the latest version and see if it helps your case. We'd be happy to further investigate performance issues that persist. Please keep us posted.

[msankhala]

I am using the swagger hub and my API spec contains 1000 lines and it has become extremely slow. Even though I have collapsed all of my schema and a few paths but It is still slow.

[heldersepu]

@msankhala Can you share your spec?
Have you tried reducing the spec (maybe try with less paths) see if something stands out as the main issue?

[zekeriyakoca]

I faced the same issue after adding [ResponseType] attribute to my endpoints. Some of the endpoints was returning complex model class and this was causing the problem in my case. I removed this attribute for these endpoints and it's solved. ResponseType was not mandatory for my project and I skipped this feature, but if you need it, you can try to find a solution to restrict model serializing dept or you can replace your returning model not including circular references.

[heldersepu]

@zekeriyakoca what you mentioned [ResponseType] attribute is not a swagger-ui feature, a quick search on the code returns nothing:
https://github.com/swagger-api/swagger-ui/search?q=ResponseType&type=Code

best you can do is attach your spec here so the team can look into it

[zekeriyakoca]

@zekeriyakoca what you mentioned [ResponseType] attribute is not a swagger-ui feature, a quick search on the code returns nothing:
https://github.com/swagger-api/swagger-ui/search?q=ResponseType&type=Code

best you can do is attach your spec here so the team can look into it
[ResponseType] asp.net attribute used by ApiExplorer to know what type a method returns. Swagger should be using this attribute to documenting the return type.

DbsDocument cannot be serializable because of circular dependency. This code cause the swagger index page to be loaded in 20-30 secs and when I try to expand the request in swager ui panel, it's frozen.

If the team implement a feature to restrict the serialization depth, this may be useful for some developers. If already exist, I would be glad to hear.

[heldersepu]

@zekeriyakoca that screenshot looks like C# maybe you are using swashbuckle, but that is not directly related to this project...
and no, at the moment, there is nothing to restrict the serialization depth, once someone clicks on the model it will expand all the way

I opened this: #4280 a while ago, the idea was to only load/expand as needed maybe 2 levels deep at a time, (I imagine this is very very low priority) that is why no one has taken interest in fixing it.

In my experience, large or complex models are inherited from bad practices and they can be refactored to reduce complexity. Yes we can create a theoretical spec with lot of nesting and that will blow any web UI, I did some numbers a while back here: #4411 (comment)
but ultimately it's our responsibility as developers to simplify the APIs we create

[spaasis]

Just noting that this issue is making it rather difficult to use OData (https://docs.microsoft.com/en-us/odata/webapi/first-odata-api) since it "relies" on accessing the ORM model via the API. This in turn might turn people away from OpenAPI towards e.g. GraphQL

[heldersepu]

Just noting that this issue is making it rather difficult to use OData (https://docs.microsoft.com/en-us/odata/webapi/first-odata-api) since it "relies" on accessing the ORM model via the API. This in turn might turn people away from OpenAPI towards e.g. GraphQL

@spaasis I don't think this is a problem with all OData projects and swagger-ui, quite the opposite, most project should be just fine, only those with complex models with a lot of nesting might have issues and those should be a minority.

[spaasis]

@heldersepu Sure, might be that most projects don't actually get hit by this. I'm working on environmental data, which by it's nature is very much linked together, so I've been bit by this in practically every OData API we're supplying via OpenApi.

The workaround thus far has been to exclude some navigation properties from the swagger.json to stop some of the cycles, but this will cripple the API usage somewhat especially on generated clients.. One could also make navigations one-sided, which has it's own benefits and drawbacks.

I think some of this could be better handled if the renderer would skip some of the redundant loops.
e.g. If I have a relation A-B-A (quite standard in OData to provide navigation properties both ways), the UI will render

• A fully
  • B fully
    • A fully
      • B fully
        • A as empty

When it could be

• A fully
  • B fully
    • A as empty

The generated example value gets really bloated when some classes example data is printed many times over

[heldersepu]

@spaasis just to clarify ... let's not mix OpenApi and swagger-ui ...

This is not a problem on the OpenApi Specification, you can provide the full swagger.json to any one and they can generate a client just fine, then make calls to the endpoints without any problem.
Here is an example:
https://swagger-net-test.azurewebsites.net/api/NestedSwag/9

The problem is expanding some of those complex models in the swagger-ui, see here:
https://petstore.swagger.io/?url=https://swagger-net-test.azurewebsites.net/api/NestedSwag/9
That is the same spec but if you try to expand Test0 model very likely browser will crash

[spaasis]

@heldersepu Certainly! I was a bit unclear. What I meant by "..turn people away from OpenAPI" was that if their model cannot be utilized via the de-facto default UI of OpenAPI, then that might push them to alternative solutions such as GraphQL (or just a different UI such as ReDoc). Our models that struggle with the swagger-ui work beautifully in the client generation.

[heldersepu]

@spaasis have you tried a complex model on ReDoc?
http://redocly.github.io/redoc/?url=https://swagger-net-test.azurewebsites.net/api/NestedSwag/9
It crashes in a worst way than swagger-ui

[spaasis]

@heldersepu In the two cases I tried ReDoc, the initial load takes way longer than swagger-ui, but after that it worked fine. Contrast that to swagger-ui where the initial load is fast, but opening an endpoint takes ages and makes the entire ui unresponsive for rest of the session. So yeah, neither are perfect

[oscarguinane]

To fix this, can we just replace the default selected response example to schema instead of value? The schema loads just fine but the value crashes the page

[onevcard-team]

To fix this, can we just replace the default selected response example to schema instead of value? The schema loads just fine but the value crashes the page

Is it possible to set the default to schema with some configuration? We use @nestjs/swagger

[appleseedexm]

Is there an update on this, is this on some kind of roadmap? The latest responses seem only partially related and its a very long standing issue.
For our project this has led to calling the FE endpoint on server startup to trigger the initial load which makes following requests faster, but looking at this issue I do wonder if it makes sense to look around for alternatives.

[yuryturing]

Is it possible to set the default to schema with some configuration? We use @nestjs/swagger

Setting swaggerOptions.defaultModelRendering worked for me.

SwaggerModule.setup('docs', app, document, {
    swaggerOptions: {
      docExpansion: 'none',
      // @see https://github.com/swagger-api/swagger-ui/issues/6787
      syntaxHighlight: false,
      defaultModelRendering: 'model',
    },
  });