Как	  сделать	  вычислительную	  инфраструктуру	  для	  большого	  кластера	                Евгений	  Кирпичёв	           ...
•  Введение	  и	  Архитектура	  •  Доставка	  задач/результатов	  •  Отладка	  и	  анализ	  •  Обобщение	  опыта:	  	     ...
Что	  мы	  строим	  •  Очень	  тяжелые	  вычисления	  (но	  очень	  параллельные)	  •  Много	  одновременных	  заданий	  (...
1	  задание	  (CreateJob)	  =	  	          Тьма	  маленьких	  задач	  (SubmitTask)	  Есть	  обратная	  связь	  (OnResult	 ...
Обычно	  (на	  суперкомпьютерах)	  используют:	  	     PlaGorm	  LSF	                            +	  	    MS	  HPC	  Serve...
Нам	  не	  подходит	  Они	  предполагают:	  •    Планировщик	  ничего	  не	  знает	  про	  задачу	       (Просто	  выделяе...
Пакетный	  планировщик	                                                    Наш	  планировщик	  Приложение:	               ...
Пример	  неудачной	  архитектуры	   Клиент	  1	     Клиент	  2	       Клиент	  3	                                 брокер	 ...
Более	  удачная	  архитектура	  •  Планировщик	                                                                   +клиенты...
Пример	  •    Клиент	  –	  Планировщику:	  	       Создай	  задачу	  A,	  важность	  30%	  •    Планировщик	  (выбирает	  ...
•  Введение	  и	  Архитектура	  •  Доставка	  задач/результатов	  •  Отладка	  и	  анализ	  •  Обобщение	  опыта:	  	     ...
Трубы	  •  На	  основе	  RabbitMQ	      –  Лучший	  продукт	  в	  своем	  классе	  (надежная	  доставка)	      –  Но	  «из...
Надежная	  доставка	  Цикл	  жизни	  демона:	  •  Получить	  задачу	  •  Посчитать	                                       ...
Демон	  A	  	                        вычисления	                               вычисле	                   Задача	  X	     ...
Масштабирование	  Из	  коробки	  RabbitMQ	  совсем	  не	  подходит	  •  Одна	  очередь	  плохо	  тянет	  10000	  клиентов	...
Масштабирование	          задачи	                        ответы	        Голова	  задачи	              Голова	  задачи	    ...
Трудности	  работы	  с	  очередями	  •    RabbitMQ	  под	  Windows	  тянет	  мало	  соединений	        –    Решено:	  кажд...
Сохранность	  данных	  при	  крахах	  RabbitMQ	                                                Publish	  confirmaƒons	     ...
Не	  перегружать	  RabbitMQ	  •  Если	  слишком	  интенсивно	  слать	  сообщения,	  	     RabbitMQ	  захлебнется	  (не	  у...
Не	  перегружать	  RabbitMQ	                        Белое	  –	  «ждем	  задачи»	                          доставка	  тормо...
Не	  перегружать	  RabbitMQ	  Оказывается,	  отличная	  метрика	  загрузки	  –	  	  число	  неподтвержденных	  сообщений	 ...
Не	  перегружать	  RabbitMQ	  Ограничить	  число	  сообщений	  «в	  полете»	      –  Ждать	  при	  roundrobin,	  пока	  те...
Поддерживать	  асинхронные	  прерывания	  Иногда	  надо	  всё	  бросить	  и	  заняться	  другим	  заданием	        –  Прер...
Переключаться	  между	  кроликами	  •  Если	  кончились	  задачи	  в	  нашем	  –	  постучаться	  в	  другого	  •  Если	  д...
Как	  это	  закодировать	  Можно	  сделать	  лапшу,	  делающую	  все	  сразу	      –  Реконнекты,	         подтверждения	 ...
Как	  не	  сойти	  с	  ума	  Разумеется,	  слои.	             	             	  
Слои	  Отсыльщик:	       –  Отослать	       –  Получить/сбросить	  список	  неподтвержденных	       –  Завершиться	  (возм...
Слои	          «Игнорировать	                                           «Балансировать	  отправку	  	          неподтвержд...
Например	                   задачи	                                                             ответы	              Сериа...
•    Введение	  и	  Архитектура	  •    Доставка	  задач/результатов	  •    Отладка	  и	  анализ	  •    Обобщение	  опыта:	...
Отладка	  и	  анализ	  •  Дебаггер	  –	  не	  вариант	  (только	  для	  локальных	  тестов)	  •  Проблемы	  тоже	  распред...
Пара	  фокусов	  в	  рукаве	  •  Мощный	  логгер	       –  Глобальная	  ось	  времени	  (точнее,	  чем	  NTP)	       –  Тя...
ƒmeplomers	  	  две	  специальных	  рисовалки	  	  A	  picture	  is	  worth	  a	  thousand	  words	         hšp://jkff.info...
http://jkff.info/software/timeplotters/
Что	  для	  этого	  нужно?	    Очень	  подробные	  логи.	     Еще	  об	  этом	  –	  позже.	  
•  Введение	  и	  Архитектура	  •  Доставка	  задач/результатов	  •  Отладка	  и	  анализ	  •  Обобщение	  опыта:	  	     ...
Корректность:	  Главный	  принцип	  Как	  писать	  правильный	  код?	  
Корректность:	  Главный	  принцип	         Код	  точно	  неправильный.	  	                   Как	  быть?	  
Как	  быть?	  •  Писать	  максимально	  подробные	  логи	  •  Писать	  меньше	  кода	       (только	  то,	  без	  чего	  п...
Барьеры	  Переводят	  любое	  состояние	  в	  предсказуемое.	  Уничтожение	  процесса	  (выполнение	  действия	  в	  отдел...
•  Введение	  и	  Архитектура	  •  Доставка	  задач/результатов	  •  Отладка	  и	  анализ	  •  Обобщение	  опыта:	  	     ...
Надежность	  •  Всё	  перезапускаемо	  и	  готово	  к	  перезапуску	  или	  смерти	  остальных	       –  Инфраструктурные	...
Перезапускаемость	  Если	  она	  есть:	  •    Можно	  перезапустить	  оборзевший	  процесс	  •    Можно	  навсегда	  забыт...
Асинхронные	  коммуникации	  •  С	  синхронными	  труднее	  обрабатывать	  ошибки,	     есть	  больше	  классов	  ошибок.	...
Eventual	  consistency	    Стремление	  к	  согласованности.	                         	  Строгая	  глобальная	  согласован...
Eventual	  consistency	                                     Publish	  confirma•ons	    Client	                             ...
Eventual	  consistency	   Scheduler	                   «Займись	  B»	         «Займись	  B»	                   «Занимаюсь	...
•  Введение	  и	  Архитектура	  •  Доставка	  задач/результатов	  •  Отладка	  и	  анализ	  •  Обобщение	  опыта:	  	     ...
Производительность	  Несколько	  аспектов:	  •  Стабильность	  под	  нагрузкой	  •  Пропускная	  способность	  •  Задержка...
Главное	         Ресурсы	  конечны	  	  
Что	  кончалось	  у	  нас	  Соединения	  с	  RabbitMQ	                                    Одновременные	  RPC-­‐вызовы	  E...
Мораль	  •  Планируйте	  потребление	  ресурсов	  •  Особенно	  таких,	  потребление	  которых	  растет	  с	  масштабом	  ...
Пропускная	  способность	                           	      Избегайте	  зависимости	  от	  обратной	  связи	               ...
Задержка	  •  Измеряйте	  •  Избегайте	  централизованных	  компонентов	  на	  пути	  запроса	  •  Не	  делите	  ресурсы	 ...
That’s	  all	  folks.	  Поставьте	  мне	  оценку	  :)	                                                          *	        ...
Upcoming SlideShare
Loading in …5
×

Как разработать вычислительную инфраструктуру для большого кластера

1,757 views

Published on

http://addconf.ru/event.sdf/ru/add_3/authors/EugeneKirpitchev/783

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,757
On SlideShare
0
From Embeds
0
Number of Embeds
529
Actions
Shares
0
Downloads
25
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Как разработать вычислительную инфраструктуру для большого кластера

  1. 1. Как  сделать  вычислительную  инфраструктуру  для  большого  кластера   Евгений  Кирпичёв   Станислав  Лагун  
  2. 2. •  Введение  и  Архитектура  •  Доставка  задач/результатов  •  Отладка  и  анализ  •  Обобщение  опыта:     корректность,  надежность,  производительность  
  3. 3. Что  мы  строим  •  Очень  тяжелые  вычисления  (но  очень  параллельные)  •  Много  одновременных  заданий  (Job)  и  юзеров  разной  важности  •  Простой  API  –  задание  =  поток  задач:  CreateJob,  SubmitTask,  OnResult   –  Задание  –  атомарное  и  stateless  однопоточное  вычисление     (напр.  перемножить  пару  матриц)  •  Непредсказуемые  вычисления:   От  секунд  (нужна  интерактивность)     до  дней  (но  не  мешать  чужой  интерактивности)  •  Задействовать  кластер  целиком  •  Отказоустойчивость  (смерть  вычислителей,  перезапуск  системных  сервисов)  
  4. 4. 1  задание  (CreateJob)  =     Тьма  маленьких  задач  (SubmitTask)  Есть  обратная  связь  (OnResult  =>  SubmitTask)   Legacy   API   app   Legacy   API   app   Legacy   API   app  
  5. 5. Обычно  (на  суперкомпьютерах)  используют:     PlaGorm  LSF   +     MS  HPC  Server   MPI   Oracle  Grid  Engine   OpenMP     Condor   …   …     Это  называется  «batch  scheduler»  
  6. 6. Нам  не  подходит  Они  предполагают:  •  Планировщик  ничего  не  знает  про  задачу   (Просто  выделяет  ядра)  •  Задачи  монолитны   •  «Мне  надо  100  ядер»   •  Как  появится  100  ядер  –  запустит   •  На  99  не  запустит  •  Есть  куча  сложных  правил  и  квот  •  Акцент  на  фичи,  а  не  на  эффективность  Без  этих  ограничений  можно  сделать  эффективнее.  Мы  знаем:  1)  задачи  прерываемы  2)  задачи  независимы  и  массивно  параллельны  
  7. 7. Пакетный  планировщик   Наш  планировщик  Приложение:   Приложение:   «Дай-­‐ка  мне  300  –  400  ядер  и  запусти  на   Я  хочу  использовать  кластер  для   них  вот  эту  команду»   вычисления  задач      Планировщик:   Планировщик:   Вот  ядра,  команду  запустил.     Хорошо,  кидай  задачи  сюда,  жди   Разбирайся  сам.   результатов  отсюда.  Я  позабочусь  об   эффективной  и  справедливой  делёжке   ресурсов.   Становятся  возможными  некоторые  трюки  для  повышения  утилизации.   But  this  margin  is  too  small  and  NDA  too  strict…  
  8. 8. Пример  неудачной  архитектуры   Клиент  1   Клиент  2   Клиент  3   брокер   Очевидно,  single  bomleneck  –  не  масштабируется   +балансировка  нагрузки  очень  математически  нестабильна  
  9. 9. Более  удачная  архитектура  •  Планировщик   +клиенты   –  Слушает  команды  о  запуске-­‐останове  заданий   +статистика   –  Приказывает  демонам  обслуживать  задачи  •  Трубы  (как  очереди,  только  шире)   +логгирование   –  Доставляют  задачи  и  ответы  •  Вычислительные  демоны  на  узлах   +мониторинг   –  Слушаются  планировщика   –  Тянут  из  труб  задач,  считают,  публикуют  ответы  
  10. 10. Пример  •  Клиент  –  Планировщику:     Создай  задачу  A,  важность  30%  •  Планировщик  (выбирает  несколько  демонов)  –  демонам:   Ты,  ты  и  ты  –  бросайте  всё  и  подключайтесь  к  трубе  А.   (возможно  вытеснение  работающей  задачи)  •  Клиент  шлет  задачи  в  трубу  А  •  Демоны  считают,  шлют  ответы  •  Клиент  собирает  ответы,  шлет  новые  задачи  и  т.п.  
  11. 11. •  Введение  и  Архитектура  •  Доставка  задач/результатов  •  Отладка  и  анализ  •  Обобщение  опыта:     корректность,  надежность,  производительность  
  12. 12. Трубы  •  На  основе  RabbitMQ   –  Лучший  продукт  в  своем  классе  (надежная  доставка)   –  Но  «из  коробки»  сам  по  себе  не  масштабируется  
  13. 13. Надежная  доставка  Цикл  жизни  демона:  •  Получить  задачу  •  Посчитать   Порядок  очень  важен  •  Отослать  ответ  •  Подтвердить  получение  задачи  
  14. 14. Демон  A     вычисления   вычисле   Задача  X   «Подтверждаю:   Задача  Y   Разрыв  связи   задачу  X  получил»   Демон  B     Задача  Y  RabbitMQ   Ждет  подтверждения  X   Ждет  Y   Ждет  Y  
  15. 15. Масштабирование  Из  коробки  RabbitMQ  совсем  не  подходит  •  Одна  очередь  плохо  тянет  10000  клиентов  •  Встроенная  кластеризация  делает  не  то   От  нее  вообще  лучше  отказаться  (одни  проблемы)  •  Очевидное  решение:  несколько  очередей  +  load  balancing  
  16. 16. Масштабирование   задачи   ответы   Голова  задачи   Голова  задачи   Демон  выбирает  случайного  кролика  (подбираются  демонами)   (отсылаются  демонами)   и  всю  жизнь*  работает  с  ним  
  17. 17. Трудности  работы  с  очередями  •  RabbitMQ  под  Windows  тянет  мало  соединений   –  Решено:  каждая  машина  подключается  к  кому-­‐нибудь  одному  •  При  крахах  демонов  данные  теряются   –  Решено:  подтверждения  тасков  •  При  крахах  RabbitMQ  данные  теряются   –  RabbitMQ  не  гарантирует  безопасность  данных  вне  транзакции!  •  Соединение  может  спонтанно  рваться  •  RabbitMQ  дохнет  под  нагрузкой   –  Надо  избегать  перегрузки  •  Нужно  мгновенное  переключение  между  заданиями  (бросай  всё  и  берись  за  задачу  А)   –  Самая  сложная  часть  •  В  очереди  на  конкретном  RabbitMQ  могут  кончиться  задачи   –  Надо  переключаться,  не  нарушая  остальных  свойств  
  18. 18. Сохранность  данных  при  крахах  RabbitMQ   Publish  confirmaƒons   Client   0..3   4..5   6..7   RabbitMQ   fsync   fsync   fsync   Disk   Клиент  помнит  сообщения,  про  которые  еще  не  известно,  на  диске  ли  они.   При  разрыве  связи  перепосылает  их.   Это  универсальный  паттерн  в  распределенных  системах  (stream  replica•on).  
  19. 19. Не  перегружать  RabbitMQ  •  Если  слишком  интенсивно  слать  сообщения,     RabbitMQ  захлебнется  (не  успевая  писать  на  диск)  •  Тормоза,  крахи,  разрывы  соединений  
  20. 20. Не  перегружать  RabbitMQ   Белое  –  «ждем  задачи»   доставка  тормозит,     или  реконнектимся  
  21. 21. Не  перегружать  RabbitMQ  Оказывается,  отличная  метрика  загрузки  –    число  неподтвержденных  сообщений   4  задания,  4  разноцветных  кролика   Один  кролик  не  поспевает.  
  22. 22. Не  перегружать  RabbitMQ  Ограничить  число  сообщений  «в  полете»   –  Ждать  при  roundrobin,  пока  текущему  кролику  полегчает?   –  Нет,  тогда  один  медленный  будет  всех  тормозить.   –  А  как  тогда?   –  Давать  очередное  сообщение  случайному  неперегруженному.  
  23. 23. Поддерживать  асинхронные  прерывания  Иногда  надо  всё  бросить  и  заняться  другим  заданием   –  Прервать  запущенную  задачу  и  кинуть  обратно  в  трубу   –  Или  прервать  ожидание  завершения  задачи   –  Порвать  соединения  с  трубами  предыдущего  задания   •  Убедиться,  что  все  ответы  точно  сохранены  на  диск  Об  этом  мы  узнаем  из  другого  потока   –  Многопоточность  –  это  всегда  ад   –  К  счастью,  это  почти  единственное  использование  многопоточности   –  Но  все  равно  ад   –  На  5000  ядрах  быстро  проявляются  ВСЕ  многопоточные  баги  
  24. 24. Переключаться  между  кроликами  •  Если  кончились  задачи  в  нашем  –  постучаться  в  другого  •  Если  делать  наивно,  будет  куча  проблем   –  Бури  реконнектов   –  Голодание   –  Дисбаланс   –  Кончатся  соединения   –  ...   –  NO  PROFIT!!!11  
  25. 25. Как  это  закодировать  Можно  сделать  лапшу,  делающую  все  сразу   –  Реконнекты,   подтверждения     доставки,   переключение,     балансировка,   асинхронные   прерывания…  
  26. 26. Как  не  сойти  с  ума  Разумеется,  слои.      
  27. 27. Слои  Отсыльщик:   –  Отослать   –  Получить/сбросить  список  неподтвержденных   –  Завершиться  (возможно,  асинхронно)  Слушатель:   –  Достать  сейчас  (blocking  +  •meout)   –  Достать  потом  (callback)   –  Завершиться  (возможно,  асинхронно)  
  28. 28. Слои   «Игнорировать   «Балансировать  отправку     неподтвержденные     между  несколькими»   при  закрытии»   «При  ошибке  переоткрыться»  «Слушать  сразу  несколько»   «Преобразовать  тип     сообщения»   «При  ошибке  сделать     «При  ошибке     то-­‐то  и  то-­‐то»   попробовать  еще  раз»  
  29. 29. Например   задачи   ответы   Сериализовать   Десериализовать  При  ошибке  повторять  до  успеха   При  ошибке  повторять  до  успеха   При  ошибке  залоггировать   При  ошибке  залоггировать   При  ошибке  переоткрыть   При  ошибке  переоткрыть  (неподтвержденное  переслать)   Слушать  сразу  несколько   Балансировать   По  числу     Неограниченная  предвыборка   Слать  в  RabbitMQ   кроликов   Слушать  из  RabbitMQ  
  30. 30. •  Введение  и  Архитектура  •  Доставка  задач/результатов  •  Отладка  и  анализ  •  Обобщение  опыта:     корректность,  надежность,  производительность  
  31. 31. Отладка  и  анализ  •  Дебаггер  –  не  вариант  (только  для  локальных  тестов)  •  Проблемы  тоже  распределенные   –  Особенно  проблемы  производительности  •  Post  mortem  отладка  по  логам  •  Логов,  по  нашим  меркам,  дох  очень  много   (тысячи  важных  сообщений  в  сек.,  в  пике  до  сотен  тысяч)  
  32. 32. Пара  фокусов  в  рукаве  •  Мощный  логгер   –  Глобальная  ось  времени  (точнее,  чем  NTP)   –  Тянет  сотни  тысяч  сообщений  в  секунду  от  тысяч  клиентов   –  hšp://code.google.com/p/greg  –  опенсорс-­‐версия   –  Ставим  1шт.  на  кластер,  получаем  точную  глобальную  картину   (без  мучений  со  специальным  сбором-­‐слиянием  логов)  •  GNU  textu•ls  +  awk  
  33. 33. ƒmeplomers    две  специальных  рисовалки    A  picture  is  worth  a  thousand  words   hšp://jkff.info/so¡ware/•meplošers/  
  34. 34. http://jkff.info/software/timeplotters/
  35. 35. Что  для  этого  нужно?   Очень  подробные  логи.   Еще  об  этом  –  позже.  
  36. 36. •  Введение  и  Архитектура  •  Доставка  задач/результатов  •  Отладка  и  анализ  •  Обобщение  опыта:     корректность,  надежность,  производительность  
  37. 37. Корректность:  Главный  принцип  Как  писать  правильный  код?  
  38. 38. Корректность:  Главный  принцип   Код  точно  неправильный.     Как  быть?  
  39. 39. Как  быть?  •  Писать  максимально  подробные  логи  •  Писать  меньше  кода   (только  то,  без  чего  программа  не  будет  работать)  •  Минимизировать  «ядро  корректности»  •  Избегать  многопоточности  и  других  опасных  приемов   (никакого  геройства)  •  Использовать  eventual  consistency     (не  настаивать  на  strong  consistency)  •  Использовать  «барьеры»    
  40. 40. Барьеры  Переводят  любое  состояние  в  предсказуемое.  Уничтожение  процесса  (выполнение  действия  в  отдельном  процессе)  •  Защищает  от  утечек  ресурсов  внутри  процесса  Периодический  перезапуск  системы  •  Защищает  от  неограниченно  долгих  зависаний  Закрытие  соединения  с  очередью  •  В  худшем  случае  (неподтвержденная)задача  будет  сдублирована  
  41. 41. •  Введение  и  Архитектура  •  Доставка  задач/результатов  •  Отладка  и  анализ  •  Обобщение  опыта:     корректность,  надежность,  производительность  
  42. 42. Надежность  •  Всё  перезапускаемо  и  готово  к  перезапуску  или  смерти  остальных   –  Инфраструктурные  сервисы  реплицируют  состояние  и  выбирают  «лидера»  •  Только  асинхронная  коммуникация  •  Все  компоненты  готовы  к  дублям  и  потерям  сообщений  •  Явно  формулировать  переход  ответственности  за  целостность  данных  •  Eventual  consistency     (система  не  обязана  быть  согласованной  постоянно)  
  43. 43. Перезапускаемость  Если  она  есть:  •  Можно  перезапустить  оборзевший  процесс  •  Можно  навсегда  забыть  о  редких  крахах  •  Можно  перезапускать  процесс  периодически  и  забыть  навсегда  об  утечках  и   зависаниях  Если  ее  нет:  •  Надо  вылизывать  код,  пока  не  исчезнут  самые  маловероятные  крахи  и  утечки  •  Если  крах  не  по  вашей  вине  (ОС,  библиотека,  железо,  уборщица)  –     это  все  равно  ваши  проблемы.  
  44. 44. Асинхронные  коммуникации  •  С  синхронными  труднее  обрабатывать  ошибки,   есть  больше  классов  ошибок.  •  Можно  использовать  софт,  хорошо  разбирающийся   в  асинхронных  коммуникациях.  •  Лучше  использовать  connec•onless  протоколы  (UDP):   исчезает  как  класс  проблема  «разрыв  связи».   (если  задача  позволяет)  
  45. 45. Eventual  consistency   Стремление  к  согласованности.    Строгая  глобальная  согласованность   трудна     далеко  не  всегда  нужна     и  далеко  не  всегда  возможна  
  46. 46. Eventual  consistency   Publish  confirma•ons   Client   0..3   4..5   6..7  RabbitMQ   fsync   fsync   fsync   Disk   Клиент  и  кролик  постепенно  согласуют  знание  о  том,     какие  данные  надежно  сохранены  
  47. 47. Eventual  consistency   Scheduler   «Займись  B»   «Займись  B»   «Занимаюсь  A»   «Занимаюсь  B»   Daemon  Планировщик  и  тысячи  демонов  постепенно  согласуют  представление     о  том,  чем  демонам  надо  заниматься  
  48. 48. •  Введение  и  Архитектура  •  Доставка  задач/результатов  •  Отладка  и  анализ  •  Обобщение  опыта:     корректность,  надежность,  производительность  
  49. 49. Производительность  Несколько  аспектов:  •  Стабильность  под  нагрузкой  •  Пропускная  способность  •  Задержка  
  50. 50. Главное   Ресурсы  конечны    
  51. 51. Что  кончалось  у  нас  Соединения  с  RabbitMQ   Одновременные  RPC-­‐вызовы  Erlang-­‐процессы  в  RabbitMQ   Место  на  диске  Cинхронные  AMQP-­‐операции  /  сек.  (e.g.   CPU  и  диск  машины,  куда  погрузили  два  сервиса  сразу  queue.declare)   Успешные  UDP-­‐пакеты  по  нагруженному  каналу  Установленные  соединения  /  сек.  с  RabbitMQ   Транзакции  RabbitMQ  в  секунду  /  в  минуту  Установленные  соединения  /  сек.  с  логгером   Терпение  при  анализе  больших  логов  Внутренние  буферы  сообщений  в  логгере   Память  у  инструментов  рисования  логов    Место  в  пуле  потоков  (медленно  разгребался)      
  52. 52. Мораль  •  Планируйте  потребление  ресурсов  •  Особенно  таких,  потребление  которых  растет  с  масштабом  •  Особенно  централизованных  (в  т.ч.  сеть)  •  Учитывайте  характер  нагрузки!   –  Его  бывает  трудно  предсказать   –  Наивные  бенчмарки  нерепрезентативны  
  53. 53. Пропускная  способность     Избегайте  зависимости  от  обратной  связи    Иначе  задержка  начинает  уменьшать  пропускную  способность   (печальный  пример  –  TCP)   Задержку  оптимизировать  гораздо  труднее    
  54. 54. Задержка  •  Измеряйте  •  Избегайте  централизованных  компонентов  на  пути  запроса  •  Не  делите  ресурсы  между  batch  и  real-­‐•me  компонентами  •  Рано  или  поздно  придется  управлять  приоритетами  запросов/ действий  вручную     –  Понадобятся  не  просто  очереди,  а  приоритетные  очереди  
  55. 55. That’s  all  folks.  Поставьте  мне  оценку  :)   *   *  Это  не  наше,  но  похоже.  

×