Web: Profile the Gitcoin API and figure out why it's slow.

[owocki]

Right now the gitcoin API is unacceptably slow.

kevinowocki@local /Users/kevinowocki~ % time curl "https://gitcoin.co/api/v0.1/bounties/?network=mainnet&idx_status=open&order_by=-web3_created&offset=25&limit=25" > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  288k  100  288k    0     0  66607      0  0:00:04  0:00:04 --:--:-- 71858
curl  > /dev/null  0.02s user 0.02s system 0% cpu 4.449 total

The above request returns 25 results and takes 4.5 seconds. Ideally it should take 1/30th of that amount of time.

I would like, contributor, to profile our API, and to

1. Recommend changes that will take down the API response time for this request. Note: These recommendations must be based in data, not just stabbed in the dark.
2. Implement those changes.

I will pay 100 DAI for (1), and I will pay 300 DAI for (2).

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

__This issue now has a funding of 3.0 ETH (312.12 USD @ $104.04/ETH) attached to it.__

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
  
  
  
  • Want to chip in? Add your own contribution here.
  
  
  • Questions? Checkout Gitcoin Help or the Gitcoin Slack
  
  
  • $53,719.40 more funded OSS Work available on the Gitcoin Issue Explorer
  
  

[FirefighterBlu3]

where is the API code in the repo?

[owocki]

https://github.com/gitcoinco/web/blob/master/app/dashboard/router.py

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

__Work has been started__.

These users each claimed they can complete the work by 1 week, 3 days ago.
Please review their action plans below:

1) firefighterblu3 has started work.

1. Locate code (implies request to @Gitcoin for identifying closely associated files within repo)
2. Identify affected code paths
3. Analyze and profile to identify if slow performance is external to code (DNS, TCP/IP routes)
4. Plan and test changes
5. Re-evaluate performance
6. Repeat 4-5 as necessary to achieve issue goal of 1/30th time, or provide data showing realistic expectation for goal

Learn more on the Gitcoin Issue Details page.

2) markusj1201 has started work.

1. Audit (speed test)

2. Identify issues and or error codes being thrown.

3. Research appropriate resolution measures.

4. Prototype debug plan.

5. Write code correction(s)

6. Implement code.

7. Test

8. Wash, rinse, repeat.

Learn more on the Gitcoin Issue Details page.

3) oogetyboogety has started work.

(1) Get silk profiler running with gitcoin api. it doesn't work out of the box

• had to put the silk urls before the wagtail urls in app/app/urls.py
• had to insert(0, silkymiddleware) instead of append(silkymiddleware)
  Silk appears to be working now
  (2) Time the request
  I 've done this with debuggin enabeld so so i might need to turn off debugging to get a true estimate. there is a lot of printing in debugging.
  I have sorted the SQL queries profiled by Sik into a spreadsheet descending by execution time. I placed it here:
  http://www.sharecsv.com/s/8b89ea59a07d517f81e736d9ff7a77a8/Untitled%20spreadsheet%20-%20Sheet1%20(3).csv
  Here are the silky results:

07:18:12.963
200 GET
/api/v0.1/bounties/
14920ms overall +3103ms
495ms on queries +554ms
337 queries +709
Query Parameters

{
"idx_status": "open",
"limit": "25",
"network": "rinkeby",
"offset": "25",
"order_by": "-web3_created"
}

Request Headers
HOST 127.0.0.1:8000
USER-AGENT curl/7.59.0
ACCEPT /
Response Headers
CONTENT-TYPE application/json
VARY Accept
ALLOW GET, POST, HEAD, OPTIONS
Raw Response Body
The raw response body is 103090 characters long and hence is too big to show here. Click here to view the raw response body.
Response Body
This is the body of the HTTP response represented as JSON for easier reading.
The response body is 128886 characters long and hence is too big to show here. Click here to view the response body.

I plan to follow the guide here to implement the changes required. It may be serialization, database, or anything in between that is causing the lag. We will have to continue to profile and find out.
https://www.toptal.com/python/performance-optimization-testing-django
be similar for other frameworks and languages. In this article, I will use these methods to reduce the response time of a query from 77 to 3.7 seconds.

