у меня лишь один вопрос - какой процент подобных ситуаций в среднем?
не думаю что выше 1%
так почему просто не оставить в покое полученные деньги.
а недовольному клиенту, чтоб не гундел по форумам, просто взять с личного кошелька/карты перевести нужную сумму?
потерей будет ведь не вся сумма, а только налог с нее.
но это всяко дешевле, чем потеря репутации из-за подобных гнилых тем в выдаче поисковиков.
а смысл проверять разные домены на одних и тех же ns?
что там у яндекса, dns1.yandex.net и dns2.yandex.net? вот именно их та проверялка проверяет так понимаю. а не домены ваши на них.
т.е. не будет такого что домен А на этих ns прошел проверку, а В не прошел.
либо все, либо никто.
так...
telnet: Unable to connect to remote host: Connection refused
запустил lsof -i -n -P | grep :53
и вижу что все как положено - как в конфиге указано 4 процесса udp и 4 процесса tcp, так и есть - (LISTEN)
точно также на двух других серверах, которые без проблемы этой.
а потом я запустил iptables -S ...
и вот оно :(
я совсем забыл что тут еще поднят vpn с кучкой правил в iptables
среди которых:
на вход был открыт только udp 53 порт.
и все замечательно работало кстати говоря.
открыл здесь 53 tcp и теперь порядок - "All Ok!" везде.
т.е. сам себе буратино, а на поддержку бочку катил... стыдно товарищи. пойду извиняться :(
что конкретно может означать у них "edns512tcp=connection-refused" ?
dns=ok edns=ok edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok docookie=ok edns512tcp=connection-refused optlist=ok,subnet
у меня на одной из vps работает dns сервер (точно такой же с такими же настройками в 2х других местах - там все ок) и из-за него все домены "Minor problems detected".
поддержка утверждает что они ничего не блокируют. я допустим верю, но значит где-то что-то еще по-умолчанию было настроено так, чтоб блокировать.
и как мне направить их в нужную сторону где копать?
как еще можно из другого места протестировать на этот "connection-refused"? какой конкретно запрос они пытаются послать?
так у каждого юзера должен быть указан его домашний каталог (в passwd)
главное создавалку юзера заставить создавать их отныне в /home2
а панель, достаточно чтоб она брала каталог именно так, а не тупо по шаблону /home/%user%
симлинки тоже вариант и тоже достаточно чуть поправить создавалку юзеров, чтоб после создания /home2/%user% делела еще и ln -s /home2/%user% /home/%user%
мысль отселить статику отдельно от основного сайта очень правильная, не понимаю почему многие отговаривать пытаются.
сами страницы сайта должны генерироваться максимально быстро, а значит нужен дорогой высокочастотный процессор, дорогая ssd и т.п.
статике это все не нужно. там наоборот можно хоть на hdd хостить за максимально дешево.
все крупные сайты именно так и делают, только они в основном самописные, а не на вордпресиках. и потому сложностей подобных не возникает.
в этом конкретном случае я бы как вариант сделал на сервере статики nfs шару, подмонтировал ее в uploads сервера динамики. и все ссылки на фотки соответственно должны быть на поддомен static.example.com
т.е. wp будет ничего не подозревая сохранять все как обычно, а по факту на основном сервере место расходоваться не будет вообще, все сразу будет закидываться на второй. и только от туда грузиться посетителями через поддомен.
ну тогда чем помочь-то?
все очевидно. хочется быстрее - платишь за более быстрое железо.
ну или не платишь и пользуешься тем что есть.
я лишь отвечаю на первоначальный вопрос, станет ли быстрей если заплатить за больше таких же ядер - нет, не станет. в данном конкретном случае.
производительней - да, станет.
но если посетителей и так не много и даже нынешние 2 ядра справляются, то смысл переплачивать?
даже в тех же магазинах часто половина касс не работает. смысл платить зарплату, чтоб кто-то просто сидел и ничего не делал.
а в выходные/праздники "подключают" всех к работе.
---
еще лучше 3й путь - заняться самим сайтом, чтоб он сам по-себе начал работать быстрей и на нынешних 2ггц.
была бы просто статика - все был влетало моментом и на 1 ядре какого-нибудь atom'а.
понятно что это идилия, но к этому стоит стремиться.
или можно попробовать просто хороший shared вместо vps.
такой, где будет и частота под 4ггц и все ядра доступны. да еще и наверняка дешевле нынешней vps.
но если сайт сделан через задницу и будет грузить зря процессор какой-то дурной работой, то попросят съехать конечно же.
хотя это даже стимул будет работать над сайтом.
это правильней, чем платить и платить за чьи-то поделки скрипты/плагинчики.
ответ на "что бы вы выбрали" зависит от задачи.
если много посетителей и создаются очереди на каждом из ядер (показатель LA может примерно дать понимание есть ли очереди и на сколько большие), то надо увеличивать число ядер.
если очереди в норме и хочется чтоб быстрее генерировались страницы - надо выше частоту.
но да, частоты сильно не увеличишь, есть определенный физический лимит.
а число ядер более-менее масштабируются, но надо осознавать что именно быстрей оно не станет.
только производительней, т.е. больше одновременных запросов сможет выполниться.
и снова да... может так получиться что 2x3ггц окажутся в итоге медленней, чем 4x2ггц, но только в случае возникновения очередей (много посетителей).
ну а 4x3ггц будут и быстрей и производительней.
лучше и того и другого по-больше... и можно без хлеба :)
ну это еще вопрос кто фуфло толкает, а кто не вникает в суть вопроса.
задача стояла: "небольшой по посещаемости сайт – скажем на WordPres", а не очередь из 1000...
поставьте wp на vps с 2 ядрами и тоже самое, но с 4-6 ядрами (такими же).
и сможете ли на глаз определить с какой из них открывается сайт? :)
очень сомневаюсь что будет хоть сколько-нибудь заметная разница.
не путаем веб-сервисы, тот же nginx и тонны тяжелых php скриптов и столько же запросов к базе.
nginx конечно многопоточный, но разве речь про тормоза при раздаче статики?
еще раз напоминаю условия задачи - у нас нет очереди. есть "небольшая посещаемость".
скажем 1-2 запроса главной страницы в минуту.
а это приблизительно 1-3к посетителей в день, что даже более чем общепринятая "небольшая посещаемость".
т.е. очереди на кассах (сколько бы их ни было) у нас нет по условию задачи.
вопрос: как нам поможет многопоточность получить главную страницу скажем не за 1сек, а за 0.2сек?
речь про index.php, а не полную загрузку всего сайта с тонной мусора статики.
вы подкатываете до верху забитую покупками тележку к свободной кассе.
вопрос: скорость прохождения именно вас через кассу будет зависеть от количества касс в маркете? будь их хоть 2, хоть 10, ваша скорость прохождения будет зависеть исключительно от расторопности кассирши. вы не раскидаете покупки по разным кассам.
если мы говорим о классической ситуации, о том же wordpress'е.
так-то конечно при желании можно и раскидать, но этим надо заниматься... кассирши с соседних касс сами не прибегут разгребать вашу тележку.
выхода лишь два - либо выбросьте из тележки все излишества, оставьте только самое необходимое.
либо выбирайте молодую и энергичную кассиршу, близкую к 4ггц, а не 2ггц бабулю.
а лучше и то и другое.
понятно что чем больше посетителей, тем больше количество касс играют роль, т.к. уменьшится вероятность очереди на каждой из касс. но когда очередей нет, то лишние свободные кассы врядли ускорят процесс вашего прохождения к выходу.
тут надо различать понятия скорости и производительности. это разные вещи.
