Couple more questions about Tyk -- scalability and developer portal?

Support Setting up Tyk
1

Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:06:47 +0000.
Sender:Darren Sargent.
Date:Thursday, 12 February 2015 19:15:43 UTC.

Hi there, we’re looking for an API gateway product, and Tyk looks amazing. And can’t beat the new price of $0!

My questions are these:
Any idea how it performs under very heavy load, like thousands of TPS? I’m guessing the answer is to scale horizontally and LB across multiple nodes, but I wondered what kind of TPS you’ve pushed through it.
Is there a “developer portal” component? I mean something whereby we can document our APIs, the parameters etc. and have the results published to a nice “portal” type page, where our customers can explore our APIs, read the doc etc. and hopefully even execute dummy “sandbox” calls to explore the API.
Thanks!

Darren Sargent

1 Like
2

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 12 February 2015 20:10:41 UTC.

Hi Darren,

Sure thing - lots of people have asked about throughput, and we’ve got some numbers, there’s a thread on this forum which lists a few tests, and most recently we ran a benchmark test which wasn’t published but was probably the most robust test (very controlled environment), but I might as well share the results here. The full results are attached, the test setup was:

The machine running the test is a 16GB RAM, 8 Core server running in the same data centre as the target machine (Digital OCean, London DS The target machine was an 8GB/4 Core Server running Ubuntu 14.04, test were conducted using JMeter.

During the test, the target server was running:
NginX
Tyk (optimised 1.4 branch)
Tyk dashboard
MongoDB (vanilla)
Redis (vanilla)
The only optimisations that were done on the OS level were:
Setting GOMAXPROCS to 4, so all cores are used by Tyk
Setting ulimit to 999999 so we didn’t run out of file descriptors (for Redis)
The tests ran for 3 minutes.

The baseline just tested NginX solo serving up the default page, and then we tested the proxy to see how it affected the machine.

Bottom line: we put 430 RPS through Tyk and the machine purred along, any more than that and we started seeing quite a lot of variability in response times. Personally, I think 430 RPS on a single node is ok, for your target of thousands of TPS, you’ll need to auto-scale the nodes. Tyk has a healthcheck API that returns upstream latency data, error rates etc. So you can easily set up and benchmark autoscaling options based on those as well as standard CPU metrics. Tyk is also CPU bound, so throwing more cores at it helps. Naturally proximity of Redis server will affect latency. These results did not use any caching.

The optimisations in that test are in the 1.5 release, so that’s all available now. I’ve attached the raw results to the post so you can see for yourself.

Tyk doesn’t have a developer portal, though we’ve thought about building one, perhaps as an extension to the dashboard.

Hope that answers anything :slight_smile:

Cheers,
Martin

  • show quoted text -
3

Imported Google Group message.
Sender:Darren Sargent.
Date:Thursday, 12 February 2015 20:10:41 UTC.

Hi Darren,

Sure thing - lots of people have asked about throughput, and we’ve got some numbers, there’s a thread on this forum which lists a few tests, and most recently we ran a benchmark test which wasn’t published but was probably the most robust test (very controlled environment), but I might as well share the results here. The full results are attached, the test setup was:

The machine running the test is a 16GB RAM, 8 Core server running in the same data centre as the target machine (Digital OCean, London DS The target machine was an 8GB/4 Core Server running Ubuntu 14.04, test were conducted using JMeter.

During the test, the target server was running:
NginX
Tyk (optimised 1.4 branch)
Tyk dashboard
MongoDB (vanilla)
Redis (vanilla)
The only optimisations that were done on the OS level were:
Setting GOMAXPROCS to 4, so all cores are used by Tyk
Setting ulimit to 999999 so we didn’t run out of file descriptors (for Redis)
The tests ran for 3 minutes.

The baseline just tested NginX solo serving up the default page, and then we tested the proxy to see how it affected the machine.

Bottom line: we put 430 RPS through Tyk and the machine purred along, any more than that and we started seeing quite a lot of variability in response times. Personally, I think 430 RPS on a single node is ok, for your target of thousands of TPS, you’ll need to auto-scale the nodes. Tyk has a healthcheck API that returns upstream latency data, error rates etc. So you can easily set up and benchmark autoscaling options based on those as well as standard CPU metrics. Tyk is also CPU bound, so throwing more cores at it helps. Naturally proximity of Redis server will affect latency. These results did not use any caching.

The optimisations in that test are in the 1.5 release, so that’s all available now. I’ve attached the raw results to the post so you can see for yourself.

Tyk doesn’t have a developer portal, though we’ve thought about building one, perhaps as an extension to the dashboard.

Hope that answers anything :slight_smile:

Cheers,
Martin

  • show quoted text -
4

Imported Google Group message.
Sender:Martin Buhr.
Date:Sunday, 15 February 2015 20:47:42 UTC.

Hi Martin,

For some reason it won’t let me reply to your answer so I’m replying to mine instead.

Excellent answer, thank you.

Our use case definitely involves a developer portal. I guess we could use the Tyk API itself to access the API definitions in the MongoDB and thereby create our own portal, but I’m not sure how we’d integrate it with Dashboard since that is still open source. If we go this route, would you be interested in partnering to develop something which would then be part of the product?

Darren

  • show quoted text -
5

Imported Google Group message.
Sender:Darren Sargent.
Date:Tuesday, 17 February 2015 06:59:22 UTC.

Thanks, very helpful answers!

On Thursday, February 12, 2015 at 11:15:43 AM UTC-8, Darren Sargent wrote:

  • show quoted text -
6

Imported Google Group message.
Sender:Darren Sargent.
Date:Wednesday, 18 February 2015 10:50:01 UTC.

Hi Darren,

We’re actually contemplating a developer portal - though the issue is making it generic enough for a wide range of use cases.

If we built one, looking back, we’ll probably not integrate it into the dashboard and instead start a new open source component. We would definitely be interested in getting some help around this, as we’re hammering out requirements, so far we have a few ideas around features, very high level for now:

Home page
API Catalogue:
View description of all public APIs
API Documentation:
Methods, endpoints and parameters
Send sample requests from the docs
Signup / Login
Profile page
My API’s
Subscribed APIs
Quotas and limits for each API key
Usage graph
Admin
Manage user profile
Manage user subscriptions (add / remove)
Manage API Listing
Documentation
API Description
Manage plans
Group Key Template (One key for many APIs) - Single Quota
Per-API Key template (One key per API) - Multiple quotas
Manage Settings
Payment redirect URL
Subscription inactive API endpoint
Subscription active API endpoint

We would use the Advanced Management API to get the currently live API’s for an organisation, these would then map against entries in a database, this way documentation, content etc can be developed against an inactive API (Tyk’s API endpoint only shows loaded API’s IIRC, not inactive ones)

Data structures for things like user profiles, API intros, home page etc would be loose interfaces, with only some fixed fields, that means that implementers can create their own fields (maybe as JSON configuration files) which get exposed to templates so it’s really flexible. This makes the backend MongoDB, but since the dashboard uses it, this should be ok.

Templates would be Golang based, so pretty flexible, and we make the base, default template out of Bootstrap so that it can be themed and adapted easily.

The only prescriptive part of the portal data structures would be the API documentation bit, where we could use something similar as we do with the designer in the dashboard to build out an endpoint map. I’m reluctant to use the actual definition as they can, by design, be incomplete so that the whole API doesn’t need to be defined resource by resource.

We’ve added in a few endpoints to activate and deactivate profiles (this would just chain out a request to the Dashboard API to deactivate a key), with the view that some integrators may wish to charge for plans, with either bundled keys (multiple API’s can be accessed with one key, this applies a single quota though), or bundles where a separate key is provided per API, but they can be bundled together as a plan, this way there are multiple quotas per key. I think this bit is the one we’re struggling with defining properly as it’s difficult to make this bit generic enough, I’d like to make it as simple as possible TBH.

Longer term we can build in payment integrations with things like Stripe or Paypal so it’s enabled out of the box. But for now I’m happy to hand-off to a third system using a redirect.

Would really appreciate your (and the rest of the community) thoughts on this :slight_smile:

Cheers,
Martin

  • show quoted text -
7

Imported Google Group message.
Sender:Darren Sargent.
Date:Wednesday, 18 February 2015 19:30:32 UTC.

This would definitely make Tyk more attractive to a wider audience as since it’s a big gap compared to other API mgmt. services not having this.

I’d encourage you to use one of the emerging API documentation standards – Swagger, RAML, or API Blueprint – vs. doing something custom. Or at least support importing from one of those formats and possibly exporting to.

Chris

  • show quoted text -
8

Imported Google Group message.
Sender:Martin Buhr.
Date:Wednesday, 18 February 2015 19:37:26 UTC.

Hi Chris,

Indeed, the dashboard actually supports importing API Blueprint to generate definitions.

So rendering a blueprint on the portal and importing it into the dashboard would make quite a slick solution :slight_smile:

What are your thoughts on adding monetisation? It feels like a minefield…

Thanks,
Martin

  • show quoted text -

  • show quoted text -

–
You received this message because you are subscribed to the Google Groups “Tyk Community Support” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web, visit https://groups.google.com/d/msgid/tyk-community-support/477076a6-00c5-427f-98e5-5c5d74b61b09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

9