Да, я неточно написал. У нас на самом деле смешанная нагрузка: есть как ввод-вывод при походах на бэкенды, так и вычислительная нагрузка при сериализации, десериализации и бизнес-логике.
У нас бывают случаи, когда нужно сделать несколько параллельных запросов к разным бэкендам. В этом случае мы отправляем запросы асинхронно, получаем CompletableFuture, комбинируем их в одну, блочимся, а дальше опять работаем в синхронном стиле.
Но мы стараемся не отправлять N параллельных запросов, то есть стараемся не делать запросов в цикле, иначе можно одним запросом положить несолько бэкендов :-)
Например, этот background процесс может записать данные в промежуточный буфер, найти socket, в который нужно записать эти данные, и создать задание по асинхронной записи данных из промежуточного буфера в этот socket. Heinz Kabutz неплохо рассказывает как это происходит в java на низком уровне. Но обычно на таком низком уровне никто не работает, а используют более высокоуровневые библиотеки, например Netty. Это как раз асинхронный неблокирующий ввод-вывод, и в этой задаче он оправдан.
Если взять такой цикл запроса: вычитывание запроса из сокета -> походы по бэкендам для формирования результата -> записть результата в сокет, то только этап походов по бэкендам у нас блокирующийся. Вычитываение запроса и запись результата в сокет по-прежнему происходят без блокировки с помощью селекторов. В селекторе можно зарегистрировать тысячи сокетов, а выделять тред только тогда, когда в сокете появятся данные. Поэтому с пушами необязательно выделять тред под коннект.
По поводу проблем нехватки тредов в будущем.
При расчетах я заложил увеличение нагрузки в 2 раза и все равно получил, что 600 тредов на сервер нам вполне хватит.
Не хватит — сделаем 1000, 2000, 4000 тредов.
Но, на самом деле, мы раньше упремся в CPU из-за десериализации ответов от бэкендов, чем в нехватку тредов.
Уход от асинхронного кода не был основной мотивацией. Когда мы выбирали, как писать logic на java, мы рассматривали как асинхронные, так и синхронные варианты. Нам понравился синхронный варинат, потому это просто, понятно и не создает существенных проблем при нашем профиле нагрузки. О каком ворохе проблем мы забыли?
Хорошее замечание.
В тесте я хотел показать, что накладные расходы на переключение между контектами потоков — не проблема при нашем профиле нагрузки.
Проблема синхронизации на общих ресурсах — отдельная проблема.
Но у нас запросы достаточно независимы. Они делят не так много общих ресурсов. Клиент для похода по бэкендам, например. Однако большую часть времени потоки проводят в блокировке ожидания ответа от бэкенда, так что рассчитываем, что проблему синхронизации на общих ресурсах мы не заметим.
От Tortik мы оказались в пользу Frontik.
Frontikи у нас выступают в качестве фронтовых серверов, которые занимаются шаблонизацией.
Им разрешено ходить по бэкендам, но только параллельно.
Как только при походах на бэкенды появляется последовательная логика, например "после похода на бэкенд 1 проверь ответ и реши, стоит ли ходить на бэкенд 2", тогда эта логика выносится в отдельный слой, который мы называем logic.
Мы выделили этот слой, чтобы переиспользовать логику для основной версии сайта, мобильной версии сайта и api.
Изначально python logic был написан на Frontik. Теперь мы переписываем его на java.
Я пытался сразу устроиться в софтверную компанию. Никому я без опыта был не нужен. Зато поступил в школу hh, а потом попал в сам hh. Кажется, что получаю опыта больше, чем во многих софтверных компаниях :-)
Не забывайте в регламентные задания SQL Server добавлять бэкап transaction лога.
Во-первых, это позволяет восстанавливать базу на любой момент времени.
Во-вторых, без бэкапа transaction лог будет все время расти.
Ну или ставьте базу в режим восстановления simple :-)
Пока не очень понятно как Canonical будет позиционировать свою систему.
Чем их система качественно лучше уже существующих?
Еще одна альтернатива Android рынку, имхо, не нужна.
Вот если они смогут выделить действительно яркую фишку…
Я тоже люблю мини-ТЗ: конкретная небольшая проблема, описание предполагаемого решения, бюджетец и срок.
Позволяет часто радовать заказчика решением наиболее важных проблем и гибко менять требования по ходу развития системы.
Но часто бывает так, что заказчик хочет понять стоимость всей системы.
Тогда без полноценного ТЗ не обойтись, иначе как оценить то, что еще не формализовано?
ТЗ — не только инструмент разрешения конфликтов между заказчиком и исполнителем.
Это еще и способ прогнозирования затрат, ведь бизнесу часто требуется не просто реализация проекта: ему требуется понимать сроки и бюджеты, чтобы оценить эффективность вложения денег.
А более-менее точные сроки и бюджеты невозможно дать без предварительной формализации работ в виде ТЗ.
Кроме того, ТЗ — это еще и способ организации работ программистов. Часто бывает удобно обсудить проект с заказчикам и сделать ТЗ, чтобы быстро передать формализованную задачу программистам.
Но я полноценные большие ТЗ не очень люблю: слишком негибко получается :-)
Лучше разбивать проект на как можно более мелкие составляющие и двигаться к достижению целей итерациями.
Почему были созданы все эти жуткие монстры с кошмарным интерфейсом, которые истязают своих пользователей, изводят своих создателей и никак не хотят расстаться с жизнью по хорошему? Почему были созданы эти сотни простых как грабли тулов, которые делают одно и то же, отличаясь цветовой гаммой, платформой, и дизайном формы логина?
Потому что 90% всего — это барахло, в полном соответствии с законом Старджона :-)
Но мы стараемся не отправлять N параллельных запросов, то есть стараемся не делать запросов в цикле, иначе можно одним запросом положить несолько бэкендов :-)
По поводу проблем нехватки тредов в будущем.
При расчетах я заложил увеличение нагрузки в 2 раза и все равно получил, что 600 тредов на сервер нам вполне хватит.
Не хватит — сделаем 1000, 2000, 4000 тредов.
Но, на самом деле, мы раньше упремся в CPU из-за десериализации ответов от бэкендов, чем в нехватку тредов.
В тесте я хотел показать, что накладные расходы на переключение между контектами потоков — не проблема при нашем профиле нагрузки.
Проблема синхронизации на общих ресурсах — отдельная проблема.
Но у нас запросы достаточно независимы. Они делят не так много общих ресурсов. Клиент для похода по бэкендам, например. Однако большую часть времени потоки проводят в блокировке ожидания ответа от бэкенда, так что рассчитываем, что проблему синхронизации на общих ресурсах мы не заметим.
Frontikи у нас выступают в качестве фронтовых серверов, которые занимаются шаблонизацией.
Им разрешено ходить по бэкендам, но только параллельно.
Как только при походах на бэкенды появляется последовательная логика, например "после похода на бэкенд 1 проверь ответ и реши, стоит ли ходить на бэкенд 2", тогда эта логика выносится в отдельный слой, который мы называем logic.
Мы выделили этот слой, чтобы переиспользовать логику для основной версии сайта, мобильной версии сайта и api.
Изначально python logic был написан на Frontik. Теперь мы переписываем его на java.
Во-первых, это позволяет восстанавливать базу на любой момент времени.
Во-вторых, без бэкапа transaction лог будет все время расти.
Ну или ставьте базу в режим восстановления simple :-)
Эта информация с последнего всероссийского семинара партнеров.
Чем их система качественно лучше уже существующих?
Еще одна альтернатива Android рынку, имхо, не нужна.
Вот если они смогут выделить действительно яркую фишку…
Про лицензии ничего не слышал, но думаю, что будут программные.
Позволяет часто радовать заказчика решением наиболее важных проблем и гибко менять требования по ходу развития системы.
Но часто бывает так, что заказчик хочет понять стоимость всей системы.
Тогда без полноценного ТЗ не обойтись, иначе как оценить то, что еще не формализовано?
Это еще и способ прогнозирования затрат, ведь бизнесу часто требуется не просто реализация проекта: ему требуется понимать сроки и бюджеты, чтобы оценить эффективность вложения денег.
А более-менее точные сроки и бюджеты невозможно дать без предварительной формализации работ в виде ТЗ.
Кроме того, ТЗ — это еще и способ организации работ программистов. Часто бывает удобно обсудить проект с заказчикам и сделать ТЗ, чтобы быстро передать формализованную задачу программистам.
Но я полноценные большие ТЗ не очень люблю: слишком негибко получается :-)
Лучше разбивать проект на как можно более мелкие составляющие и двигаться к достижению целей итерациями.
Потому что 90% всего — это барахло, в полном соответствии с законом Старджона :-)