Learn more on the Gitcoin Issue Details page.

[kuhnchris]

well that's easily explained: it loads ALL entries and then filters the RESULTSET. so there you go...

[markusj1201]

Kuhnchris, although your observation is 100% accurate, the underlying issues are found across multiple areas, causing { 'x -micro.issues = mi (macro.issue -y(slow api performance')) }

[kuhnchris]

So, literally a cock-up cascade. Can you fix it or you need some more help with that?

[FirefighterBlu3]

how about access to a SILK report covering a set of bounty requests?

[kuhnchris]

You mean SILK as in this? https://github.com/jazzband/django-silk @owocki is that feasable?

[FirefighterBlu3]

yes. it's already in the app.settings config

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

__Work for 3.0 ETH (310.82 USD @ $103.61/ETH) has been submitted by__:

1. @markusj1201
2. @oogetyboogety

@owocki please take a look at the submitted work:

• PR by @oogetyboogety
• PR by @markusj1201

---

• Learn more on the Gitcoin Issue Details page
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $56,387.62 more funded OSS Work available on the Gitcoin Issue Explorer

[owocki]

silk looks interesting for figuring out which pages are slow.. for this use case, we've already identified the API responses are slow and now we need to profile why and figure out workarounds

[markusj1201]

Kevin,
Yes. The work up I did, the write up for performance issues I found cross
referencing with udemy, google, and our tech.lib at Purdue. (No need to
re-invent the wheel.) I have the workarounds proto'd, and if it's ok with
you I can start populating the repository.

Mark

On Wed, Jan 30, 2019 at 8:51 PM Kevin Owocki [e-mail]
wrote:

silk looks interesting for figuring out which pages are slow.. for this
use case, we've already identified the API responses are slow and now we
need to profile why and figure out workarounds

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gitcoinco/web/issues/3628#issuecomment-459195087, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Ar1NZ5GSljLH0O6T9UACauZiAbI8KYf7ks5vIlo1gaJpZM4aW2Iz
.

[markusj1201]

Hey Chris! I always invite help, especially from astute programmers such as
yourself, Sir.

On Wed, Jan 30, 2019, 12:38 PM KuhnChris <[email protected] wrote:

So, literally a cock-up cascade
https://www.urbandictionary.com/define.php?term=Cock-up%20Cascade. Can
you fix it or you need some more help with that?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/gitcoinco/web/issues/3628#issuecomment-459058631, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Ar1NZ1m3hpYQGPhC-ARsJLTuA4EaZ9_6ks5vIea7gaJpZM4aW2Iz
.

[owocki]

here's a hint for all the bounty hunters out there.. this commit ( https://github.com/gitcoinco/web/commit/b47501d1dc8e4bfa4f662856a3ed7547c308beff ) gets the response time down by a factor of 4. i think that (1) theres too many foreign keys being referenced (2) theres too much on-demand computation to return an API result.

[markusj1201]

Kevin,

The amount of required resources need to be minimized or reduced to up
processing speed, that part is easy. Identifying which vectors to
re-mediate/reduce and how to properly code and implement said remediation
will take me a little more time. First thought is to reduce payloads,
possibly uglify.js to minimize the ES5...or possibly splitting up the code
to crit. noncrit?
If you like I can upload a sample snippet?

Mark

On Wed, Jan 30, 2019 at 9:04 PM Kevin Owocki [e-mail]
wrote:

here's a hint for all the bounty hunters out there.. this commit ( b47501d
https://github.com/gitcoinco/web/commit/b47501d1dc8e4bfa4f662856a3ed7547c308beff
) gets the response time down by a factor of 4. i think that (1) theres too
many foreign keys being referenced (2) theres too much on-demand
computation to return an API result.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gitcoinco/web/issues/3628#issuecomment-459197372, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Ar1NZ22YfxDZyx8bZAhWayreM7xCkRxNks5vIl0_gaJpZM4aW2Iz
.

[FirefighterBlu3]

@owocki there's a whole lot more to Silk. Silk is capable of doing python call profiling which will yield a call graph, how many times each function or method is called, and time spent in each function/method. you can configure it to only profile for the bounty view.

