I've setup an Apollo Server GraphQL API to get some data from a remote MongoDB database, hosted on Atlas. Now, if I run the server in localhost, using the server less framework, every request I made to the MongoDB server takes around 8-10ms, which is good. However, if I do the same request, to the same server, from a Lambda hosted on eu-west-1, that request takes around 90-130ms! And the worst part is that I need this Lambda to run on us-east-1, where there takes even longer (around 400ms!).
What could be the cause for this slowdown? I'm not talking about the first request, that takes over a second, but I guess is because of the Lambda starting...
I've set up a sample repository so you can see if this slowdown is related to some wrong configuration
https://github.com/GimignanoF/SampleApolloLambda
Related
For this project, I am using a prisma / Postgres database. I have made no changes to my code, and I have pulled a coworkers working version of the code to no avail. I am unable to do anything with the database, I cannot migrate, I cannot run mutations, and I cannot even open the psql console, as every command is met with
P1001: Can't reach database server at localhost:5432
Please make sure your database server is running at localhost:5432
I am not sure what I could have possibly done, I don't know enough about ports or even the contents of app.json well enough to have messed anything up. Now, no mutations can go through.
Interestingly enough, this all happened after I ran npx primsa migrate deploy on the deployed database which is on a EC2 VM from AWS. Since then, the native app associated with the database refuses to work, though it is worth nothing that the webapp connects to the deployed database just fine. This being said, nothing works locally, as the database / Port / Server don't exist anymore according to my machine, which makes no sense. I have no idea how to try to re-spin it, or why every single query / mutation from my Native App now ONLy returns Response not successful: Received status code 400 despite it having the same exact syntax it did when it worked, as well as the WebApp having the same syntax and server (ExpressJS). Does anyone have any ideas what could be causing this?
The error code 400 refers to a bad request coming from the client: too large request, malformed syntax, invalid request message framing, etc.
First step: make sure that your database server is indeed running. Try connecting to it with other SQL Clients or Libraries. Sometimes Prisma is just being difficult.
Second thing: are you hosting the database on the local server? I can assume you are because of the localhost. Make sure no other programs are using this port or maybe waiting for it.
Sorry if this doesn't help. Good luck!
I have a cloudformation stack that's creating an ACM Certificate. The code worked fine yesterday, and so I move it into being a nested stack.
The template is from a pretty nifty example. I have a hosted zone, and that's where I'm requesting the certificate, and the template has a Lambda function which is supposed to look at the Cloudformation events, get the request for the magic DNS entry, and write that DNS entry into the hosted zone to effect DNS validation of the cert request.
The Lambda instances, gets the info from CF, and writes it to the hosted zone. Everything it's supposed to have done (and did fine yesterday) has happened.
And it's not even timing out. The error I get is:
Waiter StackCreateComplete failed: Max attempts exceeded
Any ideas? I've seen AWS take it's sweet time marking certs as good doing this by hand in the GUI.
Upon closer examination it became clear that this message was from the boto3 client, not AWS, and that the default timeout for the client was the same as on the template.
Modifying the template timeout to 12 hours and rerunning the command still results in that message being generated, but the GUI shows that it's still running.
I have been working with using Strapi as my backend service and connecting it to my MongoDB Atlas instance and it is running and works. However, when I make http requests from my front-end, it takes up to 12 seconds to retrieve the response. My response is a very small JSON response (array of 3 objects with only 5 properties). However, it seems when I log into the admin portal and force the Strapi app to run, the requests are instant. I understand this may be an issue with the dynos cycling, but what solutions are there to this?
The reason you have this because of Heroku dynos basically turn-off after 30mins of inactivity. So next time when you ping the server/API, it takes some time to start again. The easiest way to go around is, have the Heroku service being pinged every x intervals (can be hour/day).
You can use services like this (http://easycron.com/) to set up a CRON to ping the Heroku service.
Hope it helps :)
I have an application that is using the upper.io/db package for communication with a Mongo database server (which is a fairly simple wrapper around gopkg.in/mgo.v2). The way the application works is that it creates a session in the main thread on start-up, and then each individual go routine that needs to make requests to the mongo server calls Clone on the session and does a defer session.Close on the resulting value. As far as I can tell, this is all standard operating procedure.
This setup works without any errors in our development environments where we are either using a locally run MongoDB or a sandbox instance on MongoLab. Recently we promoted the application up to our staging environment where we have the application talking to a Shared Cluster instance of MongoDB on MongoLab (the cheapest 15$ option). This is where the weirdness starts happening. The /first/ request that goes through (from the first go-routine that gets invoked) comes back with the expected response, but the subsequent ones all return
read tcp <ip address>:47112: i/o timeout
This happens both from our local development machines pointed at the cluster or from the AWS host for the staging environment. Since the Mongo cluster is from Mongolabs I am going to assume that they've configured everything correctly on their end.
The code is somewhat boring TBH: It literally just opens the session in the main function and maintains a reference to it, and then there are multiple goroutines with this basic structure:
sess := session.Clone()
defer sess.Close()
// make requests to Mongo
During testing, I even restricted it to run only one thing at once (i.e. only one goroutine is active at any given time), and it still fails in the same fashion.
Has anybody run into this before? Do I need to configure upper.io/db in a specific fashion? Maybe use mgo directly? I am at my wits end with this :(
In a rather long and grueling process, we finally tracked down where this issue and similar ones like it came from in our program. It ended up being a session leak in the v1 version of the upper.io/db library. The bug and fix are outlined here, but the v1 version of this library is horribly outdated at this point and the later versions do not exhibit this issue.
I doubt this answer will be useful for anybody so late in the game (especially since we ourselves solved it like.. 3 years ago at this point), but just wanted to leave the answer here for completeness.
I'm evelauting using thie service. http://www.freegeoip.net/ & i quote the text below.
The freegeoip web server is free and open source so if the public service limit is a problem for you, download it and run your own instance
The public service limit of 10,000 queries per hour by default might or might not be a problem for me, so i just want to take the safe route early enough by downloading it and running my own instance.
However, i have zero experience on deploying such a server. Does any one here have or know of a walk-through that can get me started deploying my won instance. Can i host this server on windows or my own instance must be hosted on a linux server?
My site is hosted in IIS on windows.