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, 感谢原作者分享。

MySQL在數據庫和編程中的地位非常重要,它是一個開源的關係型數據庫管理系統,廣泛應用於各種應用場景。 1)MySQL提供高效的數據存儲、組織和檢索功能,支持Web、移動和企業級系統。 2)它使用客戶端-服務器架構,支持多種存儲引擎和索引優化。 3)基本用法包括創建表和插入數據,高級用法涉及多表JOIN和復雜查詢。 4)常見問題如SQL語法錯誤和性能問題可以通過EXPLAIN命令和慢查詢日誌調試。 5)性能優化方法包括合理使用索引、優化查詢和使用緩存,最佳實踐包括使用事務和PreparedStatemen

MySQL適合小型和大型企業。 1)小型企業可使用MySQL進行基本數據管理,如存儲客戶信息。 2)大型企業可利用MySQL處理海量數據和復雜業務邏輯,優化查詢性能和事務處理。

InnoDB通過Next-KeyLocking機制有效防止幻讀。 1)Next-KeyLocking結合行鎖和間隙鎖,鎖定記錄及其間隙,防止新記錄插入。 2)在實際應用中,通過優化查詢和調整隔離級別,可以減少鎖競爭,提高並發性能。

MySQL不是一門編程語言,但其查詢語言SQL具備編程語言的特性:1.SQL支持條件判斷、循環和變量操作;2.通過存儲過程、觸發器和函數,用戶可以在數據庫中執行複雜邏輯操作。

MySQL是一種開源的關係型數據庫管理系統,主要用於快速、可靠地存儲和檢索數據。其工作原理包括客戶端請求、查詢解析、執行查詢和返回結果。使用示例包括創建表、插入和查詢數據,以及高級功能如JOIN操作。常見錯誤涉及SQL語法、數據類型和權限問題,優化建議包括使用索引、優化查詢和分錶分區。

MySQL是一個開源的關係型數據庫管理系統,適用於數據存儲、管理、查詢和安全。 1.它支持多種操作系統,廣泛應用於Web應用等領域。 2.通過客戶端-服務器架構和不同存儲引擎,MySQL高效處理數據。 3.基本用法包括創建數據庫和表,插入、查詢和更新數據。 4.高級用法涉及復雜查詢和存儲過程。 5.常見錯誤可通過EXPLAIN語句調試。 6.性能優化包括合理使用索引和優化查詢語句。

選擇MySQL的原因是其性能、可靠性、易用性和社區支持。 1.MySQL提供高效的數據存儲和檢索功能,支持多種數據類型和高級查詢操作。 2.採用客戶端-服務器架構和多種存儲引擎,支持事務和查詢優化。 3.易於使用,支持多種操作系統和編程語言。 4.擁有強大的社區支持,提供豐富的資源和解決方案。

InnoDB的鎖機制包括共享鎖、排他鎖、意向鎖、記錄鎖、間隙鎖和下一個鍵鎖。 1.共享鎖允許事務讀取數據而不阻止其他事務讀取。 2.排他鎖阻止其他事務讀取和修改數據。 3.意向鎖優化鎖效率。 4.記錄鎖鎖定索引記錄。 5.間隙鎖鎖定索引記錄間隙。 6.下一個鍵鎖是記錄鎖和間隙鎖的組合,確保數據一致性。


熱AI工具

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

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

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

AI Hentai Generator
免費產生 AI 無盡。

熱門文章

熱工具

VSCode Windows 64位元 下載
微軟推出的免費、功能強大的一款IDE編輯器

SublimeText3 Linux新版
SublimeText3 Linux最新版

ZendStudio 13.5.1 Mac
強大的PHP整合開發環境

SublimeText3 英文版
推薦:為Win版本,支援程式碼提示!

Atom編輯器mac版下載
最受歡迎的的開源編輯器