the on-demand computation is excessive, yes. there are many calculations done for all of the properties. this is why we need to employ Silk to profile the view. doing it by hand will take considerable time and be error-prone. using Silk to profile it for exact numbers will likely let us cut down a drastic load with only a few changes.

commit b47501d voids a bunch of functions with immediate "return" for the majority of it. that's disingenuous. if the functions aren't going to be used, remove the calls to them from the view or in entirety. has the impact been studied for other code paths that call them?

PK and FK aren't expensive for reads, they shouldn't even be used. they're only expensive (doubtful) when doing modification DDL.

it's eye-catching that we select every row then permutationally filter things. IMO, the query should be built in the opposite direction. we ought to consider caching queries and results as well. all the heavy lifting of filtering and property computation would become a small factor of what it is now. it's a tradeoff for ram.

[kuhnchris]

Well, actually there even should be a cache available, we could fill that once and then invalidate the cache every 5 minutes, it's even used at some other point in the django project already. aside from that, solving the source would be the "cleanest" solution, even if it's just directly limit the query with up to x rows. If it's just about the "calls" I can sync rinkeby on my server and output a silk profile file for you @FirefighterBlu3 & @markusj1201 , then we can at least trace what selects are being affected. Let me know if you guys want me to do that.

[markusj1201]

Chris,

I would greatly appreciate that, thank you. I've included the chrome audit
URL here. >gitcoin_api.audit
https://gitcoin.co/issue/gitcoinco/web/3628/2217<

Mark

On Thu, Jan 31, 2019 at 1:47 PM KuhnChris [e-mail] wrote:

Well, actually there even should be a cache available, we could fill that
once and then invalidate the cache every 5 minutes, it's even used at some
other point in the django project already. aside from that, solving the
source would be the "cleanest" solution, even if it's just directly limit
the query with up to x rows. If it's just about the "calls" I can sync
rinkeby on my server and output a silk profile file for you
@FirefighterBlu3 https://github.com/FirefighterBlu3 & @markusj1201
https://github.com/markusj1201 , then we can at least trace what
selects are being affected. Let me know if you guys want me to do that.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gitcoinco/web/issues/3628#issuecomment-459480588, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Ar1NZyg-XO0b29pE8ulOVY-udBIjDPUKks5vI0g1gaJpZM4aW2Iz
.

[markusj1201]

I am going to start by: minifying the number of critical resources:
eliminating them, deferring their download (lazy load), mark them as
asynchronous, etc, optimize the number of critical bytes to reduce the
download time , up and back, address the order in which the remaining
critical resources are loaded: download the critical assets as early as
possible which will shorten the critical path length.
Also, are we sharing a project repository in Github?
My apologies, I just started working on this yesterday.

Markus J

On Thu, Jan 31, 2019 at 1:54 PM Mark Nations [e-mail] wrote:

Chris,

I would greatly appreciate that, thank you. I've included the chrome audit
URL here. >gitcoin_api.audit
https://gitcoin.co/issue/gitcoinco/web/3628/2217<

Mark

On Thu, Jan 31, 2019 at 1:47 PM KuhnChris [e-mail]
wrote:

Well, actually there even should be a cache available, we could fill that
once and then invalidate the cache every 5 minutes, it's even used at some
other point in the django project already. aside from that, solving the
source would be the "cleanest" solution, even if it's just directly limit
the query with up to x rows. If it's just about the "calls" I can sync
rinkeby on my server and output a silk profile file for you
@FirefighterBlu3 https://github.com/FirefighterBlu3 & @markusj1201
https://github.com/markusj1201 , then we can at least trace what
selects are being affected. Let me know if you guys want me to do that.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gitcoinco/web/issues/3628#issuecomment-459480588,
or mute the thread
https://github.com/notifications/unsubscribe-auth/Ar1NZyg-XO0b29pE8ulOVY-udBIjDPUKks5vI0g1gaJpZM4aW2Iz
.

[owocki]

commit b47501d voids a bunch of functions with immediate "return" for the majority of it. that's disingenuous.

of course! i only did it to demonstrate what performance would look like when this is all optimized. its not a final solution by any means, just a demonstration of where the slow points in the API call are.

