4 ms·

Yeah you usually need to warm it up if you're about to expect a lot of traffic because it can't really deal with that. That really shouldn't be an issue for a

by blaisio 10y ago

Yeah you usually need to warm it up if you're about to expect a lot of traffic because it can't really deal with that. That really shouldn't be an issue for a site like this though, because you can just host it on a CDN...

wyager 10y ago
Top of HN traffic peaks at maybe 50-100 visitors per second. Unless you're serving a bunch of data, it really shouldn't be an issue. One problem I've run into is (I suspect) running out of sockets because they weren't getting recycled fast enough. This went away when I switched to Snap or Happstack. I used to have to "fix" this by killing and restarting my server every five minutes.
- morganvachon 10y ago
  > Top of HN traffic peaks at maybe 50-100 visitors per second. That's true, but HN posts tend to go viral on other tech news sites. It's likely the majority of the traffic spikes are not originating on this site's link. I could be wrong though.
  - wyager 10y ago
    The worst I've ever had was Reddit/HN/Hackaday. I wish I had taken pictures of the Google Analytics report; there was a huge spike when it hit Hackaday, like thousands of loads in a few minutes (maybe a bunch of RSS readers?), leveling off to a more reasonable amount and then falling off gradually as it was displaced from the top of the page. I think I usually get most of my immediate traffic from HN. Twitter is probably the most benign; it usually seems to cause a very slow burn, with little flare-ups over days or weeks.
- mitchty 10y ago
  Do you see a lot of connections in TIME_WAIT? If so I'd just bump up the ephemeral port range via: /proc/sys/net/ipv4/ip_local_port_range (or sysctl -w) But if you're not getting recycling of TIME_WAIT, you can start to change the reuse/recycle attributes (caveat emptor) with: net.ipv4.tcp_tw_reuse or net.ipv4.tcp_tw_recycle I know I have been benchmarking a servant app by throwing 2048 concurrent connections at it and just bumping up the ephemeral range has been enough for my needs. I tend to run out of socket FD's or just FD issues a lot quicker than ports. Just a thought, but 50-100requests/second doesn't sound like too big of a deal. I did a quick bench of what i have setup and I get this: # wrk --latency -c 128 -t6 http://10.0.2.15:8080/foo/bar/ Running 10s test @ http://10.0.2.15:8080/foo/bar/ 6 threads and 128 connections Thread Stats Avg Stdev Max +/- Stdev Latency 3.46ms 5.25ms 137.42ms 90.23% Req/Sec 9.84k 2.13k 19.67k 69.50% Latency Distribution 50% 1.65ms 75% 4.40ms 90% 8.59ms 99% 22.17ms 589624 requests in 10.07s, 476.28MB read Requests/sec: 58560.86 Transfer/sec: 47.30MB Note, this is a static end point so take all these figures with blocks of salt. But by tuning what I said I can have wrk do 2048 concurrent connections reasonably with just a fair increase in overall latency. YMMV
  - pushrax 10y ago
    tcp_tw_recycle is not what you want. It is only applicable to outgoing connections (i.e. not people connecting to your server), and even in that case provides little benefit over tcp_tw_reuse. I like pointing people here for the explanation: https://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html https://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-l...
    - mitchty 10y ago
      True enough, but its hard to diagnose what people are having problems with with such vague wording. Some apps might have to open connections to a backend, or not, etc... But you're quite right on recycle for outgoing. To be honest I tend to shy away from adjusting either unless I really need to.
- Thaxll 10y ago
  If you don't initiate the connection ( no reverse proxy ) you don't have to recycle sockets, only the nofile / iptables settings matter.
tedmiston 10y ago
How exactly does one go about warming Elastic Beanstalk? I thought part of the value add was Beanstalk making it so you don't have to think about these things for bursts.
- boyter 10y ago
  Contact Amazon. I go through this every time I switch work servers to a new elb or spin up a new service. They are pretty responsive when it comes to this. Just let them know you are expecting X amount of traffic. The new load balances may be a bit better in this regard Hough I haven't tried them yet.

