Що ми робимо · Storage та обчислювальні ресурси: Інженерія продуктивності та ємності
Більшості повільних платформ не потрібно більше обладнання. Їм потрібен хтось, хто знайде ту єдину річ, яка їх насправді стримує. Ми вимірюємо справжнє вузьке місце, змінюємо одну річ і вимірюємо знову, і більшість наших найбільших перемог прийшли з однієї перевіреної зміни, а не із замовлення на закупівлю.
Що це
Інженерна практика, яка зв’язує наші обчислення, сховище та мережу докупи. Коли навантаженню потрібно більше ємності, ми кажемо вам, який саме ресурс і чому.
Як ми це будуємо
Правила, застосовані до кожного build. Деякі перемоги надто надійні, щоб залишати їх на волю випадку, тож вони є постійними правилами на кожному сервері та VM, які ми передаємо:
- VM, розміщені в межах одного сокета. Ніколи не більше vCPU, ніж ядер має один фізичний сокет, ніколи не більше пам’яті, ніж обслуговує один вузол NUMA. За цією межею доступ до пам’яті стає віддаленим із затримкою приблизно в 1,7 раза більшою за локальну, і штраф накопичується, тож більша VM часто виявляється повільнішою.
- Bond, що використовують обидва з’єднання. Хешування за IP-адресами та портами, узгоджене з боком комутатора, тож кожен член bond несе трафік.
- Flash, до якого ставляться як до flash. Апаратний RAID може приховати те, що том є твердотільним, тож ми зчитуємо тип носія з дисків і встановлюємо планувальник, read ahead та глибину черги відповідно.
- Бази даних отримують свою пам’ять. Buffer pool, розміровані під working set.
- Жодного swap на VM. Нестачу пам’яті вирішують пам’яттю або виправленням у застосунку, ніколи виштовхуванням її на сховище.
Вимірювання на кожному рівні. I/O на кожен том на масивах, лічильники на кожен порт на bond і комутаторах, журнали запитів та повільних запитів на базах даних, вимірювання часу ззовні через CDN, живлення на стійку та на фазу.
Від чого це вас захищає
- Від оплати ємності, яку марнувало типове налаштування конфігурації.
- Від купівлі обладнання для проблеми, яка насправді є проблемою налаштування.
- Від більшої VM, що працює повільніше за меншу, яку вона замінила.
- Від половини вашої пропускної здатності мережі, що простоює.
- Від flash-сховища, що витрачає свій ресурс на читання, які база даних мала б кешувати.
На практиці
Edge видавця, доведений під навантаженням. Перед запуском в Афінах рівень кешування видавця побудували як два шари, пам’ять перед flash на SAN, і випробували навантаженням у двадцять тисяч віртуальних користувачів. Він витримав, і цей дизайн став нашим стандартом для платформ видавців.
Чому EuroVPS
- Ми вимірюємо, перш ніж продавати, і відповіддю часто є зміна, а не оновлення.
- Постійні правила налаштування, застосовані до кожного build, а не на запит.
- Рекомендації, які кажуть, який ресурс, скільки і чому.
Часті запитання
- Мій сайт повільний. Мені потрібен більший сервер? Можливо, але спершу ми виміряємо. Часто відповідь у конфігурації, кешуванні чи запиті, і ми покажемо вам докази в будь-якому разі.
- Чому ви не дасте моїй VM більше ядер? За межею одного сокета додаткові ядра додають затримку віддаленої пам’яті. Ми підбираємо розмір під сокет, і це зазвичай швидше.
- Чи налаштовуєте ви застосунки клієнтів? Ми налаштовуємо все, що експлуатуємо, і консультуємо щодо того, що експлуатуєте ви: пам’ять баз даних, кількість worker, рівні кешування, запити. Там, де виправлення у вашому коді, ми скажемо вам точно де.
- Це окрема послуга? Це те, як ми працюємо на кожній платформі, якою керуємо. Також доступні окремі аудити продуктивності з письмовим звітом до і після.
- closing line: Швидше зазвичай починається з вимірювання, а не з рахунку. Поговоріть з інженером про те, що насправді вас уповільнює.
- CTA: Поговоріть з інженером
Ваш наступний партнер з інфраструктури
Погляньмо на вашу інфраструктуру.
Розкажіть, що ви запускаєте сьогодні і що потребує покращення. Інженер розгляне ваш запит і допоможе спланувати наступний крок.
+357 222 32280
Почнімо з вашої інфраструктури.
Трохи контексту допомагає нам почати правильну розмову.