in RTC, for Global Software development scenario, there is the concept of cached proxies.
as i understand, it is only a read only proxy which will help while loading a component in the remote location.[scm part]
All Commit and Deliver actions when the changes are transmitted to the central server, the changes are sent directly over WAN. So these actions do not benefit from the proxy. Is this understanding correct?
Or does the proxy help in improving the performance for deliver/commit actions from the remote location?
Cache proxy are mentioned in:
"Does Rational Team Concert support MultiSite? "
"Using content caching proxies for Jazz Source Control"
We realize that there will still be cases where a WAN connection will not meet the 200ms guidance. In this case, we’ve leveraged the Web architecture of RTC to allow caching proxies to be used.
Based on standard Web caching technology, IBM or Apache HTTP Server or Squid, a cache can be deployed in the location which has a poor connection to the central server.
This caching proxy will cache SCM contents that are fetched from the server, greatly improving access times for the RTC client, and reducing traffic on the network.
So in case of RTC, it is more targeted to quicken "Load" and "Accept" and operations, rather than "Commit" and "Deliver".
If multiple developers all load from a specific stream, a caching proxy will help reduce the network traffic.
We realize that there will still be cases where a WAN connection will not meet the 200ms guidance. In this case, we’ve leveraged the Web architecture of RTC to allow caching proxies to be used.
Based on standard Web caching technology, IBM or Apache HTTP Server or Squid, a cache can be deployed in the location which has a poor connection to the central server.
This caching proxy will cache SCM contents that are fetched from the server, greatly improving access times for the RTC client, and reducing traffic on the network.
So in case of RTC, it is more targeted to quicken "Load" and "Accept" and operations, rather than "Commit" and "Deliver".
If multiple developers all load from a specific stream, a caching proxy will help reduce the network traffic.
Related
I heard that to alleviate the web server of the burden of performing the SSL Termination, it is moved to load balancers and then HTTP connection is made from the LB to the web server. However, in order to ensure security, an accepted practice is to re encrypt the data on the LB and then transmit it to the web server. If we are eventually sending the encrypted data to the web servers, what is the purpose of having a LB terminate SSL in the first place ?
A load balancer will spread the load over multiple backend servers so that each backend server takes only a part of the load. This balancing of the load can be done in a variety of ways, also depending on the requirements of the web application:
If the application is fully stateless (like only serving static content) each TCP connection can be send to an arbitrary server. In this case no SSL inspection would be needed since the decision does not depend on the content of the traffic.
If the application is instead stateful the decision which backend to use might be done based on the session cookie, so that requests end up at the same server as the previous requests for the session. Since the session cookie is part of the encrypted content SSL inspection is needed. Note that in this case often a simpler approach can be used, like basing the decision on the clients source IP address and thus avoiding the costly SSL inspection.
Sometimes load balancers also do more than just balance the load. They might incorporate security features, like a Web Application Firewall, they might sanitize the traffic or similar. These features work on the content so SSL inspection is needed.
Will Cloudflare accelerate my websocket data transfer speed by default (without any additional configurations)?
What paid and free configurations can I use to improve my websocket connection? Will Argo help here?
What level of performance increase should I wait from these different configurations?
p.s. I know that CDN mostly concentrates about optimizing serving of static content but still I am curious will it help at least a bit with dynamic content?
CDNs accelerate static content that can be cached and distributed to servers with different geolocations. But Websockets are used to server dynamic content, so the limiting factor there is the power of the server and its geolocation.
So Cloudflare or any other CDN are not be able to accelerate websockets in the same way as they can do with static content, well yes Argo might help in certain cases. But the really limiting/problematic factor with WebSockets is your application/setup handling the requests.
There are however certain conditions under which Cloudflare can accelerate connection. Some ISP want to have extra money for better routing (Double Paid Traffic), and some data center owners refuse to pay those additional money.
So it might be that the none payed connection is slower then a routing using Cloudflare as a proxy, under the condition the Cloudflare pays for the better routing. But then its not the technical part of Cloudflare that accelerates the connection, but the contract. You might need to ask your hoster about that case.
Note that Cloudflare will reset the websocket connections now and then:
“Logs from tcpdump show that Cloudflare sends a TCP reset after 1-5 minutes, despite both client and server being in sync on packets sent in each direction” - https://community.cloudflare.com/t/websockets-disconnected-in-aws-tokyo/44680
“If you’re intending to use CF websockets, be prepared for random (and potentially massive) connection drops, and be sure you’re architected to handle these disconnects gracefully. Cloudflare rolling restarts have caused hundreds of thousands of websocket connections to be disconnected in a matter of minutes for us”; “when terminating a WebSocket connection due to releases CloudFlare now signals this action to both client and origin server by sending the 1001 status code” - https://news.ycombinator.com/item?id=11638081
“When Cloudflare releases new code to its global network, we may restart servers, which terminates WebSockets connections” - https://support.cloudflare.com/hc/en-us/articles/200169466-Using-Cloudflare-with-WebSockets#12345687
So to answer your question, Argo Smart Routing inside Cloudflare can, in theory, accelerate the websocket connections and make them more reliable. But we also know for a fact that it will lead to regular websocket disconnects.
Maybe use Cloudflare for backup connections, to improve the total resilience in the face of routing anomalies.
I came across the "source" load balancing algorithm in HAProxy, which ensures that a user will connect to the same server, by choosing server based on a hash of the source IP.
Why and when is it important for a user to connect to the same server? I cannot think of a reason, assuming that all candidate servers serve identical content.
Furthermore, if there was the need for a user to always connect to the same server, then wouldn't load balancing be completely irrelevant for this user?
It is important for a user to connect to the same server if we want to achieve session persistence.
For example, when talking about a HTTP session, there are information/variables (think about a shopping cart) specific to the session in question.
This dynamic information is not shared by the candidate servers in case they are not configured to do so and it is simpler to deal with it at the load-balancing level.
The preferred way to deal with this in HAProxy is by using cookies, but this only works in HTTP mode. HAProxy offers the source load balancing algorithm, in case cookies can't be used. This can be used in TCP mode or with HTTP clients that refuse cookies.
Load balancing will be irrelevant for the user in question right, until the cookie expires. But we generally need load balancing when dealing with many users so that they can be served by multiple servers with each user sticking with one of them.
My web app, an exploded WAR, is hosted by Apache (static content) and Tomcat (dynamic content) via mod_jk. Optionally, there's an ActiveMQ component of this system, but it's currently not being used.
As I understand, each HTTP request will hit Apache. If it's a dynamic content request, Apache will forward the request to Tomcat via mod_jk. To fulfill this request, Tomcat will start a new thread to do the work.
I'm running the app on a 6-core, 12 GB RAM machine.
Besides using the ActiveMQ component, how can I improve my system's performance? Also, please correct me if I'm misstating how Apache and Tomcat communicate.
while (unhappyWithSitePerformance) {
executeLoadTest();
identifyBiggestBottleneck(); // e.g. what breaks first
fixIdentifiedBottleneck();
}
There is no blank silver bullet to provide. You should make sure your load test simulates realistic user behaviour and define the number of (virtual) users you want your server to handle within given answering time. Then tune your server until your goal is met.
Common parameters to look for are
memory consumption
CPU consumption (e.g. certain algorithms)
I/O saturation - e.g. communication to the database, general HTTP traffic saturating the network adapter
Database or backend answering time - e.g. sometimes you'll have to tune the backend, not the webserver itself.
From what I understand, if you have multiple web servers, then you need some kind of load balancer that will split the traffic amongst your web servers.
Does this mean that the load balancer is the main connecting point on the network? ie. the load balancer has the IP address of the domain name?
If this is the case, it makes it really easy to add new hardware since you don't have to wait for any dns propogation right?
There are several solutions to this "problem".
You could round-robin at the DNS-level. I.e. have www.yourdomain.com point to several IP-addresses (well all your servers).
This doesn't give you any intelligence in the load balancing, but the load will be more or less randomly distributed, but you wouldn't be resilient to hardware failures as they would still require changes to DNS.
On the other hand you could use a proxy or a loadbalancing proxy that has a single IP but then distributes the traffic to several back-end boxes. This gives you a single point of failure (the proxy, you could of course have several proxies to defeat that problem) and would also give you the added bonus of being able to use some metric to divide the load more evenly and intelligently than with just round-robin dns.
This setup can also handle hardware failure in the back-end pretty seamlessly. The end user never sees the back-end, just the front-end.
There are other issues to think about as well, if your page uses sessions or other smart logic, you can run into synchronisation problems when your user (potentially) hits different servers on every access.
It does (in general). It depends on what server OS and software you are using, but in general, you'll hit the load balancer for each request, and the load balancer will then farm out the work according to the scheme you have in place (round robin, least busy, session controlled, application controlled, etc...)
andy has part of the answer, but for true load balancing and high availability you would want to use a pair of hardware load balancers like F5 bigips in an active passive configuration.
Yes your domain IP would be hosted on these devices and traffic would connect firstly to those devices. Bigips offer a lot of added functionality including multiple ways of load balancing and some great url rewriting, ssl acceleration, etc. It also allows you to run your web servers on a seperate non routable address scheme and even run multiple sites on different ports with the F5's handling the translations.
Once you introduce load balancing you may have some other considerations to take into account for your application(s) like sticky sessions and session state but that is a different subject