Ну и зря. Можно бы было найти ошибку. Если логи не пополняются - значит почти нашли ошибку. Впрочем если хостер не помог с такой просто проблемой, может и правильно переехали.
На полном серьезе чтоли советуете? Это рекламный пост. Тут такие иногда появляются. "Подскажите хостинг такой же идеальный как sweb". Две недели назад просили найти хостинг у которого бэкапы делаются также удобно как у sweb.
Тысячу раз всем говорил: логи, логи, логи, логи! Ничего кроме логов! Первое, куда лезет любой инженер - логи.
В access.log видно отдается ли вам страничка новая (200 OK) или вы кэш забираете (304 Not Modified). Может у вас вообще access.log не пополняется и вы не туда попадаете. Чтобы ни было, 90%, что ошибка моментально всплывет. А гадать на кофейной гуще будете потом, если в логах пусто.
Конфигурация железа и конфигурация сервисов зависят от клиентов. Я заметил, что за каждой компанией закрепляется свой контингент и нагрузка совершенно разная в зависимости от этого контенгента даже если работают в одной ценовой категории.
Поэтому понимание того, что надо приходит не до основания хостинга, а в процессе заказа 3-го и далее серверов. Берита пока что попало, потом поймете в какую сторону двигаться.
Не ждите, что Вам сейчас дадут идеальный и универсальный совет.
Эту информацию тоже можно самостоятельно актуализировать. Даже если AS оформлена на старого владельца, то все равно трассировка любого его IP будет проходить через раутеры из другой AS. Карту раутеров нарисовать тоже сложно, так как там тоже AS могут быть под чужим именем анонсированы, но все же долгие годы они анонсировались нормально, пока не начались все эти проблемы. А значит можно основываясь на большинстве откидывать меньшинство и получать идеальный результат. Например если 90% трафика проходит через AS на одну компанию, а трафик к ее же другой AS вдруг пошел не через ее раутеры, то выкинуть из статистики и AS с этим раутером и AS с IP конечного клиента, как неверные.
Кстати, регистарция AS на актуальное лицо - обязанность, а не по желанию. А значит где-то есть механизм, которым Вы можете заставить всех провайдеров навести порядок. Только надо этот механизм нащупать.
И тем не менее факт: клиенты реселлера, в отличии от клиентов рефа не имеют доступа к саппорту хостинга и даже не заведены в его биллинге. В моей фразе ключевое слово было "вынужден". Удобно это или нет, но это один из основных влияющих на отличие между ними факторов. Причем крайне значительный.
Ну объем рынка как-то еще реально подсчитать. Но очень трудоемко.
Если предположить, что каждый провайдер берет столько пулов адресов, сколько ему надо (ну с небольшим запасом), то можно посчитать количество пользователей по количеству IP-адресов.
Если предположить, что они берут с большим запасом, то возможно величина запаса у всех примерно одинаковая (например 30% от используемых адресов), то эта статистика тоже подойдет.
Также можно по трассировке огромного количества адресов нарисовать примерные магистрали и пиринговые сети.
Короче копайте в сторону автономок. Там лежат ответы на многие вопросы. Но придется приложить огромное количество труда. Ну и будьте готовы, что статистика может оказаться с очень нескромной погрешностью.
Вы определенно что-то путаете. Между ними нет ничего общего. Реселлинг, в отличии от рефа, оставляет контроль над пользователями, а также вынуждает самостоятельно саппортить клиентов.
Читайте выше: в сетевой стек интегрировали надежность и идеальную защиту :D
Любопытство. Расширение кругозора. Может там используются технологии лучше тех, с которыми я знаком. Вот например до этого дня я ничего не знал про UBC (у меня то нету VPS, а только шаред). Мой мир ограничивался cgroups, к которому я так и не смог привинтить hard limit, а в текущем состоянии он мне не нравится. А в UBC это есть изначально. А еще меня интересовал throttle в MySQL (удавка вместо полной блокировки пользователя), но к сожалению, его не оказалось в CL, хотя как я понял он планируется.
Может там еще что интересное есть? Никто же мне не расскажет, пока я сам не посмотрю. :)
