|
FastMail Forum All posts relating to FastMail.FM should go here: suggestions, comments, requests for help, complaints, technical issues etc. |
|
Thread Tools |
21 Nov 2017, 04:53 AM | #1 |
Member
Join Date: Oct 2003
Location: Lille, France
Posts: 37
|
Fastmail web getting slower?
Hi,
I have the feeling web interface is getting slower and slower since 6 month. My two computers are super fast machine (I'm IT dev) and I have super fast optical fiber. Windows 10 (fresh reinstall) + Google Chrome Do you have this feeling? Remi C:\Users\rth\source>tracert fastmail.fm Tracing route to fastmail.fm [66.111.4.55] over a maximum of 30 hops: 1 1 ms <1 ms <1 ms 192.168.1.1 2 6 ms 6 ms 6 ms 80.10.123.222 3 6 ms 7 ms 5 ms 10.123.250.74 4 6 ms 5 ms 12 ms ae41-0.niidf202.Paris15eArrondissement.francetelecom.net [193.252.98.177] 5 7 ms 7 ms 7 ms 193.252.137.74 6 7 ms 6 ms 8 ms abovenet-1.GW.opentransit.net [193.251.250.188] 7 77 ms 77 ms 77 ms ae27.cs1.cdg11.fr.eth.zayo.com [64.125.29.4] 8 89 ms 88 ms 89 ms ae0.cs1.cdg12.fr.eth.zayo.com [64.125.29.84] 9 90 ms 86 ms 85 ms ae5.cs2.lga5.us.eth.zayo.com [64.125.29.93] 10 81 ms 82 ms 81 ms ae27.cr2.lga5.us.zip.zayo.com [64.125.30.253] 11 83 ms 80 ms 80 ms ae10.mpr4.lga7.us.zip.zayo.com [64.125.20.81] 12 78 ms 77 ms 77 ms ae1.mpr2.lga7.us.zip.zayo.com [64.125.20.125] 13 80 ms 77 ms 77 ms 64.124.193.85.IPYX-076763-001-ZYO.above.net [64.124.193.85] 14 96 ms 97 ms 95 ms cs30.cs20.v.jfk.nyinternet.net [64.147.125.149] 15 91 ms 90 ms 91 ms cs20.cs90.v.ewr.nyinternet.net [96.47.77.102] 16 79 ms 80 ms 79 ms 199.83.60.138.static.nyinternet.net [199.83.60.138] 17 78 ms 78 ms 78 ms www.fastmail.fm [66.111.4.55] Trace complete. |
21 Nov 2017, 07:34 AM | #2 |
The "e" in e-mail
Join Date: Jul 2002
Location: VK4
Posts: 3,029
|
Try using a different browser something like Firefox
Last edited by Terry : 21 Nov 2017 at 07:41 AM. |
21 Nov 2017, 09:25 AM | #3 |
The "e" in e-mail
Join Date: May 2003
Location: mostly in Thailand
Posts: 3,095
|
The Pingdom reports for the last year do not suggest a general slowdown. There is a variation month-to-month of about 10%. For the Home page response times, you can see the history at http://stats.pingdom.com/w17m1yxzjyin/49229
If interested in other services, start at http://stats.pingdom.com/w17m1yxzjyin There might be a problem with the specific server that hosts your account, though FastMail seem to be pretty good at finding such issues. If the problem is glaring, I would suggest submitting a support ticket. |
21 Nov 2017, 07:42 PM | #4 |
Member
Join Date: Oct 2003
Location: Lille, France
Posts: 37
|
I leave in France.
This morning response time was good. Now at 12H34 France (UTC+1) speed degradation begins. In reply to a message that contains embeded image I get a 4 second response time. This morning it was less than a second for the same message. Yesterday evening it was around 10 seconds. :authority:www.fastmail.com :method:POST ath:/api/?u=dca241af :content-length:102944 ... Request send = 92 ms Waiting = 3.99 s The API scalability is not optimal. |
21 Nov 2017, 10:01 PM | #5 |
Master of the @
Join Date: Mar 2000
Location: Tel-Aviv, ISRAEL
Posts: 1,666
|
Sending a small text message (2 hours ago) took about 5 seconds!!
|
22 Nov 2017, 04:22 PM | #6 |
Member
Join Date: Jan 2008
Posts: 34
|
The same is (still) happening to me. I contacted support about it yesterday, but they mentioned that no other user reported problems.
If you have such issues, feel free to write about it here, but please create a support ticket as well! |
22 Nov 2017, 05:18 PM | #7 |
Member
Join Date: Oct 2003
Location: Lille, France
Posts: 37
|
Hi,
Let's all do the same test. To have exact timing with Google Chrome press F12 then chose Network Tab. It's almost the same with other web browser. When you do an action on fastmail web you should find API call and find how long it take to process the request : this the waiting time. Have a look at this screen capture. http://tmp.m4f.eu/fastmail_api_speed.png You have 3 timing. The time to send the data to fastmail, the time to receive the answer. Both are related to your internet speed. The 3rd timing is the time Fastmail take to process the request. This 3rd value is the interesting one. HOW TO TEST Send a mail to youself containing only "test01" in the subject and in the body. Open network monitor with F12 and reply to yourself with test02 in the body. Keep the biggest wait time you find for this action. In a Excel file create 4 columns : Data, Time UTC, Iteration, Wait time in ms When you think fastmail is getting slower write down waiting time. Here is mine https://docs.google.com/spreadsheets...it?usp=sharing To find your UTC time you cand use this site https://www.timeanddate.com/worldclock/converter.html Remi Last edited by rthomas : 22 Nov 2017 at 05:28 PM. |
23 Nov 2017, 03:11 AM | #8 |
Intergalactic Postmaster
Join Date: May 2004
Location: Irving, Texas
Posts: 8,929
|
Time To First Byte (TTFB) measures both the time to process the request at Fastmail (which depends on what you request) and the round-trip latency between your browser and the Fastmail servers (mostly in the NYC area in the US). I notice that the people who are reporting a delay and their location in this thread are in France and Israel. Unfortunately, the Fastmail Pingdom tests do not include those countries.
My guess is that changes which are related to the time of the day are probably related to DNS lookup and network latency. Of course, network latency could be local to you, your ISP, your country, submarine cables to the US, interconnects to the New York / New Jersey area, and at the NYI Datacenter used by Fastmail. Of course, you can have a very high speed local internet connection and still have significant latency in TTFB due to network switching issues. I’m in the US and haven’t noticed anything changing with Fastmail which differs from normal variations in internet latency variations, especially if I’m traveling and using a mobile phone connection or hotel WLAN. This week I am on the west coast of the US (a long way from the Fastmail main servers) and using a hotel and other connection methods. I don’t notice any difference from my high speed fiber connection at my home in Texas (closer to the east coast). Bill |
23 Nov 2017, 01:53 PM | #9 | |
Member
Join Date: Oct 2003
Location: Lille, France
Posts: 37
|
Quote:
Why most of the API call take less then 150 ms excepted one that take 4 to 10 seconds? Why is this always the same API call, the one that contains messagesNotSpam + messageSavedOrSent + updateMailboxMessageList + mailboxCounts that is slow? Your diagnostic is not correct. Remi |
|
23 Nov 2017, 07:32 PM | #10 | |
The "e" in e-mail
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696
Representative of:
Fastmail.fm |
Quote:
Have you opened a support ticket? We can turn on additional telemetry to see what's happening if something is odd with individual accounts. Regards, Bron. |
|
23 Nov 2017, 08:36 PM | #11 |
Member
Join Date: Jan 2008
Posts: 34
|
That might also be useful for my account. My ticket is PTN388130.
|
23 Nov 2017, 10:56 PM | #12 |
Member
Join Date: Oct 2003
Location: Lille, France
Posts: 37
|
Just created PTN388569
|
30 Nov 2017, 12:32 PM | #13 |
Junior Member
Join Date: Sep 2012
Location: Toronto, Canada
Posts: 26
|
I opened a support ticket on this exact issue back in Sept or Oct. I'm in Canada.
PTN375092 |
1 Dec 2017, 09:42 PM | #14 | |
The "e" in e-mail
Join Date: Jul 2004
Location: Melbourne, Australia
Posts: 2,696
Representative of:
Fastmail.fm |
Quote:
messagesNotSpam is a pretty expensive API call, depending on the size of your bayes database and the number of messages being reported, it can take a while to update the data. Also if the report hits a web server that doesn't have the latest bayes on it yet, it needs to fetch from the backend, write the changes, and sync them back to multiple redundant copies. It's a pain, particularly if you've done a search. We made a change just last week to reduce the lock time during the asynchronous snippets fetch, because that was holding some mailbox locks for seconds at a time and slowing down later actions. And it's spooky-action-at-a-distance when that happens. Same as deleting or moving a large set of numbers and then doing something else. The interface will allow you to do new things using cached data, even while a long running operation is happening. Mostly that's lovely, because it means you can keep working, but if you do something else which needs to wait on the server, you could wind up with the interface freezing on something which _should_ be quick, and it's because the server is busy chugging away processing the earlier request. No perfect answer to that. Server actions take time. When we switch the frontend to use the JMAP protocol, it will do some of these bulk actions as a set of smaller requests which can be interleaved with fetches, which will help remove the hiccups from your experience. It won't make the full task faster, just mean it doesn't block everything else! I've had a look at all three tickets now - they seem slightly different issues might be underneath, but the problem with replying right now is that it requires both a read and a write against the server, so it winds up hitting any other lock on the account. Cheers, Bron. |
|
1 Dec 2017, 11:04 PM | #15 | |
Junior Member
Join Date: Oct 2011
Posts: 22
|
Quote:
I know that you know this, but the traditional user experience for email is that it queues and whatever work it needs to do to send gets taken care of as the queue gets processed - i.e., not blocking the user. While there may be technical/implementation issues with this, the Fastmail web UI really shouldn't impact the UX because of them. Should I file a trouble ticket about this as well? I'm not sure if it would be helpful if others have already filed them. Thanks for listening! |
|