Явный кеш БД, вроде как, оторвали в 2.x, мотивируя это «лучшим» DB слоем? Хранить сессии в базе они сами не рекомендуют в вики (да и их сессии намного дешевле хранить на ФС с каким-либо session stickness в кластере). Запросов на чтение из БД в Moodle в разы (если не на порядки) больше, чем на запись, и в недрах трекера даже есть упоминание, венчающееся «мы что-то где-то как-то протестировали, нам не понравилось».
Я же тоже не просто так написал, я со всем этим реально сталкивался. И те 2.5 Moodle Partner'а, которых я своими глазами видел, либо гасят проблему производительности железом (иногда очень смешно), либо своими собственными разработчиками, которые делают как надо, а не как придётся. Есть, например, забавный тикет, в котором человек спрашивает разработчиков, зачем они раздачу статики от тем оформления запихали в PHP-скрипты. Доводы даже как-то местами понятны, и понятно, что это обходится поставленным впереди прокси-сервером, но ведь это знать надо, что оно вот так-то устроено и вот так-то без последствий лечится.
В своё время я правки в ядро просто по diff-ам от оригинальной версии посмотрел. Но мне было проще — была задача просто определить, можно ли это всё выкинуть без значительного ущерба для функционала.
> Moodle хорош именно как интеграционная платформа: достаточно стабилен, если не ставить экспериментальные версии (больше 60 тысяч инсталляций выявляют большинство проблем раньше, чем вы их заметите), масштабируем (имеются инсталляции более чем с 1 миллионом пользователей)
Всё бы хорошо, но есть нюансы. Выявить-то большинство проблем выявят, но вот когда разработчики их починят — большой вопрос.
Масштабирование «из коробки» практически никакое: нет поддержки read-only slave DB (хотя обещают), нет поддержки X-Sendfile (хотя обещают), по некоторым тикетам напрашивается вывод, что собственно разработчики Moodle нагрузочным тестированием себя не утруждают. На одном и том же сервере инсталляция версии 2.0 по умолчанию ест вдвое больше ресурсов (по времени генерации страницы/данным performance info), чем инсталляция по умолчанию 1.9.
По коду разбросано вдохновляющее количество хардкода (например, максимальное количество недель в курсе и combobox для него на 52 элемента вместо textbox'а с одним числом, период enrollment'а).
В итоге, для реализация масштаба ВУЗа не соглашусь с автором в части «никаких правок в ядре, никаких патчей и хаков». Да, нужно постараться максимально их избежать, но делать их всё равно придётся рано или поздно, ибо некоторые вещи через API недоступны. Так что лучше сразу обеспечить наличие под рукой хоть какого-то специалиста в PHP, который умеет вести документацию на доработки и таскать их от релиза к релизу.
Ну и да, не стоит мне писать, что это OSS, где твой вклад и т.д., ибо я не разработчик. В конце концов, я же не говорю, что хуже Moodle нет, а лишь сожалею, что нет сильно лучше.
Мне тоже не хватало маленьких 64-бит инстансов, ибо теперь не нужно держать по две AMI в регионе для разных размеров инстансов, достаточно только одной. И смена размера инстанса на любой теперь производится простым остановом/запуском — удобно.
К тому же, появилась закрывашка для дырки в оперативной памяти инстанса (1Гбайт — 2Гбайт — дырка — 8Гбайт).
Внутри AZ можно отцеплять/прицеплять диски. Внутри региона между разными AZ — через снимок тома. Между регионами — только посредством третьих инструментов типа rsync.
Одно дело, когда один человек роет себе одну яму ровно с человека размером. Другое — когда десятки тысяч людей роют котлован, в который попадают вообще все.
Да, membership agreement не позволяет клиенту передавать его учётные данные третьм лицам, иначе books24x7 осталяет за собой право прекратить доступ без возврата денег. Также там оговаривается запрет на зеркалирование книг с помощью софта а-ля Teleport Pro и правила по использованиюскачиваемого контента. На сайте можно целиком прочитать.
ИМХО, перезапуск сервиса по любому изменению конфига для «боевых» серверов всё-таки не есть хорошо, ведь после редактирования конфигурация сервиса может быть просто нерабочей (зависимые сервисы, конфигурация в несколькоих файлах, сервис долго перезапускается и т.д.). А это непроизводительные простои и тоска пользователям.
Лично у меня, например, есть привычка говорить ":w" несколько раз в процессе редактирования (а изменения бывают объёмными) конфига — IM_MODIFY будет выстреливать при каждой записи?
Не всегда на какой-нибудь кафедре есть специально обученный программист либо связь с профильной кафедрой/институтом/ВЦ. Зачастую что физики, что прикладные математики сами реализуют свои алгоритмы, и в случае каких-то затруднений не знают, куда податься. Это печально, но это так.
Есть и порядочно положительных примеров, когда, например, биологи строят модели, а программисты их реализуют. Всякое бывает.
Я тоже много чего писал и на MPI, и на C: есть преподаватели в русских институтах. Однако, я также и с физиками общался, которые не знали, как решить СЛАУ размерностью в десятки тысяч. В память не влезает, что делать? И с численниками общался, которые говорили, что программист параллельных приложений — глупость, ибо они, численники, всё распараллелят сами. Годы прошли, а воз и ныне там.
Это так. Кроме того, в том же НИВЦ есть и свои спецы. Дело не в том, как учить людей и каких спецов привлекать, лишь бы были эти спецы и лишь бы шёл процесс обучения.
А вот насчёт отсутствия кадров — как же не тормозит. Развитие технологий это не только куча дорогущего железа с гордой надписью IBM. Эту кучу ещё уметь применять надо, чтобы не забивать гвозди микроскопом. Ну будет у нас те же два центра, которые будут чем-то заниматься в области технологий. А кто будет массово внедрять разработки в жизнь?
С одной стороны, мне известны два ВУЗа, которые недавно стали счастливыми обладателями собственных кластеров (один из которых из «СКИФ»ов), но кластеры эти банально не используются. Железо есть, но нет ни специалистов по этому железу, ни задач, которые сотрудники ВУЗов готовы были бы решать на этом железе. Проблема-то не в железках, проблема в образовании. Для большинства тех же математиков и физиков требование одно — дайте больше памяти и тактовой частоты ядра. На восьмиядерной машине просто запускается восемь копий самописного софта (пакеты типа Fluent в расчёт не берём), которые что-то своё считают каждая на своём ядре. Оно и однопоточное-то работает кое-как, а многопоточные (упаси Господь многопроцессные, например на MPI) приложения практически никто из деятелей науки писать не умеет.
С другой стороны, есть такие организации, как ЛИТ ОИЯИ, НИВЦ МГУ, которые давно и успешно занимаются высокопроизводительными вычислениями. Дело это нужное (выше были примеры использования) и хорошо, что этим у нас вообще кто-то занимается (на parallel.ru есть список зарубежных суперкомпьютерных центров и интернет-ресурсов, можно сходить и прослезиться).
Сроки, заявленные Медведевым, вызывают умиление. Конкретные предложения по отрасли за полтора месяца — это класс. Разработка стандартов систем и проработка совместимости до конца года — это вообще сильно. До конца года будут писать слово «Globus»? «Американцы не дураки, делайте как у них»?
Между тем, что такое «грид-системы» вообще никто не знает. «Мы объединим все суперкомпьютеры в суперпуперкомпьютер и будет здорово». Да не будет, потому что грид больше добавляет проблем, чем решает.
Короче, начинание правильное, да вот только уж больно неожиданно и странно президент проснулся на эту тему. В статье куча ссылок на петафлопсы и железо, а про подготовку кадров пару строк. Не в железе счастье, а в мозгах.
Я же тоже не просто так написал, я со всем этим реально сталкивался. И те 2.5 Moodle Partner'а, которых я своими глазами видел, либо гасят проблему производительности железом (иногда очень смешно), либо своими собственными разработчиками, которые делают как надо, а не как придётся. Есть, например, забавный тикет, в котором человек спрашивает разработчиков, зачем они раздачу статики от тем оформления запихали в PHP-скрипты. Доводы даже как-то местами понятны, и понятно, что это обходится поставленным впереди прокси-сервером, но ведь это знать надо, что оно вот так-то устроено и вот так-то без последствий лечится.
В своё время я правки в ядро просто по diff-ам от оригинальной версии посмотрел. Но мне было проще — была задача просто определить, можно ли это всё выкинуть без значительного ущерба для функционала.
Всё бы хорошо, но есть нюансы. Выявить-то большинство проблем выявят, но вот когда разработчики их починят — большой вопрос.
Масштабирование «из коробки» практически никакое: нет поддержки read-only slave DB (хотя обещают), нет поддержки X-Sendfile (хотя обещают), по некоторым тикетам напрашивается вывод, что собственно разработчики Moodle нагрузочным тестированием себя не утруждают. На одном и том же сервере инсталляция версии 2.0 по умолчанию ест вдвое больше ресурсов (по времени генерации страницы/данным performance info), чем инсталляция по умолчанию 1.9.
По коду разбросано вдохновляющее количество хардкода (например, максимальное количество недель в курсе и combobox для него на 52 элемента вместо textbox'а с одним числом, период enrollment'а).
В итоге, для реализация масштаба ВУЗа не соглашусь с автором в части «никаких правок в ядре, никаких патчей и хаков». Да, нужно постараться максимально их избежать, но делать их всё равно придётся рано или поздно, ибо некоторые вещи через API недоступны. Так что лучше сразу обеспечить наличие под рукой хоть какого-то специалиста в PHP, который умеет вести документацию на доработки и таскать их от релиза к релизу.
Ну и да, не стоит мне писать, что это OSS, где твой вклад и т.д., ибо я не разработчик. В конце концов, я же не говорю, что хуже Moodle нет, а лишь сожалею, что нет сильно лучше.
К тому же, появилась закрывашка для дырки в оперативной памяти инстанса (1Гбайт — 2Гбайт — дырка — 8Гбайт).
ИМХО, перезапуск сервиса по любому изменению конфига для «боевых» серверов всё-таки не есть хорошо, ведь после редактирования конфигурация сервиса может быть просто нерабочей (зависимые сервисы, конфигурация в несколькоих файлах, сервис долго перезапускается и т.д.). А это непроизводительные простои и тоска пользователям.
Лично у меня, например, есть привычка говорить ":w" несколько раз в процессе редактирования (а изменения бывают объёмными) конфига — IM_MODIFY будет выстреливать при каждой записи?
Есть и порядочно положительных примеров, когда, например, биологи строят модели, а программисты их реализуют. Всякое бывает.
А вот насчёт отсутствия кадров — как же не тормозит. Развитие технологий это не только куча дорогущего железа с гордой надписью IBM. Эту кучу ещё уметь применять надо, чтобы не забивать гвозди микроскопом. Ну будет у нас те же два центра, которые будут чем-то заниматься в области технологий. А кто будет массово внедрять разработки в жизнь?
С другой стороны, есть такие организации, как ЛИТ ОИЯИ, НИВЦ МГУ, которые давно и успешно занимаются высокопроизводительными вычислениями. Дело это нужное (выше были примеры использования) и хорошо, что этим у нас вообще кто-то занимается (на parallel.ru есть список зарубежных суперкомпьютерных центров и интернет-ресурсов, можно сходить и прослезиться).
Сроки, заявленные Медведевым, вызывают умиление. Конкретные предложения по отрасли за полтора месяца — это класс. Разработка стандартов систем и проработка совместимости до конца года — это вообще сильно. До конца года будут писать слово «Globus»? «Американцы не дураки, делайте как у них»?
Между тем, что такое «грид-системы» вообще никто не знает. «Мы объединим все суперкомпьютеры в суперпуперкомпьютер и будет здорово». Да не будет, потому что грид больше добавляет проблем, чем решает.
Короче, начинание правильное, да вот только уж больно неожиданно и странно президент проснулся на эту тему. В статье куча ссылок на петафлопсы и железо, а про подготовку кадров пару строк. Не в железе счастье, а в мозгах.
Поживём-увидим. Хорошо, когда что-то делается.
Хотя с технической точки зрения, разумеется, это вполне реализуемо.