4 ms·
Read "on dial-up" as "slow". The argument depends only on there being a certain distribution of client speeds. It's not about dial-up in particular.
by bdr 16y ago
Read "on dial-up" as "slow". The argument depends only on there being a certain distribution of client speeds. It's not about dial-up in particular.
- zedshaw 16y agoAnd, if there's a distribution of speeds then you can measure the distribution and see what works best. Again, my challenge still stands: Measure it or STFU.
- rortian 16y agoIf only you practiced what you preached. Imagine the amount of self-righteous bile that your servers wouldn't serve.
- zedshaw 16y agoI am practicing what I preach, you stupid 20%-er troll. That's why the whole blog post is full of measurements, testing hypotheses, and the assumption that I might be wrong. Because unlike you, I actually go do shit rather than spout off in a comment thread.
- rortian 16y agoYou may think you are. Far out. Why you think you can violate basic social norms, while others apparently support it, is beyond me.
- zedshaw 16y agoBasic social norms also involve not saying ruthless comments you wouldn't say to my face.
- rortian 16y agoPlease, you are being ridiculous. I would tell you that you mostly produce self-righteous bile to your face or anywhere else. Do you say data or 'STFU' to people's face? You're arrogant and insecure. You lash out at others who question you. It's pretty sad. People make assertions all the time, as you do, that are difficult if not impossible to verify. Sometimes the data is too hard to produce. You've noted yourself that real-world server data would be hard to produce. You might say admit that and be more humble about the fact that you've analyzed a micro-benchmark.
- blasdel 16y agoHow about you get measurements of ATR from real-world deployments instead of the wild conjectures you've laid in this thread? Your challenge applies even moreso to yourself: Measure it or GTFO.
- zedshaw 16y agoOh, you mean do what I'm already doing? Measuring and developing ideas then testing them? It helps if you're going to comment that you actually read the words I use, not the ones you have in your head that make you sound like you're super smart.
- blasdel 16y agoYes, you measured the ideal ATR inflection point for poll vs. epoll in your synthetic microbenchmark. But you guessed wildly about what ATRs people see in the real world: http://news.ycombinator.com/item?id=1572292 http://news.ycombinator.com/item?id=1572292 http://news.ycombinator.com/item?id=1572418 http://news.ycombinator.com/item?id=1572418
- zedshaw 16y agoYeah, 'cause there's no way I'll be able to test a real web server that I actually wrote based on this small test. This is a small test to test one specific thing, doing more would confound the test. Confounding. Look it up. Incidentally, this is the same test everyone else uses, so if you thought it was bullshit why did you support it when people testing epoll with it were using it? Oh, because they used it to confirm your bias rather than disagree with it.
- adamtj 16y agoI think he was suggesting that you find the ATR on real-world production webservers, which has nothing to do with your test and would not confound it. Maybe in practice nobody sees an ATR > 30%, in which case your test, if correct, is irrelevant. What sort of loads produce an ATR > 60%? How common are they? One problem with getting such numbers is that real world, the load is given, not the ATR, and the ATR for a given load may depend on implementation choices. Total connections is a function of server latency, and on a loaded system, latency can be a function of polling method. So switching methods may change your ATR. On the other hand maybe ATR for a given load doesn't change significantly depending on implementation. Your test found what is best for a given ATR, but not necessarily for a given load, or how ATR depends on load for a given implementation. Depending on the results, you may want to add some hysteresis to superpoll.
- frio 16y agoYou've already got a benchmarking system configured; why not benchmark using a congested (or at least, emulated) pipe? It doesn't necessarily depend on dial-up, either. Imagine the number of people who leave bittorrent open in the background, stream porn, or whatever else that leaves their individual HTTP connections slow. Hell, latency alone (it takes at least a second for my connection to reach the east coast of the USA) would have an effect, and you can't underestimate the increasing number of mobile devices on slow(-ish, depending on congestion) 3G networks. I'd provide statistics from my server (I serve an NZ gaming community), but I suspect my numbers would be disproportionate compared to the average workload. Here in NZ, we have far more people on crappy pipes (our DSL network is, famously, a gigantic pile of shit - although that has improved over the past couple of years and continues to), and far less people on smartphones (iPhones cost ~$800USD here). Still, I believe the commenter has a point which you shouldn't ignore, or at least shouldn't pass off so easily :). I'd love to do some testing myself, but unfortunately between working a day-job, and spending my evenings trying to get a startup off the ground, I've got no time spare.