Home / server / Questions / 938061
In Process
Hudi Ilfeld
Asked: 2018-11-01 07:15:41 +0800 CST

Receiving i/o failure on parse server

  • 772

I am using parse server as a BAAS for my android app. Everything Is working like a charm, except, when I use the app as a single user intensely I.E. if I send several requests in a very small span of time (refreshing the data many times quickly) from my android client to the parse server, the server freezes. and I get a message back from my cloud function saying: "i/o failure".

I am not getting any info in my parse.logs file related to the issue besides the "i/o failure" message on client-side I would be more then happy to understand the cause for this issue. and I how to resolve it.

Environment Setup

Server

parse-server version: 1.17.3

Operating System: Ubuntu (Bitnami image)

remote server? AWS

Database

MongoDB version: v3.0.9

Localhost

parse-server

1 Answers

  1. There's a few things you'll want to look at.

    1) You're probably using like a t2.micro instance. Those are suited for development / prototyping, but not production. The whole t series is, really. Find the general use one, at least. Though, depending on your use case, others might be better.

    2) Optimize your requests. When you refresh in app, cancel open requests instead of letting them complete for naught. try to bundle what you can. Do things in series instead of parallel to minimize concurrent open connections

    3) Make sure you properly index your database. parse-server doesn't automatically create indexes, so doing a bunch of queries can reallllly pound your database hard, make it take way longer to get data, which causes the whole server to get backed up. If you're on mlab for your database, open up their console and go to the slow queries tab for the cluster. cmd/ctrl + f - "build index", and build every single one.

    To be honest, #1 is a scaling issue. Unless you have a sizeable user base, you should be able to get by with 2 and 3. It sounds like you're doing those reallllly poorly, and your app is trying to do way too much at once that it shouldn't be, and doing what it's doing inefficiently. We used a t2.micro for our server for over a year without issue, though that was with minimum 2 instances on an EB app with auto scaling.

    • 1