Surviving Success at Matchbook: Using MMS To Track
This is a guest post from Jared Wyatt, CTO of Matchbook, an app for remembering the places you love and want to try. I joined Matchbook as CTO in January with the goal of breathing new life into an iOS app that had a small, but very devote
This is a guest post from Jared Wyatt, CTO of Matchbook, an app for remembering the places you love and want to try.
I joined Matchbook as CTO in January with the goal of breathing new life into an iOS app that had a small, but very devoted following. For various reasons, we decided to start fresh and rebuild everything from the ground up—this included completely revamping the app itself and totally redesigning our API and backend infrastructure. The old system was using MySQL as a datastore, but MongoDB seemed like a better fit for our needs because of its excellent geospatial support and the flexibility offered by its document-oriented data model.
We submitted Matchbook 2.0 to the App Store at the end of June and within a few days received an email from Apple requesting design assets because they wanted to feature our app. So, of course we were all, like, “OMG OMG OMG.”
An Influx of Users
We had originally planned for a quiet roll-out of version 2.0 because it was a completely new codebase and had not really been tested under load. However, our cautious reasoning was replaced by grandiose visions of fame and glory when Apple offered to feature us.
Matchbook 2.0 launched in the App Store on July 3rd. ?It was listed on the App Store home page under “New & Noteworthy” with top billing in the “Food & Drink” category. Within a week, we had onboarded tens of thousands of new users. Sweeet! It was high-fives all around until it suddenly wasn’t.
As our user base exploded, our application performance monitoring tool (New Relic) indicated massive amounts of time spent in the database during spikes of heavy user activity. Many, many milliseconds were being squandered somewhere in the ether while our API server was chatting with our MongoDB server. Support tickets and tweets started coming in about how much we sucked. We started freaking out (just a little) and began to rue the day we let Apple promote our app.
Monitoring to the Rescue
Prior to the launch, in addition to setting up New Relic to monitor our application, we set up MMS to monitor MongoDB. New Relic showed us that the performance issue was related to the database, but didn’t provide us with the detail necessary to determine what was causing the slowdown. So, I went to MMS. The first thing that caught my eye was the cursors chart. There were some freakish spikes in concurrently open cursors for the amount of activity on the database. So I says to myself, I says, “Jared, that seems sketchy, but why is it happening?”
I poked around in MMS a bit and noticed the profile data log—it was empty. At the risk of sounding like a n00b, I didn’t know what MongoDB profiling was, but it seemed like something I should look into. The MongoDB profile documentation indicates that level 1 profiles slow operations. Wait—did someone say slow operations? That’s me! I have slow operations! So, I hopped over to our database and said { profile: 1, slowms: 200 }.
Suddenly, query profiles started showing up in MMS and the universe began to make sense. We discovered that our ODM was running a lot of searches on indexed fields (which is good) using regular expressions instead of strings (which is bad for speediness). Upon further investigation, we found that this was happening because we had used the ODM to assign certain case-insensitive validations to some of the data models in our code. We made the appropriate changes and saw our performance issues immediately disappear. Our users were happy again.
Post Mortem
Although it caused big problems, this turned out to be a simple error with a simple fix. If not for MMS, the discovery could have been very time-intensive and stressful. It simply did not occur to us that our case-insensitive validations would cause the ODM to build queries with regular expressions and thus result in mad-crazy performance issues. Thanks to MMS, we got a clear picture of what went wrong, and it led us to implement a more efficient solution that gives us the case-insensitive validations we need without running regex searches in MongoDB.
It’s widely accepted that enterprise level systems need good monitoring tools because of their size and complexity, but the same need is often overlooked in tech startups. In today’s ecosystem where everyone is standing on the shoulders of dozens of 3rd-party libraries/frameworks/whatever to build a simple app, it’s often difficult to deduce where things might be going wrong. More than ever, the small, lean tech startups need tools that give us good insight so we can optimize performance and solve problems without expending too many of the precious few resources that we have.
Takeaways
- Set up monitoring. Visibility into your operations and interpreting the data correctly is your lifeline. Set up some custom dashboards in MMS for at-a-glance views of key metrics.
- Load test. Then load test some more and watch the data. You will see strange and wonderful things that you never thought possible when you watch how your application and database operations perform under load. Try to discover and fix some of these things before you launch. Load testing can also inform you about what specific metrics you should pay close attention to for your particular application.
- Set up performance alerts. Once you have a pretty good idea of which metrics you need to pay attention to, create alerts for when these data points approach unacceptable levels.
- Set up basic alerts for your server configuration, e.g. a replication lag alert for your replica set.
- Strike a ninja-like offensive pose when you launch. You never know what will happen and must be ready with cat-like reflexes.
Learn more about Matchbook at matchbook.co. We’re currently hiring designers and developers, so feel free to drop us a line at jobs@matchbook.co for more info.
原文地址:Surviving Success at Matchbook: Using MMS To Track, 感谢原作者分享。

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

php中success方法是用於展示一個成功訊息,其使用語法是“Success('...','Http://www.xxx.com/Admin/User/Index');”,當我們沒有寫Url的時候,系統則會判斷有無上一頁,如果有系統,則會跳轉至上一頁,否則將不會進行跳轉。

在Laravel中,success方法用於在控制器中返回成功的回應。要使用success方法,我們需要在控制器中引入Response類,然後,可以使用該類別的實例來呼叫success方法。可以透過設定回應的訊息、需要傳回的資料、回應的狀態碼,並將這些參數傳遞給success方法,將會傳回一個成功的回應,其中包含了我們設定的訊息和使用者資料。

去年年底,特斯拉推出Model 3 Highland 更新後不久,美國聯邦電動車稅收獎勵規則發生了變化,由於特斯拉在新款M 中使用了中國磷酸鐵鋰電池,合格買家的潛在折扣減少了一半。

美國卡巴斯基防毒帳戶已出售給 Pango 集團旗下的 UltraAV。 Pango 最近從 Aura 剝離出來,Aura 是一家由執行長 Hari Ravichandran 創立的安全公司。卡巴斯基被禁後被迫放棄美國市場

迄今為止,三星 Galaxy S24 FE 已經出現在許多洩密和謠言中,所有這些都表明它將成為一款稱職的旗艦殺手,擁有更新的處理器、更大的顯示器和更多的 RAM。然而,OnLeaks 的新洩漏表明 S24 F

Gate.io交易所是全球領先的加密貨幣交易平台之一。本指南提供分步教程,幫助用戶註冊和使用Gate.io進行交易。註冊過程包括選擇註冊方式(電話、郵箱或社交賬號)、填寫信息、設置登錄密碼和完成身份認證。交易教程包括訪問交易頁面、選擇交易對、輸入交易信息、下單和查看訂單狀態。通過本文的指導,用戶可以輕鬆開始在Gate.io上進行加密貨幣交易。

學習PHP中success方法的最佳實踐,需要具體程式碼範例PHP是一種流行的伺服器端腳本語言,被廣泛應用於Web開發領域。在PHP中,success方法是一種常見的用於判斷操作成功與否的方法,通常用來傳回成功的訊息或程式碼。學習PHP中success方法的最佳實踐,需要結合實際的程式碼範例進行示範和解釋。首先,讓我們來看一個簡單的例子,展示一個成功的succes

以下手續費信息僅供參考,實際手續費可能會有所變化。在選擇數字貨幣交易所時,手續費是一個重要的考慮因素,但也需要綜合考慮交易所的安全性、流動性、交易品種等其他方面。
