Senior'ов определяю как тех с кем можно нормально обменяться идеями проектов за кружкой пива. С мидлами — можно пообщаться за архитектуру и всякие solid'ы, тьфу на вас. С талантливыми джунами — за хайповые тулзы.
В настоящее время не существует систем, которые невозможно взломать. Вся безопасность строится на том, чтобы профит от взлома был меньше средств, которые нужно на этот взлом затратить. И циферка определяющая частоту смены пароля — это один из ключевых параметров в этой системе.
Единственное, что всё-таки стоит отметить что TF можно собрать как с оптимизациями, так и без. И не известно с какой сборкой вы сравнивали свой код на Си.
Есть Intel DAAL, который наверняка используется в вашем питоне, если это anaconda. Так что вряд-ли получится что-то ускорить если написать SIMDов самому.
Видимо мало было читателей знакомых с CH, потому что не ответили что ClickHouse умеет читать данные из Kafka напрямую. Сам. Правда вопрос в формате записей, что вы там шлете, поддерживает ли его Clickhouse (хотя переложить данные из kafka в kafka сменив формат это всё же лучше чем из Kafka в Influx, но возможно я не понимаю что такое «прямо транзакционка»).
Ещё — InfluxDB (бесплатный) не масштабируется и не реплицируется (только если руками шардировать и слать данные в отдельные реплики, наличие kafka тут всё упрощает, но тем не менее), а ClickHouse умеет в Cross-DC репликацию и распределенные запросы из коробки.
По скорости и плотности хранения информации ClickHouse тоже выигрывает.
Там все вычисления уже на GPU, всё изначально векторизировано. Но как вариант для декодирования такого видео вполне можно приспособить habr.com/company/intel/blog/430492 :).
Переключил с локальных векторных карт на тайлы, посмотрел как оно. Действительно иногда подтормаживает (зумил туда-сюда районы Стокгольма, где сейчас нахожусь). Количество объектов на средних зумах стоит уменьшить — серая пиксельная каша из дорог не нужна, мелкие здания которые сливаются в пиксели — тоже. Девайс — Xiaomi Mi5, если это имеет значение.
Вот скрины для сравнения — yadi.sk/a/aB4VvOHz3ZX2rL. Обратите внимание на количество объектов на карте гугла.
У вас что-то не так. 1 млн тайлов в день — это усредненно 12 RPS, ну пусть будет 30 если считать что пик трафика продолжается 8 часов, а не равномерно размазан по суткам. На 8 ядрах получается по 4 RPS на ядро, звучит вполне нормально… Вообще если без нагрузки оно тоже тратит по 5 секунд на рендеринг одного тайла, при использовании SSD, то явно где-то не хватает какой-то фильтрации объектов, или индексов для их выборки, или просто какой-то компонент в стеке хреново выбран.
Btw, выше по треду предложили ограничиться Европой, это сильно снижает требования по объему дисков.
1. Не получилось совсем от манипуляций с DOM избавиться чтобы выкинуть phantom и взять чистый nodejs? Вот у Игоря тикет про это — https://github.com/zhukov/webogram/issues/124, кажется он был бы очень даже за если бы ему помогли.
2. А реализаций mtproto на Ruby нет? Вот есть https://github.com/platphorm/telegram_rb, правда выглядит сыровато, да. Пробовали её?
3. Зачем вообще нужна функциональность отправки сообщений по mtproto? Кажется через бота все задачи нормально решаются.
Статья — ок, но открой для себя rclone serve :-).
Senior'ов определяю как тех с кем можно нормально обменяться идеями проектов за кружкой пива. С мидлами — можно пообщаться за архитектуру и всякие solid'ы, тьфу на вас. С талантливыми джунами — за хайповые тулзы.
Тот случай когда комментарий на порядок полезней статьи.
В настоящее время не существует систем, которые невозможно взломать. Вся безопасность строится на том, чтобы профит от взлома был меньше средств, которые нужно на этот взлом затратить. И циферка определяющая частоту смены пароля — это один из ключевых параметров в этой системе.
Я про то что код на питоне внутри тоже может использовать низкоуровневые библиотеки с оптимизациями вплоть до SIMD :).
Есть Intel DAAL, который наверняка используется в вашем питоне, если это anaconda. Так что вряд-ли получится что-то ускорить если написать SIMDов самому.
Ещё — InfluxDB (бесплатный) не масштабируется и не реплицируется (только если руками шардировать и слать данные в отдельные реплики, наличие kafka тут всё упрощает, но тем не менее), а ClickHouse умеет в Cross-DC репликацию и распределенные запросы из коробки.
По скорости и плотности хранения информации ClickHouse тоже выигрывает.
Вот скрины для сравнения — yadi.sk/a/aB4VvOHz3ZX2rL. Обратите внимание на количество объектов на карте гугла.
Там же есть ссылки на munin с графиками, на 4-х render нодах в сумме средняя нагрузка 2-3k RPS (в зависимости от дня недели) — munin.openstreetmap.org/openstreetmap/render.openstreetmap/apache_accesses.html.
Тут можно посмотреть как система на одном из серверов это переживает — munin.openstreetmap.org/openstreetmap/orm.openstreetmap/index.html.
Btw, выше по треду предложили ограничиться Европой, это сильно снижает требования по объему дисков.
2. А реализаций mtproto на Ruby нет? Вот есть https://github.com/platphorm/telegram_rb, правда выглядит сыровато, да. Пробовали её?
3. Зачем вообще нужна функциональность отправки сообщений по mtproto? Кажется через бота все задачи нормально решаются.