Himiko, вы из Сибири ? главный результат таких измерений - доказательство следования систем большинства провайдеров значениям TTL. Использовать эти результаты можно и нужно каждый раз.
Himiko, если при переносе наблюдать за логами вебсервера на старом и новом сервере, то можно накопить кое-какие объективные данные касательно всех посетителей сайта и сделать выводы.
olkaBaby, чтобы понять ответ, нужно понимать откуда в каждом конкретном случае берется TTL и как его проверить.
я могу дать простой ответ : при изменении данных у регистратора граница сверху - четверо суток.
при изменении CNAME или A - от 15 мин до 24 часа
За последние лет 5 я видел только один случай когда при переносе у конкретной локальной украинской фирмы сайт открывался на старом месте довольно долго.
В подавляющем большинстве случаев все провайдерские системы следуют указанию TTL. Провайдеру совершенно неинтересно отвечать на звонки и даже просто читать жалобы.
Antoniusss: Есть ли здесь, кто такие услуги оказывает на платной основе?
Неа. Как только об этом заходит речь, выясняются такие сложности, что многие готовы просто потерпеть.
Вот даже Мастерхост это понимает и поэтому фактически время решения проблемы составило 2:40 рабочего времени считая от 10 утра - времени прихода старших несменных админов.
Для профилирования php нужны совсем другие знания.
Вы лучше делайте, что вам выше советовали. При ограничении числа воркеров, они перестанут мешаться друг другу. Совокупная "мощность", количество "работы" в секунду, упадет.
olkaBaby, между CNAME и A разницы нет. Дело в значении TTL, которое к записи приставлено, а не в типе записи.
Если "зоной DNS", подразумевалось изменение dns-серверов у регистратора - это, конечно, самое медленное. TTL там может составлять 2-4 суток в зависимости от зоны, плюс некоторое время (часы), которое уйдет у регистратора, прежде чем информация дойдет от их систем к DNS.
Himiko, вы из Сибири ? главный результат таких измерений - доказательство следования систем большинства провайдеров значениям TTL. Использовать эти результаты можно и нужно каждый раз.
Himiko, я не говорил про быстрее. Непонятно вообще с какой целью вы это высказали.
Каждый конкретный случай у каждого посетителя индивидуален, но все равно можно весьма достоверно измерить процесс переноса в целом.
Himiko, если при переносе наблюдать за логами вебсервера на старом и новом сервере, то можно накопить кое-какие объективные данные касательно всех посетителей сайта и сделать выводы.
olkaBaby, чтобы понять ответ, нужно понимать откуда в каждом конкретном случае берется TTL и как его проверить.
я могу дать простой ответ : при изменении данных у регистратора граница сверху - четверо суток.
при изменении CNAME или A - от 15 мин до 24 часа
За последние лет 5 я видел только один случай когда при переносе у конкретной локальной украинской фирмы сайт открывался на старом месте довольно долго.
В подавляющем большинстве случаев все провайдерские системы следуют указанию TTL. Провайдеру совершенно неинтересно отвечать на звонки и даже просто читать жалобы.
Есть ли здесь, кто такие услуги оказывает на платной основе?
Неа. Как только об этом заходит речь, выясняются такие сложности, что многие готовы просто потерпеть.
Вот даже Мастерхост это понимает и поэтому фактически время решения проблемы составило 2:40 рабочего времени считая от 10 утра - времени прихода старших несменных админов.
Зачем им спешить, если вы никуда не убежите ?
grey2, работой грузят.
Для профилирования php нужны совсем другие знания.
Вы лучше делайте, что вам выше советовали. При ограничении числа воркеров, они перестанут мешаться друг другу. Совокупная "мощность", количество "работы" в секунду, упадет.
olkaBaby, нет разницы во времени обновления.
olkaBaby, между CNAME и A разницы нет. Дело в значении TTL, которое к записи приставлено, а не в типе записи.
Если "зоной DNS", подразумевалось изменение dns-серверов у регистратора - это, конечно, самое медленное. TTL там может составлять 2-4 суток в зависимости от зоны, плюс некоторое время (часы), которое уйдет у регистратора, прежде чем информация дойдет от их систем к DNS.
Такое ощущение, что этот tar и mysql что-то поделить не могут
Не могут поделить память. Такие операции часто "смывают" кеш диска.
Использование tmpfs может даже ухудшить ситуацию. Пробуйте.
Vin_cent, нет, не прикол. У всякого "серьезного бизнеса" есть условия, с которыми он вполне может смириться.
Вам же ionice не помог. Дальше-то что?