by blaisio 10y ago

wyager 10y ago

Top of HN traffic peaks at maybe 50-100 visitors per second. Unless you're serving a bunch of data, it really shouldn't be an issue. One problem I've run into is (I suspect) running out of sockets because they weren't getting recycled fast enough. This went away when I switched to Snap or Happstack. I used to have to "fix" this by killing and restarting my server every five minutes.

morganvachon 10y ago
> Top of HN traffic peaks at maybe 50-100 visitors per second. That's true, but HN posts tend to go viral on other tech news sites. It's likely the majority of the traffic spikes are not originating on this site's link. I could be wrong though.
- wyager 10y ago
  The worst I've ever had was Reddit/HN/Hackaday. I wish I had taken pictures of the Google Analytics report; there was a huge spike when it hit Hackaday, like thousands of loads in a few minutes (maybe a bunch of RSS readers?), leveling off to a more reasonable amount and then falling off gradually as it was displaced from the top of the page. I think I usually get most of my immediate traffic from HN. Twitter is probably the most benign; it usually seems to cause a very slow burn, with little flare-ups over days or weeks.
mitchty 10y ago
Do you see a lot of connections in TIME_WAIT? If so I'd just bump up the ephemeral port range via: /proc/sys/net/ipv4/ip_local_port_range (or sysctl -w) But if you're not getting recycling of TIME_WAIT, you can start to change the reuse/recycle attributes (caveat emptor) with: net.ipv4.tcp_tw_reuse or net.ipv4.tcp_tw_recycle I know I have been benchmarking a servant app by throwing 2048 concurrent connections at it and just bumping up the ephemeral range has been enough for my needs. I tend to run out of socket FD's or just FD issues a lot quicker than ports. Just a thought, but 50-100requests/second doesn't sound like too big of a deal. I did a quick bench of what i have setup and I get this: # wrk --latency -c 128 -t6 http://10.0.2.15:8080/foo/bar/ Running 10s test @ http://10.0.2.15:8080/foo/bar/ 6 threads and 128 connections Thread Stats Avg Stdev Max +/- Stdev Latency 3.46ms 5.25ms 137.42ms 90.23% Req/Sec 9.84k 2.13k 19.67k 69.50% Latency Distribution 50% 1.65ms 75% 4.40ms 90% 8.59ms 99% 22.17ms 589624 requests in 10.07s, 476.28MB read Requests/sec: 58560.86 Transfer/sec: 47.30MB Note, this is a static end point so take all these figures with blocks of salt. But by tuning what I said I can have wrk do 2048 concurrent connections reasonably with just a fair increase in overall latency. YMMV
- pushrax 10y ago
  tcp_tw_recycle is not what you want. It is only applicable to outgoing connections (i.e. not people connecting to your server), and even in that case provides little benefit over tcp_tw_reuse. I like pointing people here for the explanation: https://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-linux.html https://vincent.bernat.im/en/blog/2014-tcp-time-wait-state-l...
  - mitchty 10y ago
    True enough, but its hard to diagnose what people are having problems with with such vague wording. Some apps might have to open connections to a backend, or not, etc... But you're quite right on recycle for outgoing. To be honest I tend to shy away from adjusting either unless I really need to.
Thaxll 10y ago
If you don't initiate the connection ( no reverse proxy ) you don't have to recycle sockets, only the nofile / iptables settings matter.

tedmiston 10y ago

How exactly does one go about warming Elastic Beanstalk? I thought part of the value add was Beanstalk making it so you don't have to think about these things for bursts.

boyter 10y ago
Contact Amazon. I go through this every time I switch work servers to a new elb or spin up a new service. They are pretty responsive when it comes to this. Just let them know you are expecting X amount of traffic. The new load balances may be a bit better in this regard Hough I haven't tried them yet.