Яка затримка в центрі обробки даних? Я запитую це, припускаючи, що є порядки різниці

Я намагаюся з'ясувати щось, на що я просто не можу знайти хорошої відповіді.

Якщо я скажу кеш REDIS (або якийсь зовнішній кеш пам'яті), що сидить у центрі обробки даних, і сервер додатків, що сидять у тому ж центрі обробки даних, яка буде швидкість мережевого з'єднання (затримка, пропускна здатність) для зчитування даних між цими двома машинами?

Чи буде, наприклад, мережа "швидкості", як мінімум, на порядок вище, ніж швидкість ОЗУ, яка шукає мої дані з кешу на REDIS?

Моє остаточне питання - чи це все, що сидить у пам'яті на REDIS, насправді забезпечує будь-яку корисність? Суперечить тому, чи замість цього REDIS кешував це все на SSD? Пам'ять дорога. Якщо мережа справді не є вузьким місцем у центрі обробки даних, то пам'ять має значення. Інакше це не так.

Я думаю, моє загальне запитання, незважаючи на велику невідомість у центрах обробки даних та неможливість узагальнити, а також відхилення, чи ми говоримо про достатній порядок між затримкою пам’яті в комп'ютерній системі та навіть найкращими мережами, що працюють в постійному тоці, що пам'ять скорочені затримки не забезпечують значного покращення продуктивності? Я розумію, що існує багато змінних, але наскільки це близько? Це так близько, що ці змінні мають значення? Наприклад, прийміть гіперболічну позицію щодо нього, магнітофон є НАЙЧАК повільнішим, ніж мережевий, тому стрічка не ідеальна для кешу.

Існує кілька версій "графіків затримки, які кожен повинен знати", таких як:

• https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html
• https://gist.github.com/jboner/2841832
• https://computers-are-fast.github.io/

Справа в тому, що насправді існує більше, ніж просто затримка. Це поєднання факторів.

Отже, яка затримка мережі в центрі обробки даних? Затримка, я б сказав, що це "завжди" нижче 1 мс. Це швидше оперативної пам'яті? Ні. Це близько до оперативної пам'яті? Я не думаю, що так.

Але питання залишається, чи це актуально. Це дата, яку ви повинні знати? Ваше питання має для мене сенс. Оскільки все має вартість, якщо ви отримаєте більше оперативної пам’яті, щоб усі дані могли залишатися в оперативній пам’яті або нормально час від часу читати з диска.

Ваше «припущення» полягає в тому, що якщо затримка в мережі буде вищою (повільнішою), ніж швидкість SSD, ви не будете отримувати всі дані в оперативній пам’яті, оскільки у вас буде повільна мережа.

І, здавалося б, так. Але, ви також повинні враховувати паралельність. Якщо ви отримуєте 1000 запитів на дані одночасно, чи може диск виконати 1000 одночасних запитів? Звичайно, ні, так скільки часу буде потрібно для задоволення цих 1000 запитів? Порівняно з оперативною пам’яттю?

Важко звести це до одного фактора, наприклад, великих навантажень. Але так, якби у вас була одна операція, затримка мережі така, що ви, мабуть, не помітили різниці SSD від оперативної пам'яті.

Як і до появи на ринку диска 12 Гбіт / с, мережеве посилання 10 Гбіт / с не буде перевантажено одним потоком, оскільки диск був вузьким місцем.

Але пам’ятайте, що ваш диск виконує багато інших речей, ваш процес - не єдиний процес на машині, ваша мережа може переносити різні речі тощо.

Крім того, не всі дискові дії означають мережевий трафік. Запит на базу даних, що надходить з програми на сервер бази даних, становить лише дуже мінімальний мережевий трафік. Відповідь сервера баз даних може бути дуже маленькою (єдине число) або дуже великою (тисяча рядків з кількома полями). Для виконання операції серверу (сервер бази даних чи ні) може знадобитися кілька запитів, читання та запису диска, але лише надсилає дуже невеликий біт назад по мережі. Це, безумовно, не одна-на-одну мережевий диск-ОЗУ.

Поки я уникав деяких деталей вашого питання - зокрема, частини Redis.

Redis - це відкритий код (ліцензований BSD), зберігання структури даних в пам'яті, який використовується як база даних, кеш-пам'ять та брокер повідомлень. - https://redis.io/

Гаразд, так що це означає, що все в пам’яті. На жаль, цей швидкий SSD-диск тут вам не допоможе. Redis може зберігати дані на диску, тому він може бути завантажений в оперативну пам'ять після перезавантаження. Це лише для того, щоб не "втратити" дані або доведеться перенаселити холодний кеш після перезавантаження. Тож у цьому випадку вам доведеться використовувати ОЗУ, незважаючи ні на що. Вам потрібно буде мати достатню кількість оперативної пам’яті, щоб містити набір даних. Не вистачає оперативної пам’яті, і я думаю, що ваша ОС буде використовувати swap- напевно, це не дуже гарна ідея.

У комп’ютерних системах є багато шарів кешу. Вставлення його на рівні додатків може бути корисним, кешування API та запитів до бази даних. І, можливо, тимчасові дані, наприклад сеанси користувачів.

Сховища даних, такі як Redis, надають таку послугу через мережевий (швидкий) або UNIX-сокет (навіть швидше), як би ви використовували базу даних.

Вам потрібно виміряти, як саме працює ваша програма, але давайте складемо приклад. Скажімо, звичайний запит користувача робить 5 запитів API, що займають 50 мс кожен. 250 мс - затримка, яку можна визначити користувачем. На відміну від кешування результатів. Навіть якщо кеш-пам'ять знаходиться в іншій зоні доступності по всьому місту (не оптимально), звернення, мабуть, не більше 10 мс. Що було б 5-кратним прискоренням.

Насправді база даних та системи зберігання також мають свої кеші. Однак, як правило, швидше отримати заздалегідь отриманий результат, ніж знову пройти через двигун бази даних та рівні системи зберігання. Крім того, шар кешування може зняти значне завантаження бази даних за ним.

Для прикладу такого кешу у виробництві шукайте не далі, ніж інфраструктурний блог Stack Overflow про архітектуру . Сотні тисяч запитів HTTP генерують мільярди звернень Redis досить важливо.

Пам'ять дорога.

DRAM за 100 нс часу доступу приблизно в 100 разів швидше, ніж твердотільне постійне зберігання. Це порівняно недорого для цієї вистави. Для багатьох застосувань трохи більше оперативної пам'яті купує цінну швидкість і час відгуку.