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.

Try using a different browser something like Firefox

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.

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
:path:/api/?u=dca241af
:content-length:102944
...
Request send = 92 ms
Waiting = 3.99 s

The API scalability is not optimal.

Sending a small text message (2 hours ago) took about 5 seconds!!

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!

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

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

Hi Bill,
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

Hi,

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.

That might also be useful for my account. My ticket is PTN388130.

Just created PTN388569

I opened a support ticket on this exact issue back in Sept or Oct. I'm in Canada.
PTN375092

BritTim asked me to pop in and look at this. Sorry I haven't had a chance yet.

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.

Hi Bron, I'm seeing a problem here as well when using the web interface. Whenever I send an email now it hangs 5-10 seconds. This behavior just started recently, and actually really impacts productivity, because I'm blocked completely from doing anything else in the Fastmail UI while it is sending. If you think of going through a large number of emails and replying first thing in the morning, and you're blocked eight seconds for each one, then you've already been sitting waiting for over a minute for just replying to eight emails (!!).

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!