New answers tagged scalability
Let's take the pragmatic approach. All these limits are things that were hardcoded and designed in the past century when hardware was slow and expensive. We're in 2016 now, an average wall-mart toaster can process more requests than the default values. The default settings are actually dangerous. Having hundreds of users on a website is nothing impressive....
ulimits -a will tell you how many open files your system allows a process to use. Also, net.ipv4.ip_local_port_range sets the total range of sockets to enable per IP. So, your worker_connections cannot be more than any of those, or your client connections will queue until net.core.netdev_max_backlog - the total size of the TCP queue. Keep in mind that if ...
Setting lower limits may be useful when you may be resource-constrained. Some connections, for example, keep-alive connections (not only with the clients, but with the upstream servers, too), are effectively wasting your resources (even if nginx is very efficient, which it is), and aren't required for the correct operation of a general-purpose server, ...
The appropriate sizing can be discovered through testing, as it is variable based on the type of traffic Nginx is handling. Theoretically, nginx can handle: max clients = worker_processes * worker_connections (* =multiply) and worker_processes = number of processors To find out processors, use: grep processor /proc/cpuinfo | wc -l
In short: yes! But that depends a bit in the syslog daemon you're running. Syslog-ng allows that with the program() destination. Rsyslog offers actions.
Syn flood is kind of attack that is near to impossible to protect on single host. Check SynCookies cat /proc/sys/net/ipv4/tcp_syncookies and enable (set to 1) it if disabled. It help legit users keep working. Also You can try set lover /proc/sys/net/ipv4/tcp_synack_retries http://stackoverflow.com/a/26674591/205355 About IP Synflood usually use ...
Top 50 recent answers are included