Above sample is not bad system responded in <1s for >88%. It looks like no optimisations needed here. Let’s see different case:

Ops! We had some performance problems 2010-03 .. 2010-07 (twitter.com, BTW). Looks like they were fixed in next months.

We are going to allow store and show day-by-day visualisations as well to give you feedback in shorter amount of time.

• In-place branches (I used to use them heavily)
• Faster (no Python libs loading during “cold” start)
• Can’t live without “git rebase -i” now

504 Gateway Time-out
nginx/0.7.64

Oto wynik monitora realizowanego przez site-uptime.net:

Jak widać serwis boryka się z problemem wydajności podobnie jak kilka miesięcy temu Twitter. Czyżby znowu “popularność zaskoczyła drogowców” ?

Aktualizacja (2010-06-13). Sytuacja nie wygląda najlepiej. Od tygodnia ciągłe pady i uptime 82%:

Note: all uptime buttons and images below are generated in real-time, you can click on images / baners to see reports with details directly from site-uptime.net.

MySpace

MySpace uptime

Facebook

Facebook uptime

Twitter

Twitter uptime

As you can see the “winner” in this category is: Twitter!

Site-uptime.net

site-uptime.net is a service that continuously monitors websites and allows to configure email / SMS notifications on downtime. May be helpful for professionals who care about accessibility and uptime of their services.

Random network instability visible during last days forced me to make a fast migration S1 to new server. Linode slice deployed in UK was choosen as default platform for S1 monitoring station. Their networks and servers proved to be very stable in past few years.

I hope new infrastructure will make better measurements and lower false notifications ratio.

Site: http://twitter.com is down ('502 Bad Gateway')

Looked at main Twitter page and saw this picture:

I checked that Twitter responds very slowly and randomly shows “over capacity” page. You can see details on site-uptime public report. Here’s response graph from last days (measure interval 15 minutes, HEAD requests):

UPDATE (2010-04-15): after few weeks the situation is getting worse:

Bardzo ciekawe. Po kolejnej próbie otwarcia strony dostaję następujący komunikat serwowany z url-a: http://www.goldenline.pl/offline.html:

Przerwa zapewne jest planowa, oczywiście obiecuję trzymać kciuki za obsługę portalu

Oto co zobaczyłem w środku pliku HTML:

<a href="http://www.goldenline.pl"><img src="logo_big.gif" alt="Praca w GoldenLine" /></a>

Czytaj “mamy problemy ze stabilnością, być może jesteś kompetentnym adminem, żeby nam w tym pomóc, zapraszamy” . W innym:

<!--<strong>GL wraca o 05:00 jeszcze szybszy  </strong>-->

Dość duże to okno serwisowe

UPDATE (2010-02-08): sytuacja została opanowana przed 5-tą jak widać na wykresie:

One week HTTP measurement

I’m using another service: site-uptime.net to record and analyse statistics from running Twitter website. Measurements are performed every 15 minutes using HEAD requests, total time of receiving response (excluding DNS resolution time) is collected. Here are the results showing data collected from eight days using station from Poland:

You can see time response spikes located every ~10 PM GMT +2. Are they related to server load or network? To check that we can see measurements retrieved using station from Chicago, USA:

The picture is quite different. Seems the traffic on network connection to Europe causes higher access time. Let’s see if it has impact on speed of serving responses:

Not so bad. ~90% of requests are served under 1 second, it’s very good result. Average response time is 650 ms, minimal: 370 ms . Note no downtimes in January – a good result.

Where’s Twitter located?

Let’s see where twitter.com web server is located:

$ mtr twitter.com
(...)
 6. te3-1.lonse1.London.opentransit.net        0.0%    27   48.2  48.8  47.8  49.8   0.5
 7. xe-3-1.r01.londen03.uk.bb.gin.ntt.net      0.0%    27   48.6  96.8  48.1 244.9  67.3
 8. ae-1.r22.londen03.uk.bb.gin.ntt.net        0.0%    27   50.3  50.9  48.9  72.3   4.6
 9. as-0.r20.nycmny01.us.bb.gin.ntt.net        0.0%    27  131.7 129.7 127.7 132.7   1.4
