Optimize the web apps, or build a better solution - Under Study

#1 Ajouté par Kaetemi il y a 3 ans [en]

Based on my measurements, your web apps take between 1 and 2 seconds on every page load. This is an unacceptable latency, especially in gaming.

Studies have shown that for every 100ms of action delay, sales will drop by 7%. (See https://web.archive.org/web/20200507112031/https://www.akamai.com /uk/en/about/news/press/2017-press/akamai-releases-spring-2017-st ate-of-online-retail-performance-report.jsp.) Though, I suppose the proof is in the pudding.

---

Kaetemi

#2 Ajouté par Ulukyn il y a 3 ans

{translate}

Please send us your measurements and the conditions under which they were taken so that we can see how to improve them.

For the link, be careful, it is not a reliable study, Akamai is a company that provides fast hosting and simply says that it can lower by 7% but without proving it. It is purely marketing

#3 Ajouté par Sinvaders il y a 3 ans [en]

{translate}

Just open any ARK related thing in-game, and you'll see that is slow, no need for any measurements to notice it.
Example: marauder teleport crystal.

#4 Ajouté par Kaetemi il y a 3 ans [en]

{translate}

Eh, these are well-known facts in the industry. Especially in games, any responsiveness delay above 300ms will lose you players. Web apps are a bad strategy if you can't ghost the interaction locally.

Here's another article. There are many more similar studies.

https://www.forbes.com/sites/steveolenski/2016/11/10/why-brands-a re-fighting-over-milliseconds/

Research suggests that 25% of people will abandon a website that takes longer than 4 seconds to load. Amazon found that just 100 milliseconds of extra load time cost them 1% in sales. Those statistics, as profound as they are, pale in comparison to video buffering.

Users hate video buffering. Just one instance of buffering decreases video consumption by 39%. This is a real problem for companies in the video distribution space. And since all brands are media companies today this pretty much applies to everyone.

I'm on a 250 Mbps fiber connection. With 5ms ping to Cloudflare, and 250ms ping to the Ryzom server. You've got plenty of milliseconds left to stick below 300ms. Hell, even sticking below 500 ms would be a massive improvement.

Edité 4 fois | Dernière édition par Kaetemi (il y a 3 ans).

---

Kaetemi

#5 Ajouté par Ulukyn il y a 3 ans [en]

{translate}

The game engine itself has major optimization issues. You can be killed several meters away from a monster because of the latency. Long texts take forever to reach the client, while web apps display the same content in 30x less time. Not to mention the fact that each player runs at different speeds depending on their internet connection.

All these problems are part of the Ryzom Core engine and you never worry about them, although you will agree that it is much more annoying than a webapp that takes 500ms to display. Of course, this does not mean that we should do nothing. Just that we use webapps in contexts where latency is less important than in a combat session.
Moreover we use more and more lua code to reduce the reaction time of the interface of the new webapps

#6 Ajouté par Kaetemi il y a 3 ans [en]

{translate}

Ulukyn

Long texts take forever to reach the client, while web apps display the same content in 30x less time. Not to mention the fact that each player runs at different speeds depending on their internet connection.

All these problems are part of the Ryzom Core engine and you never worry about them

No, there is a ticket for it.
https://github.com/ryzom/ryzomcore/issues/628

(Besides, I am more focused on getting RC in the hands of more developers at this point. Lower the time to get a dev shard running. Not in the business of trying to do everything by myself.)

The running speed is already fixed in the latest Core, but it's a breaking change, so excluded from the merged batch. The server was attaching server timestamps to client positions, which caused jittery player movement under the right conditions.

Edité 3 fois | Dernière édition par Kaetemi (il y a 3 ans).

---

Kaetemi

#7 Ajouté par Ulukyn il y a 3 ans [en]

{translate}

Cool :)

The ticket is not associated with any commit. Can we have the list of associated commits to see if we can apply it?

#8 Ajouté par Kaetemi il y a 3 ans [en]

{translate}

Ulukyn

Cool :)

The ticket is not associated with any commit. Can we have the list of associated commits to see if we can apply it?

For the additional protocol? No implementation yet. (As I said, other priorities.) It's just a ticket. It's fairly easy to implement, though.

For the running speed:
4407fc29708aaffb451e9d578263f163f874863c
92bfb0aafbd5fbc93d157eb0f521fdc36190b65e
d07e2194395b4bcbaacff817fc616153c07cfa64
20ed0a4412437fc7d2013e781eabce02b1abbb9e
5b22e0950a65d9080dd48aa69c52542c94278ca2

Dernière édition par Kaetemi (il y a 3 ans).

---

Kaetemi

#9 Ajouté par Kaetemi il y a 3 ans [en]

{translate}

Ulukyn

You can be killed several meters away from a monster because of the latency.

This is because the LCT is flat (1s), regardless of distance, and is tuned for the refresh rate of any (read: far) mobs. It's a lousy flaw, but doesn't affect action/attack latency itself. Action response time is not really affected here.

Two potential options to investigate, though. Move to a smooth radial gradient for the client-side LCT on positions (assuming the peak update interval is consistent by distance). Or estimate the client-side distance on the server-side when mobs attack (less interesting, because it'll become too easy to run away).

---

Kaetemi