в MX нельзя указать IP адрес, только имя домена. Если вы указываете IN MX mail.mydomain.com - то необходимо объявить A запись для mail, чтобы DNS смог указать адрес вашего почтового сервера.
кхм... смотрю я на connlimit для iptables и не вижу невозможности его применить к udp.
Смотрите, вы можете на своем сервере настроить обрезку лишних пакетов. Они перестанут доходить до приложения, но тем не менее по прежнему будут присутствовать на интерфейсе и в канале. Если вам этого достаточно - то режьте у себя. Если нет - общайтесь с техподдержкой.
все зависит от структуры данных. Планируйте индексы, планируйте нагрузку... Однозначного ответа никто не даст. Но опять таки... Горизонтальное масштабирование никто не отменял и придумали его именно из за этого ;)
Стандартная проверка. Берем два свича, и между ними разматываем 100 метров витой пары. На улице, летом, на асфальте, без пересекающих магистралей и т.п. В свичи включаем компьютеры и проверяем через iperf линию. Так вот, на меди это взлетает без вопросов. До 130 метров точно. А вот на омедненке... Начинается лотерея ;)
берем обычную 8-портовую мыльницу, в 1-й и 2-й порты втыкаем пачкорд, и радостно наблюдаем за штормом в сети. А шторм в данном случае как раз и вызван тем, что мыльница про протокол STP не слышала, управлять кольцами не умеет, и кольцо в сети вызывает вымывание fdb таблицы чипа, в результате трафик начинает дублироваться на все порты, лавинообразно.
При некоторых условиях свич вырождается в хаб. Это происходит при переполнении fdb таблицы свича. В этих условиях пакеты начинают рассылаться на все порты коммутатора.
изначальная стоимость - это стоимость внесения в текстовый файл нескольких строк, типа
mydomen.com. IN NS ns1.mydomen.com.
mydomen.com. IN NS ns2.mydomen.com.
ns1.mydomen.com. IN A 1.1.1.1
ns2.mydomen.com. IN A 2.2.2.2
Собственно это и все, что требуется для регистрации домена mydomen.com.
Хотя нет, еще надо в whois внести инфу о домене и его владельце. Как устроен whois пока не знаю, но подозреваю что так же ;)
Ну а дальше - придумываем ценник на свои услуги и начинаем регистрировать домены ;)
Это не вызывает перекодировку данных. Первая директива задает кодировку по умолчанию для базы данных - теперь все операции создания таблиц без указания кодировки будут брать кодировку указанную для базы. Вторая директива задает кодировку по умолчанию для таблицы - теперь все операции создания таблиц, в которых не указана кодировка для текстового поля будут принимать кодировку из таблицы.
Если уж менять кодировку для поля - то надо указывать конкретное поле в операторе alter table. Но даже это не вызовет перекодировку данных - просто указывается с какой кодировкой по умолчанию теперь интерпретировать эти данные.
Ну в принципе такое решение описано у них в документации. По крайней мере я так ее понял ;) Честно скажу - с heroku не работал, опирался исключительно на документацию и принципы работы dns.
Да, получаем лишний сервер и лишний запрос в днс, но не думаю, что в вашем случае это создаст значительные проблемы. Хотя вам виднее. Думаю, как дойдете до миллиона клиентов вашего приложения - стоит пересмотреть схему ;)
