Application node operating system memory (BASIC Plan) Why Is always 99%? + upstream prematurely closed connection while reading response header from upstream

6
Hi All.  I have a basic (MENDIX CLOUD  1/1 Gigs) plan. I don't have enough clients to justify the best plan, the gap is just huge on performance, but I cannot justify it. The thing is my app is complex. And I have been trying to find ways to be on the safe side of the Application node operating system memory and every other metric. But no matter what I do, queues, cache, custom cache, removing queues, simplifications. I’m always on the 95-99% of the available system memory. And I’m even getting a crash often when showing to customers: "upstream prematurely closed connection while reading response header from upstream", nothing on the log. The app just restarts with an ugly message.  I’m running out of options really. I cannot show it like that or get more clients like that. What is been considered on the APPLICATION NODE SYSTEM MEMORY? is the number of pages? microflows? nanos? How can I lower it.  I only have 1 gig and I’m always at 1005-1010 MB. How can I slim that and try to make my app fit these limits?  Is it tables? Is the relationships between them (I have 30-40 tables)… What is it? Also I could not find a way to debug it in eclipse (which AppId to hook to to check objects?). My app works great on dev.  My problem is prod.
asked
1 answers
2

I’m with Carlos on this. The Basic plan is good, but why not another tier to cover app growth? I’m concerned because the success of the app I developed is becoming a problem, since the Standard one app plan is too much, and the Basic is quickly becoming too little.

App success should never become a problem for the Mendix platform, because it might push the user out. 

answered