kowsik
|
14 years ago
|
on: Speed Limit of PaaS - 64K TCP Ports
Talking about port exhaustion is, I realize, a little confusing because there are the web requests coming in and the web-tier is making outbound requests to other services. Adding an image to the blog to hopefully clarify things.
kowsik
|
14 years ago
|
on: Speed Limit of PaaS - 64K TCP Ports
I've added a picture to clarify which ports I'm talking about. Hopefully this clarifies things a bit.
kowsik
|
14 years ago
|
on: Speed Limit of PaaS - 64K TCP Ports
My point is the thing you are connecting in the back-end has to scale at the same level as node - if not better. I'm sure making independent non-pipelined requests to CouchDB will help, but if CouchDB views are slow or it can't handle the concurrency, then the web requests to node.js will start slowing down resulting in a pipeline stall.
kowsik
|
14 years ago
|
on: Speed Limit of PaaS - 64K TCP Ports
We had a node.js app where each inbound request would go through a set of HTTP connections to the back-end couchDB. When the concurrency reached around 1,000 then there were 1,000 requests made through 10 couchDB pipelined connections. The result was the web requests were starting to get slower and slower. Think of a 6-lane road merging into a 1-lane road. Congestion.
kowsik
|
14 years ago
|
on: Speed Limit of PaaS - 64K TCP Ports
Okay, we are talking past each other. If you have a server on an EC2 instance, with enough RAM you can support more than 64K inbound connections for exactly the reasons you mention. Try generating more than 64K connections outbound and this is exactly what I'm talking about.
kowsik
|
14 years ago
|
on: Speed Limit of PaaS - 64K TCP Ports
My observation/assumption is that your app is running in a multi-tenant PaaS environment, where mysteriously you start getting bind errors because the ephemeral port space is shared with other tenants.
kowsik
|
14 years ago
|
on: Speed Limit of PaaS - 64K TCP Ports
Read the blog again. This is bollocks if you are running your own server where you can be multi-homed, add loopback aliases etc and crank up the memory to support 100,000+ sockets. I'm talking PaaS where your app is an multi-tenant environment with no root access.
kowsik
|
14 years ago
|
on: Heroku for Java
kowsik
|
14 years ago
|
on: Load testing? Try to take down your app for $1 with blitz.io
It's going to cost you no more than $79/day * 2 for two days of load testing if you sign up directly to
http://blitz.io. That's peanuts compared to anything else on the market. And with EC2 lowering inbound bandwidth costs, this only gets better!
kowsik
|
14 years ago
|
on: Load testing? Try to take down your app for $1 with blitz.io
One more thing. An m1.small instance on EC2 (on-demand pricing) will cost you around $60/month + bandwidth costs. So you need a multi-tenant load testing solution to amortize the costs and drive hourly price down, which is what we are doing.
kowsik
|
14 years ago
|
on: Load testing? Try to take down your app for $1 with blitz.io
Load testing is not a month-long event. Nobody does it 24/7 for 4 weeks straight. It's usually bursty for an hour or so of a day (aligned with a git push or continuous deployment), which bodes well for $1/hour
http://blitz.io Heroku pricing.
kowsik
|
14 years ago
|
on: Load testing? Try to take down your app for $1 with blitz.io
kowsik
|
14 years ago
|
on: Load testing? Try to take down your app for $1 with blitz.io
Yes, it's because they pro-rate add-ons by the second. If you sign up with Heroku, you immediately get 500 concurrencies as part of the free plan. Signing up directly with blitz.io, OTOH, gives you blogging and referral credits - see
http://blitz.io/invite
kowsik
|
14 years ago
|
on: Head JS Loads JavaScript Files Like Images Without Blocking the Page
I had some serious issues with head.js with
http://blitz.io in that the load order was not deterministic causing all sorts of weirdness. For example jQuery will end up loading after the code that requires jQuery resulting in undefined stuff and form posts not binding properly. While I truly liked the idea, it wasn't for us.
kowsik
|
14 years ago
|
on: blitz.io node.js client
this is pretty awesome!
kowsik
|
14 years ago
|
on: Interactive Mapreduce | CouchDB
I wrote this originally for an internal brown bag as a gentle introduction for SQL-oriented folks. Glad it helped!
kowsik
|
15 years ago
|
on: Why NoSQL is bad for startups
Check the date on the article. :)
kowsik
|
15 years ago
|
on: Why NoSQL is bad for startups
thanks for the delayed april 1st HN reference. Had fun writing this one! It's CouchDB's fault. :)
kowsik
|
15 years ago
|
on: On HTTP Load Testing
problem with most load testing tools is the fact that you have to script through them. It's a PITA. Especially with PaaS and Heroku/EngineYard/Other-Vendors/-style deployments, time-to-deploy often obsoletes the time-to-script-test-cases. Need something different, agile and continuous.
kowsik
|
15 years ago
|
on: Blitz.io: Taking the sting out of load and performance testing
Thanks @pbreit and welcome to blitz.io. Check out the ruby gem (gem install blitz) for continuous integration and the chrome extension for in-browser load testing. And here's a quick blog on integrating blitz.io with @tropo so you can automatically schedule load tests and send an SMS:
http://bit.ly/i0etWX