Три раза нет? :)
Безымянный 30.09 11:52
1. Проблему с загрузкой большого числа модулей можно решить только ленивой загрузкой, кеширование не поможет. Прекрасный пример Питон, где большие проекты могут стартовать десятки секунд, а то и минуты (про Руби даже речи нет, там ещё медленнее). Предкомпиляция байт-кода есть в Питоне давно, но она проблему не решает. Поэтому в следующей версии Питона (3.15) появтися ленивая загрузка модулей.
В Парсере ленивая загрузка пшется элементарно с помошью свойств. Еще сильно помогает объединение кода нескольких связанных классов в один файл — тогда файловых операций будет поменьше и это всё равно полезно, даже если код в кеше ОС.
2. HTTP-сервер не в Парсере. Это всего-лишь ещё один интерфейс для интерпретатора. Вместо stdin/stdout мы используем http-протокол. Базовая схема запрос-обратока-ответ не меняется, сервером мы из кода не управляем.
Пока в Парсере нет асинхронного ввода-вывода и корутин нет никакого смысла городить костыли — всё равно мы очень быстро упрёмся в проблему отдельного треда на каждый запрос. Даже при недбольших нагрузках. А ещё сразу захотим общую память между потоками и синхронизацию. :)
3. Сигналы без асинхронного ввода-вывода и корутин тоже смысла не имеют. Пока мы не можем явно управлять потоком исполнения из кода на Парсере мы даже graceful shutdown нормально не сделаем.
----------
Основной посыл такой. Как только мы получем задачу, для которой не срабатывает схема «полный запрос → полный ответ», то нам надо брать другие инструменты. asyncio/aiohttp для Питона, Ноду, Го или даже Раст с Токио. Т.е. инструменты, которые изначально проектировались под сложные задачки с сетью и распределённостью.
Более менее перспективное направление развития — добавлять интерфейсы для общеупотребимых систем — очередей (Рэбит, Кафка, Натс), ноэскуэля (Редис, Монга и т.п.), и баз аднных (например, драйвер для Фаербёрда/РедБазы пригодился бы).