10. ae-0.r21.nycmny01.us.bb.gin.ntt.net        0.0%    27  124.1 125.3 122.6 136.4   2.8
11. as-0.r20.chcgil09.us.bb.gin.ntt.net        0.0%    27  141.4 146.0 139.8 172.6   9.1
12. ae-0.r21.chcgil09.us.bb.gin.ntt.net        0.0%    27  144.7 147.4 143.7 181.2   7.7
13. as-5.r20.snjsca04.us.bb.gin.ntt.net        0.0%    27  199.7 210.2 199.7 281.7  18.4
14. xe-1-1-0.r20.mlpsca01.us.bb.gin.ntt.net    0.0%    27  203.7 204.2 198.9 242.5   8.0
15. mg-1.c20.mlpsca01.us.da.verio.net          0.0%    26  200.1 200.2 195.2 207.2   2.5
16. 128.241.122.117                            0.0%    26  196.7 197.6 193.1 209.1   2.7
17. 168.143.162.5                              0.0%    26  201.7 226.6 196.2 278.5  28.2
18. 168.143.162.36                             0.0%    26  196.4 212.4 195.8 261.2  21.0

Far from Europe (200 ms). geoiptool service will show more details:

Servers are located in Colorado. The best times I can get from USA is ~110 ms (tested from Newark). Seems Europe Twitter users are in worse position, but the kind of service (short messages, easily compressable text content) works fine with such packet delays.

About Measurement Service

site-uptime.net allows you to measure any website and notify you on downtimes. You can check how your website is visible for customers 24/7 and are able to track any problems (even if they appear out of your local business hours).

Obserwując statystyki działania usług WWW można zaobserwować pewne schematy zachowania czasu odpowiedzi systemu które mogą wynikać z:

• aktualnej liczby użytkowników serwisu (która się zmienia w ciągu doby)
• chwilowego obciążenia maszyn realizującej usługę (skorelowane z liczbą użytkowników)
• czynników leżących poza serwerem jak np. obciążenie sieci
• regularnych automatycznych operacji administracyjnych (tzw. okno serwisowe)

Wykres pomiaru czasu odpowiedzi strony http://onet.pl za 8 dni wskazuje na ten ostatni czynnik:

Podpowiedź do pytania z tematu postu podkreśliłem na czerwono. Onet.pl wykonuje automatycznie jakiś proces który pomiędzy 5:00 a 5:15 odłącza mechanizm generujący stronę WWW. 15 minut to czas kiedy serwis może sobie raz na dobę “odpocząć”. Kondycja godna pozazdroszczenia

site-uptime.net jest usługą która pozwala ocenić jakość działania serwera na podstawie regularnych pomiarów czasu odpowiedzi HTTP. Problemy mogą być raportowane na wskazany adres e-mail lub SMS-em. Pozwala to na szybką reakcję w przypadku kiedy występuje problem i ocenę wydajności infrastruktury na podstawie danych historycznych.

Obsługa PayPal oczywiście nadal będzie dostępna równolegle z DotPay.

However, such random problems may show efficiency problems with your site (timeouts). You should check carefully what’s hidden behind them (web server error log, if available).

Today I’d like to share some observations on web applications speed. My monitoring network checks almost one thousand of URL addresses and few interesting pictures are created here.

Lets see sample monitoring results from random URL (one week measurment): http://forum.magicsquad.eu (located currently in webh.pl hosting provider):

As you can see typical site response time is almost four seconds! (DNS resolution time excluded) Measurment is performed from Cracow, Poland. Let’s see results from Chicago, USA:

Similar picture (slightly slower ping times visible). We have two possibilities here:

• Script is clumsy (PHPBB)
• Hosting is overloaded / improperly configured

Long term analysis

Let’s see statistics generated by site-uptime.net (monitoring station in Poland):

As you can see performance degradation (80% -> 10% responses under one second) started 5 months ago!. No one noticed that average page loading drops suddenly (no change of hosting provider since then!).

You can reach current public report for monitored station here.

Conclusions

• I suggest to monitor site performance and availability, especially if you are making money from them
• Sometimes fix is at your fingertips (if you know the problem details)