there's a whole lot more to Silk. Silk is capable of doing python call profiling which will yield a call graph, how many times each function or method is called, and time spent in each function/method. you can configure it to only profile for the bounty view.

sounds useful to me!

minifying the number of critical resources: eliminating them, deferring their download (lazy load), mark them as asynchronous, etc,

download the critical assets as early aspossible which will shorten the critical path length.

when you say things like this, or submit a PR with a bunch of boilerplate about frontend optimizations, it makes me concerned you maybe haven't understood the task. the scope of the task is simply to improve the performance of the gitcoin API (the logic for all of which, is housed on the backend, in python). there's only one HTTP request being made here, and lazily downloading assets, asyncronoulsy downloading assets, will not help here. please just start with actually profiling the API code and work forward from there.

[markusj1201]

Roger that.

On Thu, Jan 31, 2019 at 4:16 PM Kevin Owocki [e-mail]
wrote:

commit b47501d
https://github.com/gitcoinco/web/commit/b47501d1dc8e4bfa4f662856a3ed7547c308beff
voids a bunch of functions with immediate "return" for the majority of it.
that's disingenuous.

of course! i only did it to demonstrate what performance would look like
when this is all optimized. its not a final solution by any means, just a
demonstration of where the slow points in the API call are.

there's a whole lot more to Silk. Silk is capable of doing python call
profiling which will yield a call graph, how many times each function or
method is called, and time spent in each function/method. you can configure
it to only profile for the bounty view.

sounds useful to me!

minifying the number of critical resources: eliminating them, deferring
their download (lazy load), mark them as asynchronous, etc,

download the critical assets as early aspossible which will shorten the
critical path length.

when you say things like this, or submit a PR with a bunch of boilerplate
about frontend optimizations, it makes me concerned you maybe haven't
understood the task. the scope of the task is simply to improve the
performance of the gitcoin API (the logic for all of which, is housed on
the backend, in python). there's only one HTTP request being made here, and
lazily downloading assets, asyncronoulsy downloading assets, will not help
here. please just start with actually profiling the API code and work
forward from there.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gitcoinco/web/issues/3628#issuecomment-459527735, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Ar1NZ5HhAqz9TN-5Yn4h6pO0IGj-O_bEks5vI2s-gaJpZM4aW2Iz
.

[FirefighterBlu3]

@owocki fyi, your previous comment is about two authors. i wrote the first half, @markusj1201 wrote the second half :)

[markusj1201]

Thanks David.

On Thu, Jan 31, 2019, 5:07 PM David Ford <[email protected] wrote:

@owocki https://github.com/owocki fyi, your previous comment is about
two authors. i wrote the first half, @markusj1201
https://github.com/markusj1201 wrote the second half :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gitcoinco/web/issues/3628#issuecomment-459541471, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Ar1NZ1jV70ymU3Aa2-r0GJSaPkWvYCPPks5vI3cTgaJpZM4aW2Iz
.

[oogetyboogety]

@owocki The main issue appears to be each bounty's related interests being looped through and a roundtrip query for each one. I'll see if we can prefetch it somehow.

[oogetyboogety]

@owocki @kuhnchris @FirefighterBlu3 @markusj1201
Before:

2019.02.01 23:59.422
200 GET
/api/v0.1/bounties/
524ms overall +599ms
63ms on queries +91ms
60 queries +127

After:

200 GET
/api/v0.1/bounties/
360ms overall +200ms
19ms on queries +32ms
12 queries +29

[markusj1201]

Nice work.

On Fri, Feb 1, 2019, 6:22 PM oogetyboogety <[email protected] wrote:

@owocki https://github.com/owocki @kuhnchris
https://github.com/kuhnchris @FirefighterBlu3
https://github.com/FirefighterBlu3 @markusj1201
https://github.com/markusj1201
Before:

2019.02.01 23:59.422
200 GET
/api/v0.1/bounties/
524ms overall +599ms
63ms on queries +91ms
60 queries +127

After:

