VERY Slow Performance on host - Thinking back to PHP

Yeah I think it’s something to do with CloudFlare. I have had MAJOR ddos attacks in the past. 1 mill requests a day, 50 million total.

I have serious… enemies out there, so I need cloudflare.

I’ve just started porting to Wordpress… Sigh.

I wouldn’t use Apache with Meteor (or any web app to be honest). Go for NGinx before you start thinking about migration which is a big undertaking. I honestly don’t think it’s Node / Meteor the culprit … and not sure how cloudflare with Meteor is worse than cloudflare with PHP. We are online with thousands of simultaneous users and no issues.

Get sample nginx conf from here: https://github.com/ramezrafla/meteor-deployment

5 Likes

Why are you using Apache? Is that a CloudFlare requirement?

And have you considered using Sikka or Meteor’s connection-level DDPRatelimiter for per-ip/user DOS?

1 Like

Maybe upload to MDG Galaxy hosting even temporarily to make sure its not a devops/configuration issue. It only takes a few steps to do it. If it runs slow there you will know it’s a problem with your Meteor project

1 Like

SkyRooms is very cool! The app popped up very quickly here. Are you using WebRTC for your in-app video?

Actually, I spent today switching it to WordPress. Which is why it’s
running so fast.

I was using Meteor plus webtrc but, now it’s WordPress and webtrc.

I’ll keep the code I have for Meteor, but it is one of the most difficult
learning curves I’ve ever seen. So much to learn. Production environemt
self hosting is insane. I refuse to host my software on galaxy, three times
more expensive, and I have to maintain a mongo db anyway.

Can’t even serve images to three clients without breaking. Sad I wasted the
time developing so much… Yikes.

1 Like

I had plenty of issues developing and hosting my Meteor app too. I did emphasize performance a lot. Shame your app is down and I cannot take a look.

I don’t think anyone was asking you to run your app on Galaxy. They were suggesting doing that as a surefire way to identify whether it’s something wrong with your codebase. There would be absolutely no reason why a well-written Meteor app would be slow on Galaxy. But hosting doesn’t have to be expensive. You can host a Meteor app for as little as $5/mo on Digital Ocean. And there are many tools (such as MUPX) that make it a breeze to deploy with a single command from the terminal.

Maybe you were on a time-crunch and had to make some quick decisions and went with what you were comfortable with.

Why not host it non-officially, post the IP for it, and maybe someone here will look at it?

1 Like

Are you accessing WebRTC via a library or directly? I’m adding WebRTC and I’m curious about how other people are accessing it.

If you don’t need reactivity and feel more comfortable with PHP or Wordpress, by all means go for it, nothing wrong with that. If your website can actually work fine on Wordpress without losing features, then I’d say it’s better to keep it on Wordpress than as a Meteor app - Meteor is an overkill in such a case, it’s meant for different purposes and it was probably a wrong platform choice from the very start.

But just to make sure, ask yourself following questions. Did I do everything I can to make it work fast? Did I use publications only for queries where I really need reactivity and use methods for the rest? Did I optimize the queries in the database? Did I take care of indexes? Did I split the application into microservices? That’s for the start.

I’m glad it’s working fine for you now, good luck with the business. :slight_smile:

1 Like

I feel that this entire post is irresponsibly written and should be deleted. It’s one thing to be a beginner or new to a product and understand you may not know what you are doing. It’s another thing to take an aggressive view and dismiss an entire work. You mention you have a lot of enemies, I would reflect on why that may be.

3 Likes

I’m frustrated that I’ve invested six months of work on the promise of Meteor. It works great on dev.

When you go to port to your production environment, it’s an ABSOLUTE NIGHTMARE. And there’s no getting around that. True of false, Meteor is very complicated to setup on a production system. True.

I had thought, no problem, I’ll host on Galaxy, sure their prices are higher, but the value they deliver is nice. But no, I still have to run my own mongo server. So it’s still super complicated to setup.

In short, Meteor makes a lot of promises, and it’s super hard to find answers to why things don’t work well. I hope that any one considering moving in to Meteor, or NodeJS for that matter, thinks twice. I suppose if you’re brought up on that technology, versus .net, php, or similiar, it’s not so bad.

I have a lot of competitors, from a lot of industries. DDOS is very common, we deal with about 30k hits a day in regular traffic.

To conclude this post, I indeed ported my code back to PHP. It actually went super smoothly for the UI, just need to rebuild the logic and database connection.

I really enjoyed Meteor, but there are still MAJOR problems it has. Even Kaidira (spelling?) is shutting it’s service down because Meteor users aren’t paying for it? I wish Meteor the best, but forcing deployments to use CDN’s or face 20s response times is… unacceptable. I had to triage about 20 problems just to get it running SLOWLY. Gross.

Cheers,

1 Like

The aggressiveness and tone are disturbing and hard to understand.

That said, I come from PHP land. LAMP is the easiest means to deployment I’ve found. Name your file .php, write <? echo "Hello World"; ?> and it’s deployed.

I turned to Node when I wanted near real time performance for my platform. PHP’s brilliance (don’t laugh) is that every script begins stateless and ends stateless – its little own container. But when you need persistent state (and $_SESSION isn’t cutting it), web sockets, etc, you need to move on.

As others mentioned, if you don’t need the advantages that Meteor/Node bring, don’t use it. Using Meteor to write a PHP style app will bring weeks or months of needless pain. The dev ops with Meteor (and Node generally) is 1000x more complicated than the largely fire and forget LAMP.

4 Likes

Loads great for me and it’s getting a 91/100 on pingdom.

I did my first test deploy today with Galaxy and mLab. Once you’re signed up with both you just copy and paste this:

{
  "galaxy.meteor.com": { 
     "env": { 
       "MONGO_URL": "mongodb://<dbuser>:<dbpassword>@<dbserver>:<dbport>/<dbname>" 
     } 
   }
}

It’s completely idiot proof. Just read the official deployment guide.

2 Likes

Yeah it’s moved to Wordpress now. :confused:

It’s not idiot proof, there are many things to consider such as ports, DNS
whitelisting, and many more security / traffic issues.

Even configuring this setting on Apache is stressful. Of course, much of
that could be mitigated by using NginX and so forth.

My point is that it was complicated.

At any rate, I’m all moved out now, cheers.

All right, then. @thea can we close this topic now? Seems the point has been made.

I’m not sure what you’re doing there but it seems to be the wrong approach. Complicated?

Here’s what I do to set things up on a Debian Minimal Installation:

a) Grab the build tools with apt-get
b) Build the proper version of Node and MongoDB, install them
c) Install nginx
d) Set the right environment variables so Meteor can find the MongoDB installation (it’s in the docs)
e) Configure nginx to act as a proxy (easily found on SO)
f) Use forever or similar to keep Meteor up.

This is on a dinky VM I’m not paying very much for. And yet I’m seeing this:

So your complaint would be 200ms response times for for a 76kb image? Is that correct?