Low Latency Web

Low Latency Web

The following kernel parameters were changed to increase the number of ephemeral ports, reduce TIME_WAIT, increase the allowed listen backlog:
  echo "2048 64512" > /proc/sys/net/ipv4/ip_local_port_range
  echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle
  echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse
  echo "10" > /proc/sys/net/ipv4/tcp_fin_timeout

  echo "65536" > /proc/sys/net/core/somaxconn
  echo "65536" > /proc/sys/net/ipv4/tcp_max_syn_backlog




The load generator is wrk, a scalable HTTP benchmarking tool.




wrk -t 10 -c N -r 10m http://localhost:8080/index.html where N = number of connections. 






Apache Benchmarking tool










































Comments








Post a Comment













Popular posts from this blog









Sites, Newsletters, and Blogs





















BLOGS  Java.net Weblogs  Martin Fowler's blog  Paul Graham  Ruminations of a Programmer  Form Follows Function   Newsletters  Core Java Tech Tips  Enterprise Java Tech Tips  JavaSpecialists.EU  TheServerSide.com   Sites  Java.net Today  Hot Java Sites  CSS Zen Garden   Evernote  Hacker News  Pragmatic Programmer  








Read more










Oracle JDBC ReadTimeout QueryTimeout





















If a query exceeds the oracle.jdbc.ReadTimeout without receiving any data, an exception is thrown and the connection is terminated by the Oracle driver on the client. Unfortunately the session will still be queued on the database and continue to wait for locks, hold any current locks, and complete any DML/PL*SQL procedures that are pending on the server-side of the orphaned connection.   If an application, on a another connection, due to ReadTimeout exception, retries DML/PL*SQL  which requires locks, those queries will queue behind the initial DML/PL*SQL. This will increase the workload exacerbating the situation. On applications with retries, this can be observed by querying the v$session table  or gv$session on RAC and noting new sessions started periodically based on the ReadTimeout interval. The sessions may often have the same SQL_ID and/or SQL_HASH_VALUE.   If stmt.setQueryTimeout(Seconds) is issued and the statement exceeds the timeout, it will atte...








Read more










Locks held on Oracle for hours after sessions abnormally terminated by node failure





















If a session holds db locks and is abnormally terminated (no fin/ack), the locks will persist until the db session is closed, typically around 2 hours and 12 minutes with default network tcp_keepalive settings. Abnormally terminated does not include CTRL C or kill -9. The ojdbc6 driver apparently has a shutdown hook thread that closes the connections in graceful shutdowns. The OS apparently closes the connections when processes are killed. Abnormally terminated might include power failure, firewall failures, Out Of Memory, OS/kernel crash, network connection failure, JBoss or other server node failure, etc.     This was easily reproduced by creating a  process that connected to the db and updated a record but did not commit. While the first process was waiting, a second process with a contending update was started which blocked on the first update. The first clients network cable was then disconnected. The second clients transaction waited for approximately 2 hours until the databa...








Read more