I created a rest api and I am not very happy with the performance of it. I spent some time to investigate and stumbled across a tool to easily track the performance of my api (www.apiscience.com).
They split the overall response time in 4 categories- connect, resolve, processing and transfer. The resolve part often takes about 150ms while the processing of the call itself only takes about 18ms which results in an average response time of 160ms (the call i tried here is really simple so the average would be higher normally).
My question is how can I improve/minimize the resolve time for my calls?
(side info: my servers are placed in Ireland and I chose Ireland as location for the tests too)
Thanks in advance!
Edit - What do they mean with Resolve Time?
(https://www.apiscience.com/blog/what-do-api-sciences-curl-based-timings-mean/)
API Science’s “Resolve Time” is the equivalent of Ken’s “DNS Lookup.”
DNS stands for Domain Name System. A URL consists of text (and
sometimes numbers); however, the communication addresses that compose
the Internet are formulated as IP (Internet Protocol) addresses, for
example, 208.80.152.2. Before a request can be routed between the
requesting client and the server that will process the request, the IP
address that the URL refers must be looked up. A request is sent to a
DNS resolver by curl, and the resolver returns the correlated IP
address. API Science’s “Resolve Time” is the time in milliseconds that
it took this operation to complete.
As the documentation mentions, the DNS resolution time is the amount of time an API consuming client waits before finding out where to route the actual calls to your API server - the mapping between your server's name and IP address.
Where you host your DNS can be completely independent from both where you host your API service, and where your domain name is registered, and there are multiple choices in the market for DNS hosting service. DNSPerf (of which I have no affiliation) does a comparison of services and is probably a good starting point for further research if you'd like to select a new DNS provider.
Related
I am trying to detect bot traffic to an application using a list of session ips.
The simplistic solution would be to find occurrences of identical ips and if the number of these are beyond a threshold, we could say that that traffic is coming from a bot.
I got myself thinking and doing some research and was questioning:
Could traffic coming from a single IP be coming from multiple users hiding behind a subnet or proxy? In which case definitely not being a bot?
(also i dont really understand how subnetting or proxies work, so be gentle.)
there is more than just visit from IP, and its possible to get different visitors from the same IP (especially if visitor is using dial-up connection)
The way I would catch bots are with process of elimination from obvious to probable
if userAgent is empty
if userAgent is short or not descriptive
if userAgent contains some obvious signatures or rogue bots that I
don't want accessing my site
if visitor's average pageview stay on the page is less than 3 sec its
a bot
in this case I bounce the hit
and then not so obvious
I record a ip, timestamp and userAgent of every visit for 30 min. and compare every new visit to the pool.
If IP is accessing the site too quickly, most likely its a bot
if IP is accessing the site with different userAgents is probably a
bot
in this case I preset captcha
Problem description:
I have 2 EC2 instances which are located in the Europe and North America region. Now I have setup a Route 53 to direct user request to these servers with Weighted Round Robin record set
When user being directed to one server and created session, the next time it resolve the domain name it could be direct to the other server which doesn't have the session. (e.g user logged in and clicked another link and has to login again)
Thoughts:
I could have a load balancer to ensure session stickiness of both server but in this case the Weighted Round Robin DNS routing can't be set.
I can also increase the TTL of DNS response but again it almost eliminates the effect of WRR.
Or I could configure servers to share sessions (which I don't know how to. The server is Ofbiz server) and I am not sure whether it is good practice.
Question:
Is there a way to maintain user sessions while using Weighted Round Robin Record on Amazon Web Service Route 53 ?
Many thanks !
DNS round-robin works perfect for a short-life TCP connection (e.g. Performing a query). However, If you want to provide a longer session, please make sure that you have a longer-life session between your client and server. You can use HTTPSession between your servers and clients and the Connection will stay open till the session gets expired.
As you mentioned, increasing TTL will not solve the problem because you could set a TCP connection close to expiry time of one DNS response and next time you get different IP address from a new DNS response.
If you don't want to use HTTPSession for any reason, you probably better use Elastic Load Balancing (ELB) to do the same thing for you.
Given that our linux servers never open direct connections to our clients, is it safe to use tcp_tw_recycle on them ?
Those servers are behind a application level load-balancer and all the connections i see on them are between internal 10.x.x.x addresses.
Thanks
We have such a load balancer provided by AWS (ELB), so I'll provide my advice based on that:
Why gamble? If your overhead/port-consumption is coming from quick client connections, Amazon recommends enabling persistent connections on your ELB instead. (I asked them about this question specifically and got that recommendation...our Amazon contact does not recommend enabling tcp_tw_recycle).
That said, if, say it's another internal box they're struggling to establish rapid connections with (apache-php chatting with MySQL on behalf of the client without persistent connections), you might be able to get away with it:
If ALL client connections will be via the ELB (please set your security group accordingly), then technically speaking you shouldn't encounter problems for the tcp_tw_recycle timestamp jumping cases I'm aware of:
ELB is a termination point on behalf of the client (their NAT firewall won't factor in, and ELB is not NAT based)
The ELB box(es) will not reset themselves, acquire the same IP address, and still be assigned as your ELB (will be someone else's if it happens at all)
The ELB box(es) will not be replaced by another ELB machine using the same IP and still be serving your traffic as your ELB (will be someone else's if it happens at all)
*2 and 3 are not a guarantee from Amazon, but it does appear to be their behavior, just as stop/start will get you a new private IP for EC2 boxes). If that did happen, I'd imagine it is a thing of extremely low probability.
You could theoretically run into issues restarting your own boxes if they communicate with other service machines (like MySQL or memcached) and you restart (not stop/start) one of your boxes, or move their elastic IP to another box and are not using private IPs for internal chatter. But you have some control over this. However, if it's all on the AWS cloud (or your fast internal network), issues are extremely unlikely (unless your AWS zone is having a bad day, and you're restarting/replacing your systems for that reason).
A buddy and I had a long-standing argument about this, and he won by proving his point with a long running 4k browser (fast script) load test via Neustar...there were no connection issues from the client side via ELB, and eliminating the overhead helped quite a bit :-)
If you haven't already, consider tcp_tw_reuse (we were using this to keep the ephemeral port range active before the above mentioned test showed the additional merit of eliminating the overhead with tcp_tw_recycle for us). Be sure to watch your counters on ifconfig if you do decide to disable that chunk of the protocol ;-P.
The following is also a good summary resource on the topic of timestamps jumping: Dropping of connections with tcp_tw_recycle
I want to get DateTime from an external reliable source. I know I can get it via DateTime.Now() Method, but that can be fooled easily by changing the Systems Date and Time. Is there a way around? It is a windows form app!
You need a Network Time Server Client class.
In short, you ask one of the numerous Time Server on Internet the date and time to set your internal PC clock using the NTP protocol.
If you search for NTP Client you will find numerous examples.
This is the first that came out from a Bing Search
Quoting:
The Network Time Protocol (NTP) and its simplified form (SNTP) are widely used to
synchronize network resources, due to their simplicity and effectiveness.
Of course, as everything installed on a client PC, also this could be hacked faking the address of the time server and returning a different value. But this will require more work from the hacker than simply resetting the PC clock.
While you might implement a Network Time Protocol client in your app and request the current time over the net or request something from some http server and use the time from Date response header, this also may be fooled (the one may intercept the traffic and send you responses on behalf of the time server you will be connecting or tweak http response).
Though, the easiest is to get response from some http server.
In the firefox developer tools, under the "Net" panel, resources that are loaded have their load time split into different colors/categories. These are:
DNS Lookup
Connecting
Blocking
Sending
Waiting
Receiving
What do each of these represent, and more specifically, does any of them accurately represent the amount of time that the server is thinking (accessing the database, running algorithms, etc)?
Thanks.
You couldn't accurately determine what the server is doing as such, I'm afraid.
You can discount most of them except Waiting, however, as the rest occur before and after the server handles your request. What it actually does while you wait will be a 'black box'.
There may be some asynchronous operations taking place during Sending and Receiving, so again it's hard to be accurate but you can get a ballpark figure of the time the server is working and the time the request spends travelling back and forth.
EDIT
Rough Definitions:
DNS Lookup: Translating the web address into a destination IP address by using a DNS server
Connecting: Establishing a connection with the web server
Blocking: Previously known as 'queueing', this is explained in more detail here
Sending: Sending your HTTP Request to the server
Waiting: Waiting for a response from the server - this is where it's probably doing all the work
Receiving: Getting the HTTP response back from the server
The firebug wiki also explains these (see the Timeline section).
Blocking Time spent in a browser queue waiting for a network
connection (formerly called Queueing). For SSL connections this includes the SSL Handshake and the OCSP validation step.
DNS Lookup DNS resolution time
Connection Elapsed time required to create a TCP connection
Waiting Waiting for a response from the server
Receiving Time required to read the entire response from the server
(and/or time required to read from cache)
'DOMContentLoaded' (event) Point in time when DOMContentLoaded event was fired (since the beginning of the request, can be negative if the request has been
started after the event)
'load' (event) Point in time when the page load event was fired (since the beginning of the request, can be negative if the request has been started after the event)
There's a pretty good article with time charts and a protocol level explanation of what's happening at each stage here.I found it pretty helpful as they also visually demonstrate the impact of using persistent and parallel connections versus serial connections.