How scalable is Parse?

Question

I was considering using Parse.com for my backend, but I am skeptical about its scalability.

Can it handle several thousand concurrent users? If not, can there be any good way to give them up?

Answer 1

I know the question may be old, but wanted to provide my 2 cents for others that might consider parsing ....

In the simplest of scenarios, analysis may work well. As soon as you need to scale to more complex queries, I personally have not found anything but headaches.

• Requests are limited to 1000 entries. Initially, you might think that this is not a problem until you begin to deal with subqueries and realize that strange data is being returned because the subquery cuts records without warning or error. (FYI, the default is 100 entries, unless you specify a limit to 1000, so the problem is even worse if you don't pay attention).

• For some strange reason, there is a limit on the number of times you can issue a count request in minutes. (and this limit is really very low). Be prepared to try and throttle your code so that you do not fall into this limit, otherwise errors will be thrown.

• Background jobs do not work reliably. I had a background job task that runs every 5 minutes, and there is a time when it takes 20+ minutes before work starts.

• Lots of timeouts. This is the one that gives me the most heartburn. A. If you have a cloud function that takes time to process, you have about 6 or 7 seconds to execute it, or it will shut you down.
  B. I get the feeling that there is general instability in the system. Periodically, I run into problems that seem to go on for about an hour or so when timeouts happen more often (and with relatively simple functions that should return immediately).

I am completely sorry for my decision to use parsing, and I am doing my best to support the application long enough so that we can receive financing so that we can leave the platform. If anyone has the best alternatives to parsing, I'm all ears.

Answer 2

[Edit: after three amazing years with the team, I decided to move on and am no longer an employee of Parse or Facebook. The team is in excellent hands and did amazing things. The entire backend has been rewritten to significantly improve performance and reliability. The roadmap is astounding, and I expect big things to come from the team. During my departure, Parse powered over 600,000 applications and submitted a huge amount of requests every day. If every single Parse was sent to a unique person, he could make up the fourth largest country in the world in one day. For further assistance with Parse, please post questions here with the parse.com tag or mailed to the Google development team.]

Full disclosure: I am an analyst engineer.

Parse already has thousands of applications, not to mention users. When we left the beta at the end of March, it announced over 10,000 applications running on Parse, with growth rates of 40% over the previous month. Parse is staffed by a world-class team, many of whom have many years of experience working with large volumes of data and large amounts of traffic.

We welcome your traffic with open arms; You will be in the company of great teams such as Band of the day and Hipmunk . We are so confident in our services that we built our One Click Export so that people like you can try without the risk of analysis. If you feel that Parse does not meet your performance expectations, we will gladly send you with the saved data.

Answer 3

We chose Parse as the basis for our application. Conclusion: NOT NOT.

Stability is a disaster, performance is also a disaster, as well as support (probably because they cannot help you because all problems cannot be reproduced).

Performing even the simplest functions can lead to random timeouts inside Parse (for example, we are talking about simple login entries in PFUser):

Error: Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo=0x17e42480 {NSErrorFailingURLStringKey=https://api.parse.com/2/client_events, NSErrorFailingURLKey=https://api.parse.com/2/client_events, NSLocalizedDescription=The request timed out., NSUnderlyingError=0x17d10e60 "The request timed out."} (Code: 100, Version: 1.2.20) 

We run into timeouts every day, and this is due to the fact that we are testing 10 max users!

This is typical, which we return all the time, in completely arbitrary moments and cannot be reproduced. Calling the Cloud Code function, which performs multiple requests and multiple inserts:

  {"code":124,"message":"Request timed out"} 

Try the same 10 minutes later and it will pass in less than a second. Try again after 20 minutes and it will take 30 seconds to complete.

Since the transaction does not exist, it is actually very funny when storing, for example, three objects in 1 Cloud Code function, where Parse decides to get rid of the function randomly after I say that I saved 2 of 3 objects. Great for your database to be consistent.

"Best" we got where they are. Keep in mind that this is the actual data returned from the Cloud Code function:

  {"code":107,"message":"Received an error with invalid JSON from Parse: <!DOCTYPE html>\n<html>\n<head>\n <title>We're sorry, but something went wrong (500)</title>\n <style type=\"text/css\">\n body { background-color: #fff; color: #666; text-align: center; font-family: arial, sans-serif; }\n div.dialog {\n width: 25em;\n padding: 0 4em;\n margin: 4em auto 0 auto;\n border: 1px solid #ccc;\n border-right-color: #999;\n border-bottom-color: #999;\n }\n h1 { font-size: 100%; color: #f00; line-height: 1.5em; }\n </style>\n</head>\n\n<body>\n <!-- This file lives in public/500.html -->\n <div class=\"dialog\">\n <h1>We're sorry, but something went wrong.</h1>\n <p>We've been notified about this issue and we'll take a look at it shortly.</p>\n </div>\n</body>\n</html>\n"} 

I am not describing here what happens once in the blue moon in our project. With the exception of 500 errors (which I met twice a month), all the rest are observed daily.

So, it’s very easy to get started with this, but you have to take into account that you are working on an unstable platform, so make sure you earn your retries and exponential deferral systems because you need it!

What excites me the most is that I have no idea what will happen when 20,000 people start using my application on this server.

edit:

Right now I have this when logging into PFUser:

 Error: Error Domain=PF_AFNetworkingErrorDomain Code=-1011 "Expected status code in (200-299), got 502" UserInfo=0x165ec090 {NSLocalizedRecoverySuggestion=<html><body><h1>502 Bad Gateway</h1> The server returned an invalid or incomplete response. </body></html> , PF_AFNetworkingOperationFailingURLResponseErrorKey=<NSHTTPURLResponse: 0x16615c10> { URL: https://api.parse.com/2/get } { status code: 502, headers { "Cache-Control" = "no-cache"; Connection = "keep-alive"; "Content-Length" = 107; "Content-Type" = "text/html; charset=utf-8"; Date = "Mon, 08 Sep 2014 13:16:46 GMT"; Server = "nginx/1.6.0"; } }, NSErrorFailingURLKey=https://api.parse.com/2/get, NSLocalizedDescription=Expected status code in (200-299), got 502, PF_AFNetworkingOperationFailingURLRequestErrorKey=<NSMutableURLRequest: 0x166f68b0> { URL: https://api.parse.com/2/get }} (Code: 100, Version: 1.2.20) 

Is not that great?

Answer 4

If you are writing a small / simple application (or prototype prototype) with almost no logic on the backend, then go for it, but for something larger / more scalable it is best to avoid it, I can say that from the first it’s a manual experience. All this sounds good with their user management, push notifications, abstract storage, and what not, but in the end it is not worth the problem. Namely, I developed the backend for the application on Parse, the customers were so much in it because it sounded cool and promising (strong marketing, I think) that Facebook bought and what not, but a few weeks in the production of significant problems / limitations Since the platform began to emerge, what should be a simple application turned out to be a nightmare for development and scaling.

The result / conclusion of the project: - broke the time window for a relatively simple application - it should have lasted 2-3 months, it lasted almost a year and is still not stable / reliable if we used our own stack, which he would make in the time window for I’m sure that I did a similar demo project in 5-10 days using the user node stack - they lost the trust of customers, now they are redoing the application with another team that will use their own stack - lost cash for violating time alternating windows and trying to get it to work - has done so much overtime because he began to think about my health - never use any platform / solution that promises to have it all, always using specialized / certified stack

At first there were problems with stability and constant platform failure, for example, server downtime and random errors, but they were all sorted (this was in the beginning or middle of 2014), but the following problems remain:

• you cannot debug your code, at least for the moment (there are ways to make it work with an additional node server and some obscure library)
• the limits are ridiculous, a scalable platform that can execute 50-60 API requests per second (or more depending on your subscription), which is not so small until you start to experience stress, and when you click it your code will constantly fail .
• API calls are measured as follows: server function call (analysis task) - 1 call, database query - 1 call, another request (because they do not have any advanced / complex query system, if you have a more complex scheme databases, you will soon understand what I mean) - 1 call, if you need to get more than 1000 requests, guess what - the request again, etc., the request for counting (you need to do this as a separate request), which is unreliable (tends to return an approximation for several thousand records).
• Creating / saving ~ 1000 + simple objects is a load on the platform / database, deleting 1000 or more objects, especially since it is ridiculously fast for regular databases, but on Parse it tends to take 5-10 minutes (if you check it more in detail, it will remove 20 objects per package).
• Unable to use most npm packages (only pure JS files, including the source directly)
• if you go and read the Parse forums, you will see that users started / burned the Parse team constantly for the platform lacking functions and needed to go through hoops for an arbitrary logical implementation, for example, choosing random entries and similar materials.
• they support integration with Stripe, but if you want to use Paypal or some other payment service (we decided to use Paypal because it has significantly better country support for Stripe), you cannot get it to work on Parse, for Paypal integration I had to use a separate server to disable it.
• there is no easy way to synchronize users and handle concurrency problems, you should use hacks and some kind of funny logic that you would not use or allow, using nowhere
• I want 100+, not to mention 1000+ concurrent users, good luck deleting this.
• when you want to know the number of records in a table, you can reach the limit when calling the count request, which is funny, not documented and completely funny, and in the end returns an approximate number
• modularity is not an alien platform, the functions that you call from your tasks cannot last more than a couple of seconds (7 seconds, I think), and when you take into account the request time, which it must happen with a lot of complex requests and some complex logic
• You may have something like Cron jobs, but they cannot last more than 15 minutes (due to low platform performance, for example, several requests, very, very short), they are limited to 2-3-4 simultaneous tasks depending on your monthly fee and having a very limited / poor scheduling system (for example, you cannot edit it from your code, it is very limited, so you need to use hacks to do the exact same job 2 times accurate during the day or something like he can't keep track of the econ mission time, etc.).
• When you get an error message on the server, this may be completely wrong, check the forums for this, I don’t remember anything from my head.
• Push notifications are regularly delayed for 20-30 minutes.

An arbitrary example: you want to get a random element from your database, the application makes a call to the task that will provide it (1 API call), the task requests the database, but you need to make 2 calls, first get the number of elements (1 API call), and then the second, to get a random element (1 API call), these are 3 API calls for this function and with 60 requests per second, 20 users can make that call at a given time before getting into the request limit, and the platform going haywire. after you turn on other users, browsing application screens and more, you’ll see where it leads ...

If it was good, would Facebook not buy it if it mentioned using it even for some of its applications? I would suggest 3 things: - first - do not listen to Pars Pars, this is his platform, so he must promote it, listen to people who used it to do something, using it
- second - if you need a serious and scalable platform and you do not want to fully configure, go to the Amazon Cloud services or something similar that is tested and reliable - thirdly - stay away from the platform if you have experience working on the side server, if you don’t go and hire a backend dev for the project, it will be cheaper and you will end up with a working solution.

Answer 5

I spent the day looking at parse.com, and here is my current opinion based on what I found (Please keep in mind that I only have a very short development experience with the SDK so far).

Parse.com clearly has some very attractive positives, so I found myself looking at it, but for discussion I will concentrate on being critical, since all the positive results are listed on their website. (Well done parse.com for trying to solve such a big problem!) ...

• In reviews, Hipmunk is the biggest name I would say. It is listed as an application that uses part of the SDK data. Without getting close to the Hipmunk developers, I don’t know for sure, but I can’t imagine how they store ALL of their data in the parse.com cloud.
• After viewing and viewing most of the listed applications. No one really stands out due to the fact that it is very dependent on the server side, so I can not understand if scalability was solved using parse.com based on this data.
• The website lists 40,000 applications and counts. I feel (but don’t know) that, based on the application gallery, this figure is based on the number of applications in their user base, and not real live applications in applications. The app gallery will display much larger names if many apps use parse.com.

Parse.com is a very new concept and very different even from its closest competitors. Thus, without concrete evidence of how scalable and stable (and everything else), it is very difficult for the project developer to consider doing this because too much is at stake.

Answer 6

I conducted tests for my own answer to a similar question , and it can be VERY, VERY FAST. However, your results may depend on the details of your implementation ...

The test compares the Android SDK with Android, using its own HTTP stack that creates Parse / REST calls ...

Test Details:

The test environment is the latest version of Android on a 10-month-old phone over a fast WIFI connection.

(upload 63 snapshots where avg filesize = 80K)

test 1 using android SDK SDK = slow performance

test 2 using native REST calls through android RESULT = VERT FAST

- EDIT - as there is interest here ....

As for http thruput, parsing the SDK (android) and performance, maybe parse.com hasn't optimized performance on how they implement android asyncTask () in the parse.android SDK? Like a job that takes 8 min. on parse.sdk can be done in 3 seconds on an optimized REST, DIY structure (see links for implementation details), I really don’t know. If the parsing did not fix the SDK implementation, as these benchmarks were run, then you probably do not want their default asnycTask files to do anything close to the actual network workload by default.

Answer 7

The big attraction with Parse (and similar SaaSs) is that you can save tens of thousands on development costs. Given that the back-end is often the most expensive aspect of a web application; that head-ache suddenly poof.

The problem with Parse and most (all) SaaS is that the scope, power, memory, bandwidth, scalability, thresholds, warnings, and various actions are out of your control.

Same thing with Shopify. This is a great saas with full control of products, orders, inventory and aesthetics, but without control of the machine. So, today SaaS is not a hell of a lot different from godaddy. They always resell or maximize their cars to make money; and you get stuck if you really care about ass performance. You cannot even buy this level of service.

I would like something AT LEAST to be as powerful and comprehensive as the AWS console. Most techies know and accept that Heroku and Parse are both hosted on AWS. What's the difference. Therefore, pay more for the added service, but do not prohibit access to those critical low-level tools that make the site and application, and the zing user interface. Hint for Parse staff.

In any case, in response to the question:

Parse API is plain JSON. This way you can pump out data in the same JSON format that Parse is expecting.

You might even be able to use your PFObject (iOS). At some point, all these high-level APIs go to a common HTTP request / response. The good thing about the general nature of REST is the usual framework; things like http, url, strings and utf. There is no funky here.

Answer 8

Parse works great with especially helper / user management features. But I started to run into problems.

Long lead / ping time, limitation of 1000 objects INCLUDING subqueries, no data centers in Europe (as far as I know)

It would be a divine platform, if they could sort the problems of productivity and stability. I somehow regret it, but I put 5000 lines of code, so I will stick to it.

Maybe they should separate their DEV applications and PROD applications and allow PROD applications after some kind of control, or create another environment, paying only customers?

We in 2014, $ 20 / month servers can handle non-optimized websites (60 non-cached db requests on the main page) with 1 million visits / month, this should not be so difficult on Parse!

Answer 9

This is normal for prototyping applications, especially if the iOS / Android developer does not know how to create the database / API itself.

This is not at all normal when it comes to developing an application with logic that requires more complex queries:

 SELECT * FROM 'db' WHERE 'column' = 'value' LIMIT 100; 

Related queries and internal joins do not exist in Parse. And good luck to update / delete 320,000 entries if you need (with the number I'm working with now).

The only thing that is really useful is the processing of Users through the SDK. If I could find good documents or even a tutorial on how to process / create users through iOS / Android applications using Django and DRF / Tastypie, I instantly convert everything that is being developed in our company to use this.