Sorry - desperate for help with response times

[John Fligg]

I have been chatting with Bruce on this one and whilst I take his valued comments on board think I still need some verification from the public. I also have some evidence I need an opinion on.

First the evidence. Attached are 2 images of the same system. Tim is the Users screenshot and Ambrit is mine. Both are using the same screen size on a touchscreen device. The Users device is a Samsung Android. Mine is a Dell Windows tablet.

Looking at Tim, note how the bottom row of buttons (just visible) line up with a large space on the Home menu and how that menu is double spaced. Now check out Ambrit - the buttons are lined up as expected and the menu items are single spaced.

Bear in mind I am logged into his account so using the same Preferences so the menu style being used is the same.

So my question is why would this be? Is this something to do with the scripts running on his machine? BTW I have tried compressed and incompressed and there is no difference. These are uncompressed.

Now for the favour I need ....

Can anyone please log into www.ambritsoftware-us.com and enter without the quotes "farrierus" and "demo" - password is lower case. From the Start menu select Horse and either add or edit a Horse. I am told that the response times are slow. Now add a Breed or any of the lookups. Again the response times are very slow I am told. Does anyone find the response times unacceptable?

I am really looking for someone to do this using Android but being paranoid now (the latest response times were 26 seconds to open a lookup I am told!!!!) any OS would do.

I am told the Clients machine is new and a good internet connection and whilst I know there can be no direct comparison, a competitors software runs perfectly on his machine.

If anyone can explain the difference in screenshots that would be good and would that have any bearing on this response time issue? Also any feedback as to response times would be really useful.

Many thanks guys.

John

[attachment deleted by admin]

[kevin plummer]

Hi John,

Are the 2 screen shots using the same Browser? That's the first thing I would look at.

As for the speed, if you read the jQuery Mobile development blog there was an interesting post on how different devices performed and how after they optimized some code some of the improvements in some of the devices that ran very slow. I'm not saying this is anything to do with your problem but it clearly demonstrates different devices and different browsers run at different speeds and the technology behind them and how bugs in various os and browsers can affect performance. You mentioned in a previous post that in mobile mode it ran very fast and desktop mode was very slow - to me that shows there is a problem running jQuery desktop framework on an Android/Google device. So can you get your client to download Firefox and try that?

[John Fligg]

Hi Kevin - thank you. Good idea. Jist one thing and Bruce will tear his hair out (sorry Bruce!).

I know nothing about jQuery. So is jQuery unique to NT6 - what I mean is that the competitors software runs perfectly. Could it be they are not using jQuery for their web enabled app?

Might that be the difference?

Thanks

John

[John Fligg]

Oh BTW I believe he is using Chrome as I am. So yes the screenshots are the same. I believe that double space is a clue.

John

[kevin plummer]

jQuery is not unique to NT6 but that does not mean all web technologies use jQuery. There are lots of different technologies and I suspect a lot don't use the framework but it is incredibly powerful and becoming more and more popular that it is becoming an add-on to these other techniques. So there is a good chance your competitor does not utilize the technology but I'm not saying jQuery is the problem - it's just one of the many pieces to the puzzle that makes your app work.

You would think Chrome running on Android and Windows would render a web page the same but maybe he is on a different version and they are 2 different os after all so maybe there are subtle differences in the underlying browser code.

[John Fligg]

So far everyone testing MY application has been using Windows on a desktop or Tablet. I have not had any feedback on anyone using Android. Just general comments here that Android is not a problem.

His desktop (XP) using whatever browser he has (I suspect IE) works perfectly.

Have asked me to send me the browser and version he is using and then will ask him to install Firefox mobile.

My Dell Inspiron Duo although a tablet works more like a laptop and runs full versions of the browsers, not the mobile versions.

But that double line spacing on the menu I really feel holds the clue. The times are atrocious now, 23 seconds to open any  window. Weird.

[kevin plummer]

I would also check what android version he is running. Upgrading the version may also help.

[Johan de Klerk]

Hi John,

I tested with my son's Tab:
Samsung Galaxy Tab 10.1
Android Honeycomb 3.2
Default browser on tab
Location: South Africa
ADSL 4Mbps line

Added a horse "johan"
Lookups and everything else is nice and fast.

Have not seen any response times above 2 seconds to do any lookups.

Hope this helps.

Regards

Johan de Klerk

[John Fligg]

Thank you Johan. That is making me feel better. But I have some very interesting information now. I hope someone can make sense of it.

First of all I am using a Rackspace server in the US and the client is in the US. I have no idea who they use.

The client tells me he is using a "Samsung Galaxy tablet. Andriod 3.1 operating system. " I need to find out more. I assumed it was new based on what he was telling me. Now I am beginning to wonder.

He has now installed Firefox mobile and the response times have gone down from 26 seconds to 14 seconds. The menu has now gone back to normal spacing. The buttons are responding whereas before they were not. However he says from pressing "Insert to Saving", so it is not clear what else is happening in between. Only just noticed that.

Now I happened across a site called gomez.com where they test response times of websites. I really am not quite sure what they are telling me but here are the reports. I have no idea who my competitors use for their cloud services.

My site: http://www.gomez.com/multi-browser-performance-test/your-multi-browser-website-performance-test-results/?testid=c6c51f9ea971d38b93eb2ffccdf99308&lang=en

Their site: http://www.gomez.com/multi-browser-performance-test/your-multi-browser-website-performance-test-results/?testid=959acc13aecdcc2a8a3154714c819491&lang=en

Why is there such a huge difference between the two? You found a good response time in SA so I am not quite sure of the relevance. Also response times in Australia who have bad 3g connections are under 2 seconds.

Many thanks.

John

[kevin plummer]

Try to get your client to upgrade to 3.2

There are reported issues with 3.1

[John Fligg]

Thank you. Just got back from lunch to find your suggestion and the client had already updated. He says all works perfectly now.

I did some Googling and found this ....

http://code.google.com/p/android/issues/detail?id=17353

VERY interesting - jquery/javascript was almost unusable in 3.1

Wow!!!

Hope this helps someone perhaps.

Thank you to everyone for your help.

John

[rjolda]

Hi,
I have a Net Talk Server.  Runs well on I Phone and Android.   Very fast.....
If your end users are connecting via cell connection then the cell transmission may be the cause of the delay.....try them on WiFi.
My apps also work well on my Android tablet - Honeycomb 3.X
FWIW,
Ron Jolda

[John Fligg]

Thanks Ron

This is a tablet device and I think very much device dependent.

The client had a NEW Samsung 1 month old running Android v3.1 and very slow with jquery and javascript. Upgrading to v3.2 and it works perfectly. Being a month old he never thought to check for a later version. Also automatic updates are not the default apparently.

So maybe it is just some Samsung devices as others have reported Android v3.1 to be fine also.

Just one of those things I guess.

Thanks

John

[bruce2]

Thanks for the feedback John. I suspect this issue will come up a fair bit in the months to come, and it's good to know the solution.

Cheers
Bruce