Application node operating system memory (BASIC Plan) Why Is always 99%? + upstream prematurely closed connection while reading response header from upstream
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.
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.