[
https://issues.apache.org/jira/browse/TS-2458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2458:
------------------------------
Description:
we have origin connections limits, the parameter
proxy.config.http.server_max_connections is for whole connections, and the
parameter proxy.config.http.origin_max_connections is for the specified
connections per original server ip / host.
the http transaction is rescheduled / retried after 100ms when it's original
connections exceed these limits.
these transactions will be rescheduled repeatly when the original server is
very slow. the system worsens when these retries happen because the http
transactions accumulate more and more.
I think we should cut off these transactions immediately other than retry after
100ms.
the rescheduling codes in proxy/http/HttpSM.cc as:
{code}
4581 if (sum >= t_state.http_config_param->server_max_connections) {
4582 ink_assert(pending_action == NULL);
4583 pending_action = eventProcessor.schedule_in(this,
HRTIME_MSECONDS(100));
4584 httpSessionManager.purge_keepalives();
4585 return;
4586 }
4587 }
4588 // Check to see if we have reached the max number of connections on this
4589 // host.
4590 if (t_state.txn_conf->origin_max_connections > 0) {
4591 ConnectionCount *connections = ConnectionCount::getInstance();
4592
4593 char addrbuf[INET6_ADDRSTRLEN];
4594 if (connections->getCount((t_state.current.server->addr)) >=
t_state.txn_conf->origin_max_connections) {
4595 DebugSM("http", "[%" PRId64 "] over the number of connection for
this host: %s", sm_id,
4596 ats_ip_ntop(&t_state.current.server->addr.sa, addrbuf,
sizeof(addrbuf)));
4597 ink_assert(pending_action == NULL);
4598 pending_action = eventProcessor.schedule_in(this,
HRTIME_MSECONDS(100));
4599 return;
4600 }
4601 }
{code}
was:
we have origin connections limits, the parameter
proxy.config.http.server_max_connections is for whole connections, and the
parameter proxy.config.http.origin_max_connections is for the specified
connections per original server ip / host.
the http transaction is rescheduled / retried after 100ms when it's original
connections exceed these limits.
these transactions will be rescheduled repeatly when the original server is
very slow. the system worsens when these retries happen because the http
transactions accumulate more and more.
I think we should cut off these transactions immediately other than retry after
100ms.
the rescheduling codes in proxy/http/HttpSM.cc as:
4581 if (sum >= t_state.http_config_param->server_max_connections) {
4582 ink_assert(pending_action == NULL);
4583 pending_action = eventProcessor.schedule_in(this,
HRTIME_MSECONDS(100));
4584 httpSessionManager.purge_keepalives();
4585 return;
4586 }
4587 }
4588 // Check to see if we have reached the max number of connections on this
4589 // host.
4590 if (t_state.txn_conf->origin_max_connections > 0) {
4591 ConnectionCount *connections = ConnectionCount::getInstance();
4592
4593 char addrbuf[INET6_ADDRSTRLEN];
4594 if (connections->getCount((t_state.current.server->addr)) >=
t_state.txn_conf->origin_max_connections) {
4595 DebugSM("http", "[%" PRId64 "] over the number of connection for
this host: %s", sm_id,
4596 ats_ip_ntop(&t_state.current.server->addr.sa, addrbuf,
sizeof(addrbuf)));
4597 ink_assert(pending_action == NULL);
4598 pending_action = eventProcessor.schedule_in(this,
HRTIME_MSECONDS(100));
4599 return;
4600 }
4601 }
> the http transaction should not be rescheduled when the original connections
> overflow
> -------------------------------------------------------------------------------------
>
> Key: TS-2458
> URL: https://issues.apache.org/jira/browse/TS-2458
> Project: Traffic Server
> Issue Type: Improvement
> Components: HTTP
> Reporter: Yu Qing
>
> we have origin connections limits, the parameter
> proxy.config.http.server_max_connections is for whole connections, and the
> parameter proxy.config.http.origin_max_connections is for the specified
> connections per original server ip / host.
> the http transaction is rescheduled / retried after 100ms when it's original
> connections exceed these limits.
> these transactions will be rescheduled repeatly when the original server is
> very slow. the system worsens when these retries happen because the http
> transactions accumulate more and more.
> I think we should cut off these transactions immediately other than retry
> after 100ms.
> the rescheduling codes in proxy/http/HttpSM.cc as:
> {code}
> 4581 if (sum >= t_state.http_config_param->server_max_connections) {
> 4582 ink_assert(pending_action == NULL);
> 4583 pending_action = eventProcessor.schedule_in(this,
> HRTIME_MSECONDS(100));
> 4584 httpSessionManager.purge_keepalives();
> 4585 return;
> 4586 }
> 4587 }
> 4588 // Check to see if we have reached the max number of connections on
> this
> 4589 // host.
> 4590 if (t_state.txn_conf->origin_max_connections > 0) {
> 4591 ConnectionCount *connections = ConnectionCount::getInstance();
> 4592
> 4593 char addrbuf[INET6_ADDRSTRLEN];
> 4594 if (connections->getCount((t_state.current.server->addr)) >=
> t_state.txn_conf->origin_max_connections) {
> 4595 DebugSM("http", "[%" PRId64 "] over the number of connection for
> this host: %s", sm_id,
> 4596 ats_ip_ntop(&t_state.current.server->addr.sa, addrbuf,
> sizeof(addrbuf)));
> 4597 ink_assert(pending_action == NULL);
> 4598 pending_action = eventProcessor.schedule_in(this,
> HRTIME_MSECONDS(100));
> 4599 return;
> 4600 }
> 4601 }
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