200 GET
/api/v0.1/bounties/
360ms overall +200ms
19ms on queries +32ms
12 queries +29

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gitcoinco/web/issues/3628#issuecomment-459912756, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Ar1NZ39e2M4PX0r6KRgaQkexf8A2dNHcks5vJNpWgaJpZM4aW2Iz
.

[owocki]

Awesome! Can you submit a PR!?

What di you use to generate those stats?

On Fri, Feb 1, 2019 at 5:22 PM oogetyboogety [e-mail]
wrote:

@owocki https://github.com/owocki @kuhnchris
https://github.com/kuhnchris @FirefighterBlu3
https://github.com/FirefighterBlu3 @markusj1201
https://github.com/markusj1201
Before:

2019.02.01 23:59.422
200 GET
/api/v0.1/bounties/
524ms overall +599ms
63ms on queries +91ms
60 queries +127

After:

200 GET
/api/v0.1/bounties/
360ms overall +200ms
19ms on queries +32ms
12 queries +29

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gitcoinco/web/issues/3628#issuecomment-459912756, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAfXiarWXc82KFt9epimpJAo4KpBqHafks5vJNpVgaJpZM4aW2Iz
.

--

@owocki http://www.twitter.com/owocki

---

check out what i'm building on github http://github.com/owocki

or what i'm shooting on photoshelter http://photography.owocki.com/

or find me on twitter http://www.twitter.com/owocki, facebook
http://www.facebook.com/kevinowocki, instagram
http://instagram.com/owocki, linkedin http://www.linkedin.com/in/owocki,
and owocki.com http://www.owocki.com/?utm_source=emailsig.

see you around teh internets!

PS -- Come to the next Boulder Blockchain
https://www.meetup.com/Boulder-Blockchain/ meetup. Be there or be ^ 2.
PPS -- Have I mentioned that Gitcoin is live? More @ https://gitcoin.co

[oogetyboogety]

@owocki I used the django silk profiler already built into gitcoin. The callgraph it generated also shows roundtrip db queries to get avatar urls for each profile in ProfileSerializer. It shows the prefetched queryset gets invalidated here:
https://github.com/gitcoinco/web/blob/master/app/dashboard/models.py#L2081

So prefetching active avatars is what i will wrap up today to finish work on this pr:
https://github.com/gitcoinco/web/pull/3662

[oogetyboogety]

@owocki Wrapped up prefetching of avatar urls. @kuhnchris got silk working as well, so he may be able to checkout these changes and time them for you. You can also just time the curl request like you were doing before.

Now there are dashboard tips that accumulate queries and on demand computation. These could also be condensed into one query. We should set the scope for this particular issue; IMO we could scope this issue to the related profile avatars, dashboard activities, and dashboard interests. Then we can open another issue for prefetching dashboard Tips and other miscellaneous API model classes. Take a look at changes I made in dashboard/models.py to properties that have lines that invalidate prefetched or cached querysets. It's recommended to store cached, prefetched querysets by Django docs in order to query less and increase cache hits over misses while still avoiding confusion:
Using to_attr is recommended when filtering down the prefetch result as it is less ambiguous than storing a filtered result in the related manager’s cache:
https://docs.djangoproject.com/en/2.1/ref/models/querysets/

I would also recommend you use the built in HTTP caching headers on your external API requests from python either to Github or the currency conversion microservice. An example of how to do this might be this library:
https://github.com/ionrock/cachecontrol

[FirefighterBlu3]

I would still like to get a copy of the python function call profiling results. Would @oogetyboogety or @kuhnchris please share them with me?

[kuhnchris]

sure, depend on from what, the API call? hit me up on Slack (@kuhnchris) and I'll give you access to the test system I used.

[owocki]

@oogetyboogety i just responded on the PR.

btw, how many bounties are in the profile you submitted at https://github.com/gitcoinco/web/issues/3628#issuecomment-459912756 ? i cannot repro those results

[oogetyboogety]

@owocki I just responded to your response! Please take a look at your earliest convenience.
That profile that I posted was for the first 25 rinkeby bounties at offset 25. I tested further with many more mainnet bounties now.

[gitcoinbot]

⚡️ A tip worth 0.75000 ETH (102.13 USD @ $136.18/ETH) has been granted to @oogetyboogety for this issue from @owocki. ⚡️

