Saturday, 23 January 2016

Astro BytE

Houston, do we have a new planet?







What’s the excitement about? Do we have a replacement for Pluto?

Earlier this week, astronomers Konstantin Batygin and Mike Brown of the California Institute of Technology (Caltech) in Pasadena, U.S., reported in the peer-reviewed Astronomical Journal that a body as big as Neptune — but as yet unseen — orbits the Sun every 15,000 years. Mr. Brown was among those who played a pivotal role in downgrading Pluto from ‘planet’ to a mere ‘dwarf planet’ and so his championing for Planet Nine is being taken quite seriously by the astronomer community. Then again, unless there’s visual confirmation, we don’t have a new planet.
How big is it?
The object, which the researchers have nicknamed Planet Nine, has a mass about 10 times that of Earth and orbits about 20 times farther from the Sun on average than does Neptune (which orbits the Sun at an average distance of 2.8 billion miles). In fact, it would take this new planet between 10,000 and 20,000 years to make just one full orbit around the Sun.
How long has the search for such planets been on?
The search for planets beyond Uranus has an over 150-year-old history. Based on the peculiar movements in the orbit of that planet, astronomers felt there had to be a heavy body that was causing these skewed movements and presto, Neptune was found in the mid 19th century. But that still wasn’t enough. Among the several objects found beyond Neptune — in a region that is now known as the Kuiper belt — the most prominent was Pluto, discovered by Clyde Tombaugh, in 1928. But decades of data later suggested that Pluto was too small to be a proper planet and there were bigger objects that could be better contenders.

Why is the Batygin-Brown duo so confident about their potential discovery?
According to a news report in Science, the duo inferred Planet Nine’s presence from the way six Kuiper objects orbit. They say there’s only a 0.007 per cent chance, or about one in 15,000, that the clustering could be a coincidence. Instead, they say, a planet with the mass of 10 Earths has forced the six objects into their strange elliptical orbits, tilted out of the plane of the solar system.
The orbit of the inferred planet is similarly tilted, as well as stretched to distances that will explode previous conceptions of the solar system. Its closest approach to the Sun is seven times farther than Neptune, or 200 astronomical units (AUs). (An AU is the distance between Earth and the Sun, about 150 million kilometres.)
Can we ever see Planet Nine?
Icy and cold definitely but over at Wired, Rhett Allain has made some back-of-the-envelope calculations to suggest that if Nine were to be at its closest to our Sun, it would take 63 years for a spacecraft like New Horizons (that flew past Pluto last year) to fly past it. That’s the best shot and at worst, it could be around 300 years.


Friday, 13 November 2015

Time To First Byte

Its my first post on " FunnY BytE ".....


     What is Time To First Byte ?

Time To First Byte ( TTFB ) is often used as a measure of how quickly a web server responds to a request and common web testing services report it. The faster it is the better the web server.



TTFB helps enterprises identify weak points in the connection process. By determining where delays occur, enterprises can tweak their services to perform faster and more reliably. Since a website’s speed can impact its web search rankings, TTFB has become crucial to optimizing performance and increasing visibility.


​WHAT AFFECTS TIME TO FIRST BYTE ?

TTFB is impacted by three key actions:

 1) sending a request from a client machine to the server
 2) processing that request on the server and generating a response, and
 3) sending the response from the server to the client.

Action 1: Sending a request to the server

Measuring TTFB begins with the request. The time it takes for a server to receive a request can vary based on the time it takes to perform a DNS lookup, the speed of the user’s network, the distance to the server, and any interruptions in the connection. Enterprises have no control over the link between the user and the Internet, but any delays will still impact their TTFB.

Action 2: Processing and generating the response

Once a server receives a request, it has to generate a response. This involves starting processes, making database calls, running web scripts and communicating with other systems on the network. Common strategies used by enterprises to reduce TTFB include caching web pages, optimizing server-side code, and improving hardware resources.

Action 3: Sending the response back to the client

Once a server generates a response, it needs to transmit it back to the user. This step is dependent on both the enterprise’s connection speed and the user’s connection speed. The TTFB is determined the moment the client begins receiving the response, literally when the client receives the first byte. Transmitting a request and a response over a network can account for almost 40% of the TTFB.
TTFB  Numbers

“Good” TTFB Numbers

On a well operating system, the TTFB can be under 100 milliseconds (ms) for static content such as html, images, css, and javascript files. These low numbers make sense if you consider what happens on the server side. The web server simply has to open a file, which may be in the file cache, and send it to the client. This process is very fast.
For dynamic content, the TTFB is often 200-500ms. The longer numbers reflect what is happening behind the scenes. Consider a WordPress Blog. When you make a request, the PHP scripts have to open a number of include files, make a connection to the database, parse the results, and send back the final HTML document. All of this takes time. So even on a well powered, lightly loaded system, TTFB numbers will almost always be higher for dynamic content than static content.

“Bad” TTFB Numbers

For static content, if your TTFB is more than a few hundred milliseconds, you may have some bottlenecks on your server. This could be your HTTP server not able to handle requests fast enough. Many servers will accept a connection and then hold it until it is ready to process. This backlog of requests can slow down the response time.
Another common issue with poor Time to First Byte numbers is disk IO. If your disk IO is slow, then the system may take longer than desired to open up a file and send it. Faster disks may help this situation, but you may also want to consider more RAM. More RAM may allow more files to be held in the internal file cache and lower disk IO.
For dynamic content, you cannot really define a global “bad” time to first byte number. If you have a complex application, then waiting 1-2s may be reasonable. While we like things to be faster, setting a real-world expectation for your application is important.
If your dynamic content’s Time to First Byte is longer than desired, you first want to check some hardware metrics, such as:
  • Disk IO
  • Swap Usage
  • RAM Usage
  • Network Bottlenecks
If you find your server’s hardware is adequate, then the configuration of your server could be the problem. You will want to systematically review:
  • Apache (web server) Configuration
  • PHP Settings
  • MySQL Settings
  • Network Settings
If you are making calls to remote networks or services, checking into the latency of those systems is required as well.

​BENEFITS OF OPTIMIZING TIME TO FIRST BYTE

Optimizing TTFB benefits both users and content providers.

Users see an improved browsing experience since they have to spend less time waiting for a web service to generate a response.
Enterprises see higher customer engagement and retention as users are less likely to leave due to delays or slow loading times.
                                                       -----zzz-----
( For more Knowledge .. keep reading "FunnY BytE".)