what is the threshold, if any, above which it's re...
# box-products
w
what is the threshold, if any, above which it's recommended to have a dedicated web server in front of a commandbox instance? we're considering deployments of commandbox/lucee in a production environment but these apps only face inward (intranet). there's little expectation of a high volume of requests, but would prefer to proactively design a solution that won't have to be subsequently be changed a month down the line
z
i'd say it basically comes down where you might want to do some webserver kung fu (if you need to)
s
FWIW, we use a teeny tiny DigitalOcean droplet - 4 gigs of RAM - to front every single web site we have. It barely breaks a sweat. so 'dedicated web server' ain't what it used to be
w
fair. any rewriting we need is handled by undertow well, and the apps themselves don't serve static assets (they're rest apis) so i'm thinking a dedicated web server serves little purpose here
s
my only consideration when doing this was how many sites would be on the production server. since i do have multiple commandbox servers running on the server i use nginx specifically for a reverse proxy. With this being the case, the only adjustment i needed to make is to ensure the production flag was in the
server.json
since the internally routed url will always be 127.0.0.1 so commandbox sees it as a local site
w
roger, thanks
b
Scott's concern is lessened now that CommandBox natively supports ModCFML so you can have as many sites as you like in a single Java instance
@websolete The Java-based Undertow web server is both powerful and quite fast. All CF traffic is going to hit Undertow anyway, so putting a proxy in front of it does nothing but add network hops. (And, CommandBox has a better out-of-the-box lockdown for security so you'll actually have to do more work to configure Apache/Nginx to be as secure) So this really comes down to static files IMO. I've done some head-to-head testing of • IIS • Apache • CommandBox serving up static files under extreme load and the throughput of each web server (we're talking like 5,000 requests per second) was basically identical. The only server that showed an edge was IIS, which had slightly lower CPU usage, probably due to its OS-level stack integrations on Windows. So, if Apache is on the box serving static files, it's not going to do it any faster than CB can serve them. So now it basically comes down to threads. You can configure CommandBox/Undertow to process as many concurrent requests as you want (and an image getting downloaded is a "request") but if you have users downloading, like, 1GB zip file or something, that could be taking away threads from CF requests. But to be honest, if you have enough large static assets to worry about this, you should probably be using a CDN like S3 in the first place which means you can just stick with CommandBox and be done with it 🙂
👍 1
👍🏾 1
s
I feel like this should be a blog post, I wasn’t aware how comparable the 2 were
w
thanks brad
b
Everything should be a blog post (or a screen cast). If only I had more time 😆
🥲 2
🤣 1
w
Don’t forget ease of use and logging standards. We always have haproxy and/or nginx in front of undertow. That was mainly because we had several tools to aid in configuration management, logging, logging analysis and troubleshooting, and our sysadmins were way more comfortable in analyzing traffic from nginx and haproxy. I am sure undertow is very performant. But talking standards, ease of use and documentation I think those reverse proxy’s are way more flexible, so for web facing sites I would always use nginx or haproxy. But it is very dependant on your setup and who should troubleshoot your server at 3 am.
✔️ 1