Nice work @oogetyboogety! Your tip has automatically been deposited in the ETH address we have on file.

• $61328.16 in Funded OSS Work Available at: https://gitcoin.co/explorer
• Incentivize contributions to your repo: Send a Tip or Fund a PR
• No Email? Get help on the Gitcoin Slack

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

__This Bounty has been completed.__

Additional Tips for this Bounty:

• owocki tipped 0.7500 ETH worth 102.13 USD to oogetyboogety.

---

• Learn more on the Gitcoin Issue Details page
• Questions? Checkout Gitcoin Help or the Gitcoin Slack
• $60,919.62 more funded OSS Work available on the Gitcoin Issue Explorer

[owocki]

http://bits.owocki.com/dd903ddf4103/Image%202019-05-13%20at%209.34.17%20AM.png

API on the gitcoin explorer is regularly taking 5s - 20s to return. it didnt used to be this slow. i wonder if it’s a performance regression.

[kuhnchris]

Hey there @owocki - did you turn on the SILK Profiling, e.a. can you check where the bottle neck is (database, API, Django, ...)

[oogetyboogety]

@kuhnchris @owocki FYI I'm sure I made this clear enough but again I had trouble running the Silk profiler until i used these two commits:
https://github.com/gitcoinco/web/pull/3781/files#diff-3f9737c05a00f8739afebff6239e18f4
https://github.com/gitcoinco/web/pull/3781/files#diff-3dc4970f50a896f3b3911da07a463c47

Should I make a separate PR so that these might be merged? What do you guys think?

Thanks for your input, hope I'm not leading us in the wrong direction with these commits. Once you do merge them into your current branch, you can run the Silk profiler on the Django Rest Framework API or the dashboard model's methods.

If you think it would be helpful, I could attach some general traces and logs I generated using Silk with DRF and dashboard methods

[kuhnchris]

Hey there @oogetyboogety - thanks for checking in. At this point it looks like your code is commenting out a bit too much, so we prolly have to re-check it. But the idea to add the render functions and other apps to the dynamic SILK profiling makes sense, we just have to extend it to the other apps aswell.
Since @owocki didn't come back at us yet I don't think anything happened up to this point.

@owocki any update for us on that?

Thanks!

[owocki]

no i didnt turn on django silk profiler. my assumption was that whomever was going to do this ticket was going to do that. after all the scope is "Profile the Gitcoin API and figure out why it's slow"

it's fairly easy to do after running sync_geth to pull the bounties from the mainnet.

i tried multiple times to get #3781 to work but never was able to. i posted notes on that PR

[kuhnchris]

So you are saying the issue is bad enough that you actually want to merge in productive slowing-down profiling code instead of just doing a profiling session?
I mean, fair enough, it's just that you shouldn't really ever do this on prod...

We can send in a PR to activate SILK, no problemo...
but please be aware of the security risks of exposing those things to the public, we need to ensure it's at least password protected, if not protected better via authorizations, no idea how the silk default app is, but I think anyone can access it?

Anyways, I'll leave it to the people who know SILK more than me, not getting this blood on my hands.

[owocki]

i did not say that at all, no.

[oogetyboogety]

Hmmm i was thinking there is the ENABLE_SILK option in the code for dev, environment. The two commits I referencex fix thst option for the dev environment, and for prod i sugvest we sit down for a ssssion as suggested. I at least got it working ad well as a call graph with metrics if you guys want to take a look at that

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: Kevin Owocki [e-mail]
Sent: Monday, May 20, 2019 5:48:27 PM
To: gitcoinco/web
Cc: oogetyboogety; Mention
Subject: Re: [gitcoinco/web] Profile the Gitcoin API and figure out why it's slow. (#3628)

i did not say that at all, no.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/gitcoinco/web/issues/3628?email_source=notifications&email_token=AAZKLVU5W3NTEI2WJWWKWHDPWMMCXA5CNFSM4GS3MIZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV2FJ2Q#issuecomment-494163178, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAZKLVRQK6BGU5O42JLEQYTPWMMCXANCNFSM4GS3MIZQ.