Вбрасываю насчёт применимости управляемого кода в "низкоуровневых" приложениях и готовности Microsoft к dog-fooding: движок хранилища нового Exchange переписан на управляемом коде.
Он эффективнее в терминах IOCP по сравнению с предыдущим поколением в Exchange 2010.

Здравствуйте, Sinclair, Вы писали:

S>Вбрасываю насчёт применимости управляемого кода в "низкоуровневых" приложениях и готовности Microsoft к dog-fooding: движок хранилища нового Exchange переписан на управляемом коде.

А там что, есть серьезные затыки по процессору? Не SQL Server с кучей хранимок все же.

Здравствуйте, AndrewVK, Вы писали:

AVK>А там что, есть серьезные затыки по процессору? Не SQL Server с кучей хранимок все же.
Про затыки по процессору я, собственно, ничего не знаю. Я даже не вполне понял из презентации, идёт ли речь о замене самого ESE или только о приложении Store, которое может интеропаться с ESE.

Здравствуйте, Sinclair, Вы писали:

S>Вбрасываю насчёт применимости управляемого кода в "низкоуровневых" приложениях и готовности Microsoft к dog-fooding: движок хранилища нового Exchange переписан на управляемом коде.
S>Он эффективнее в терминах IOCP по сравнению с предыдущим поколением в Exchange 2010.
Насколько я помню уже в 2010 нативного кода было мало, что в свое время меня очень удивило

Здравствуйте, Sinclair, Вы писали:

S>Вбрасываю насчёт применимости управляемого кода в "низкоуровневых" приложениях и готовности Microsoft к dog-fooding: движок хранилища нового Exchange переписан на управляемом коде.
А подробности? Откуда дровишки? ))

Здравствуйте, IB, Вы писали:
IB>А подробности? Откуда дровишки? ))
Из Здания 33
Exchange 15 TAP Summit.

Подробностей пока не очень много.
Вот сегодня рассказали про предварительные (до релиза ещё значительно больше года) результаты перформанс тестов. IOPS сократили примерно на треть, зато в полтора раза выросло потребление CPU и в 4 раза оверхед по памяти (всего примерно 1 гиг на сервер).
Идея в том, что CPU и RAM сейчас быстро растут и дешевеют, а IO — нет. Пацаны рассчитывают иметь 16-32 ядра на типичном back-end сервере.
Ну, то есть воспринимать это надо, конечно же, with a grain of salt, т.к. это просто результаты их ночных автотестов. Никто полировкой перформанса в терминах CPU и RAM ещё не занимался — полировали алгоритмы и параметры для сокращения IOPS.

Здравствуйте, Sinclair, Вы писали:

S>Exchange 15 TAP Summit.
=) А на BUILD будешь, в LA в сентябре?

S>Вот сегодня рассказали про предварительные (до релиза ещё значительно больше года) результаты перформанс тестов. IOPS сократили примерно на треть, зато в полтора раза выросло потребление CPU и в 4 раза оверхед по памяти (всего примерно 1 гиг на сервер).
Прикольно ) А за счет чего они так выйграли — просто аккуратнее все переписали, реализовали новые алгоритмы заточенные под конкретную нагрузку или еще что-то? Не колятся?

Здравствуйте, IB, Вы писали:

S>>Exchange 15 TAP Summit.
IB>=) А на BUILD будешь, в LA в сентябре?
Очень-очень вряд ли. . Я сюда-то еле выбил поездку.

IB>Прикольно ) А за счет чего они так выйграли — просто аккуратнее все переписали, реализовали новые алгоритмы заточенные под конкретную нагрузку или еще что-то? Не колятся?
Не, не колятся. Это же не для разработчиков инфа. Всё, что они рассказывают про архитектуру — оно скорее для админов. Типа "ну вот мы теперь сделали отдельные процессы для каждой mailbox database, так что теперь при падении или зависании одной БД остальные незатронуты, и дампы делать быстрее и легче". Ну, и как следствие "зато у каждого процесса есть некий оверхед по памяти". Глубже этого мало что известно.

Пытливые умы смогут получить доступ к паблик бете когда-то в следующем году, и применить силу Лутза Родера

Здравствуйте, Sinclair, Вы писали:

S>Подробностей пока не очень много.
S>Вот сегодня рассказали про предварительные (до релиза ещё значительно больше года) результаты перформанс тестов. IOPS сократили примерно на треть, зато в полтора раза выросло потребление CPU и в 4 раза оверхед по памяти (всего примерно 1 гиг на сервер).
S>Идея в том, что CPU и RAM сейчас быстро растут и дешевеют, а IO — нет. Пацаны рассчитывают иметь 16-32 ядра на типичном back-end сервере.

SSD и гигабайтные кэши сделали революцию, сейчас сотни тысяч IO операций в секунду уже мэйнстрим. IO ни в какую сейчас не затык. Кривые ручки программистов, как и всегда, сейчас top 1 performance issue.

Здравствуйте, IB, Вы писали:

S>>Exchange 15 TAP Summit.
IB>=) А на BUILD будешь, в LA в сентябре?

S>>Вот сегодня рассказали про предварительные (до релиза ещё значительно больше года) результаты перформанс тестов. IOPS сократили примерно на треть, зато в полтора раза выросло потребление CPU и в 4 раза оверхед по памяти (всего примерно 1 гиг на сервер).
IB>Прикольно ) А за счет чего они так выйграли — просто аккуратнее все переписали, реализовали новые алгоритмы заточенные под конкретную нагрузку или еще что-то? Не колятся?

Уверен, что выигрыш НИКАК не связан с менеджед кодом. Да он и не может быть, собсно. Просто что-то оптимизнули И, заодно, ублажили devdiv.

Здравствуйте, iHateLogins, Вы писали:

HL>Уверен, что выигрыш НИКАК не связан с менеджед кодом. Да он и не может быть, собсно.
Да ладно. Как раз возможность "оптимизнуть", а не бороться с языком и есть заслуга менеджед кода. =)