DivineTraube

11 ms·

61.
Parse Is Gone: Unpublished Details About Their Infrastructure(medium.com)
12 points by DivineTraube 10y ago|0 comments
62.
The Parse Infrastructure: What They Did Not Tell You(medium.com)
11 points by DivineTraube 10y ago|0 comments
63.
Parse Is Gone: A Few Secrets About Their Infrastructure(medium.com)
20 points by DivineTraube 10y ago|0 comments
64.
by DivineTraube 10y ago
Of course, it's a little unfair to declare it failed. The exit definitely was impressive. However, the product still died. It's hard to tell without the real business metrics whether this was due to lack of sustainable revenue and
65.
by DivineTraube 10y ago
That is definitely true for some of the older versions of Mongo. Still, a quorum write concern will yield far fewer consistency violations. An interesting trade-off to take: losing a little data is better than losing a little latency.
66.
by DivineTraube 10y ago
A little Parse trivia a gathered from talking to (very capable) Parse engineers that now work at FB: - Still the world's largest MongoDB user - Had 1M apps, largest one with 40M users - Server was Rails at first (24 threads max. concur
67.
by DivineTraube 10y ago
Thanks a lot, it's fixed now.
68.
by DivineTraube 10y ago
We fixed that problem and deployed it. It turned out to be the iframe with the tutorial app. That sets a new hash with a random todo list id and that captures the back button. It was not intended to keep people on our site. Thanks for point
69.
by DivineTraube 10y ago
> It is true that with Shopify or similar platforms you aren't able to make backend choices or implement caching like the article has described, and yes it's true that all the themes in the theme store aren't perfectly op
70.
by DivineTraube 10y ago
How about Googles Doubleclick (2016): 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load [1]. Mobify (2016): For every 100ms decrease in homepage load speed, Mobify's customer base saw a 1.11% lift in s
71.
by DivineTraube 10y ago
We built Baqend around the caching algorithms that we developed at the university. Our goal was to make the performance optimizations applicable to as many contexts a possible. We went for the "serverless" pardigm and backend-as-a
72.
by DivineTraube 10y ago
That should be done a lot more than it's usual today. Part of "mobile first" should be testing mobile speed. One problem is of course that mobile networks vary greatly in both latency and bandwidth. A great resource on perfor
73.
by DivineTraube 10y ago
Sure. There is an abundance of studies. My favourites are [1]: -100ms of additional page load time cost 1% revenue (Amazon) -400ms means -9% vistors (Yahoo) -Showing 30 search results instead of 10 and therefore accepting 500ms of additiona
74.
by DivineTraube 10y ago
You're absolutely right, latency in the checkout process is a conversion killer. Somehow Paypal currently seems broken, maybe it's still related to the Dyn DDOS attacks which took Paypal down completely. During our testing, Paypal
75.
by DivineTraube 10y ago
All major browsers do respect the TTL if one is set. So it does save many requests. If it's not possible to the the TTL because the content might change at any time it is still useful to a caching header with a TTL of 0. Otherwise the
76.
by DivineTraube 10y ago
Unfortunately on the server that method executes a synchronous API call to Paypal Plus, which has very flaky response times.
77.
by DivineTraube 10y ago
You're right that browser caching has a few tricky parts, which is why we do a some things differently. What you describe is an HTTP revalidation (If-None-Match, If-Modified-Since) which the browser triggers in two cases: -if the TTL d
78.
by DivineTraube 10y ago
You're pointing out an important point: third-party services have to be fast, too. The call that starts the checkout does a synchronous request to Paypal Plus, which has very ugly request latencies from time to time. The shop is indeed
79.
by DivineTraube 10y ago
The JMeter load tests were conducted to test the throughput of the CDN and backend setup (browser caching was disabled). The load generating servers where hosted in Frankfurt (Germany) where the CDN (Fastly) also has an edge location. This
80.
by DivineTraube 10y ago
And it not only hurts because of revenue. Slow sites also let users preceive quality and credibility as lower (Fogg et al. 2001; Bouch, Kuchinsky, and Bhatti 2000). The startup/brand will end up being seen as less interesting and attra
81.
Building a Shop with Sub-Second Page Loads: Lessons Learned(medium.com)
271 points by DivineTraube 10y ago|96 comments
82.
by DivineTraube 10y ago
HTTP has a good solution/proposal for this: the server can include a stale-on-error=someTimeInSeconds header in addition to the TTL and then every cache is allowed to continue serving stale data for the specified time while the origin
83.
Web Performance: A Survey(medium.com)
9 points by DivineTraube 10y ago|0 comments
84.
Sub-Second Page Loads: Web Performance by Example(medium.com)
11 points by DivineTraube 10y ago|0 comments
85.
Building a Shop with Sub-Second Page Loads: Lessons Learned(medium.com)
11 points by DivineTraube 10y ago|0 comments
86.
Building a Shop with Sub-Second Page Loads: Lessons Learned(medium.com)
9 points by DivineTraube 10y ago|0 comments
87.
by DivineTraube 10y ago
So AMP does two major things: (1) It prescribes a stripped-down version of HTML and uses a JS loader to render fast and load as much resources as possible asynchronously (2) It caches the website in the Google CDN and delivers it via HTTP&#
88.
Scalable Stream Processing: A Survey of Storm, Samza, Spark and Flink(medium.com)
135 points by DivineTraube 10y ago|41 comments
89.
Scalable Stream Processing: A Survey of Storm, Samza, Spark and Flink(medium.com)
12 points by DivineTraube 10y ago|0 comments
90.
Real-Time Stream Processing: A Survey and Decision Guidance(medium.com)
6 points by DivineTraube 10y ago|0 comments

More ›