to post messages and comments.

SSL и правда на столько медленный или у меня руки кривые? nginx по http обрабатывает по 5к запросов в секунду, и среднее время ответа не больше 200мс, на том же сервере по https обрабатывает около 70-200 запросов в секунду и ответы по секунде и больше, периодически достигая минуты. Процессоры загружены не более чем на 15-20% память почти вся свободная

Преамбула: Я разрабатывал, в основном, десктопные приложения. Сетевые писал в специфичной области, где 3 клиента на сервер — уже много.

Ковыряем тут архитектуру сервера для нового проекта. Сдесь затык, там асинхронщина, и вот уже в проекте и NoSQL (Redis), и очереди сообщений (ZMQ), и всякое другое хипстерство :)

в общем, перефразирую Митця:
— Ну а згодом? Про наслідкі можливі не подумать? Один лиш тількі раз і вже "хайлоад" крадеться з своїю усмішкою хижой. Макбуки, рубі, кєди, смузі та коворкінг...

Сейчас узнал как работает хайлоад поиск и хранения некоторого набора информации в одной кампании, занимающейся контекстной рекламой. Местные мастера умудрились намутить обёртку прямо поверх dev, и писать/читать прямо туда/оттуда. Монструозный велосипед, который вполне понятен на уровне сотен миллиардов записей.
Всё-таки порой чувствую себя полным нубом в кодинге.

highscalability.com — вы ебанулись? Я люблю питон, често, но OK, it can use too much memory and be too slow. Not a big deal on the server side, just buy bigger machines. — это же ебаный пиздец, повышать скорость работы софта за счет пользователя — это же ебаный пиздец и фейл по все поля.

Установили новый рекорд нагрузки, 2500 rps. Всё, большего пока и не нужно. Осталось поднять нормальный мониторинг, дабы следить за ситуацией, и понять, как нормально обойти балансер.

Всё, мы окончательно ебанулись. Неделя нагрузочного тестирования не проходит даром. Поприседали на все возможные дилды с нжинксом и отсутствующими профилированием/мониторингом. Поднялись со 120 до 850 rps. Хотим больше. Следующий шаг — несколько гуникорнов под одним нжинксом. We need to go deeper.

Тут говорят, что выражение «High Load» — русизм, больше так никто не говорит. То-то меня раздражает его непонятность. Правильно писать «Hight Availability». Теперь всё встало на свои места. Нагрузка на серверах вообще никак не связана с желаемым результатом — доступностью сервисов. Отныне и присно, и во веки веков буду гнобить «High Load»

Поиск мечты: есть какая-нибудь распределённая ФС, которая умеет:
— управляемый, на уровне отдельного файла, мирроринг(между машинками) и кэширование(в память)
— управляемое шифрование, опять же per file
— дедуплецирование
— настраиваемый механизм кэширования, а не просто lru

instagram-engineering.tumblr.com — рассказ про архитектуру Instagram.

Краткое резюме:

1. Amazon EC2 — для хостинга.
2. Ubuntu 11.04 — основная OS.
3. PostgreSQL (12 Quadruple Extra-Large High-Memory nodes + 12 replicas) — для основной части данных. Pgbouncer для пулинга.
4. Redis (several Quadruple Extra-Large Memory nodes) — для фидов и сессий.
5. PostGIS → Apache Solr — для гео-поиска.
6. Memcached (6 instances) — для... ни за что не угадаете. Не используют Amazon Elastic Cache, потому что невыгодно экономически.
7. Django (>25 High-CPU Extra Large nodes) over Gunicorn — для динамики.
8. Nginx (3 nodes) позади Amazon Elastic Load Balancer (проверяющим их доступность) — для балансировки загрузки. ELB также и терминирует SSL.
9. Amazon Route 53 — для DNS.
10. Fabric — для автоматизации деплоймента.
11. Gearman — для очереди задач. PyAPNS — PUSH-нотификации.
12. Munin — метрики. Sentry — error reporting. Pingdom — внешний мониторинг доступности. PagerDuty — информация о инцидентах.

Мне нужно выбрать БД для будущего достаточно нагруженного приложения. Основная задача — хранение большого количества данных вида ключ — значение (значения). Сейчас выбор стоит между MySQL и PostrgeSQL. С PostgreSQL работал мало^W^Wне работал почти совсем.
Основные критерии — надежность, скорость и масштабируемость.
Что выбрать и в кратце почему, Жуйк? Спасибо.

В связи с #1369483 возник такой вопрос — а если сервер будет держать два каталога с хардлинками от картинок, боевой и приватный, и при удалении стирать хардлинки из боевого каталога, его постигнет смерть от фрагментации?

Жуиск, ты как бы ворочал матрицы, скажем, 1.000.000 на 1.000.000? Я вот слышал много всяких модных слов типа "хадуп", "piccolo" и MapReduce, они большой оверхэд дадут по сравнению с нативным велосипедом?

graylog2.org Какая хорошая штучка! Это целая система логгинга с поддержкой AMQP. Как оно красиво, интересно и вкусно, но... Ест не мало ресурсов(на джаве написано, к слову), да и применять особо негде.