зависит от того, как именно ваша CMS будет нагружаться. Много пользователей, минимум функционала - почитайте подробнее про работу под nginx, там как раз на многоподключений.
Много тяжелых сложных отчетов, возможно поискать решение без sql, или оптимизировать сами запросы.
Невозможно сделать универсальную быструю CMS, все затачивается под конкретный тип использования.
Поищите удачный профайлинг и делайте нагрузочные тесты, имитируйте пользователей, увидите где затыки.
Например в SoundForge есть функция нормализации, которая сглаживает все пики громкости, приводя к примерно среднему. То есть извлечь аудиопоток, прогнать через нормализатор, засунуть его назад в видео уже обработанным.
Так можно и несколько видео подряд обработать, и они все будут идти с равной громкостью, без перекосов. Именно для таких вещей (трансляция по радио/видео) и применяется нормализация, чтобы не было перекосов.
Храните в базе IP и время доступа. При каждом обращении к сайту с этого IP обновляйте время доступа.
Увеличивайте счетчик только если последний раз с этого IP заходили более 1 часа/1 суток/1 недели назад.
Сейчас НИКТО, повторяю, НИКТО не пишет на языках программирования. Синтаксис большинства популярных языков программирования настолько схож, что изучить 3-5 языков можно за пару недель.
А вот зание библиотек, движков, фреймворков, опыт работы с инструментарием - это годы реальной работы, а не института. Поэтому те, кто утверждают, что они знают язык программирования походив на курсы - сперва подтвердите это, пройдя тех. интервью и устроившись в нормальную фирму хотя бы джуниором. Я уж не говорю про мида.
Вы же написали, что у вас 1К приборов настроены на какой-то конкретный IP.
Значит эти приборы умеют пользоваться TCP-IP и у них указано, что связаться с адресом x.x.x.x напорт yy и отправить инфу. Так?
Вместо этого, настроить их, чтобы было указано связаться с адресом pribor1.mycompany.com порт yy.
Прописать, чтобы pribor1.mycompany.com разрешался как x.x.x.x можно уже со стороны DNS сервера.
Все. Надо сменить IP - сменил на DNS сервере, а на приборе ничего настраивать уже не нужно.
Ну или как я писал выше временно поднимите VPN и перенаправляйте все на внутренний IP адрес второго сервера.
Тем более, давно следовало все перевести на DNS, и тогда никуда больше не придется ехать. Причем никто не мешает создать хоть 1к a-записей в DNS, чтобы сидя на гаваях перенаправлять трафик конкретного прибора даже не включая его )
densomart: Ну может ему тогда перед программированием пройти курсы по таймменеджменту и обычной логике? Может я немного ошибаюсь, но джуниор - это уже взрослый сформировавшийся человек, у которого должно быть достаточно знаний для решения вопросов. Можно помочь в первые пару недель, приставить куратора, но затем уже выясняется проблема не отсутствия знаний, а некорректному подходу к решению проблем вообще.
dozent: С точки зрения любого человека, он должен адекватно понимать хватает ли времени для решения задачи в процессе разбирательства.
Во всяком случае я дал свое мнение на вопрос - Инициатива что делать должна исходить от Junior-а, который должен уметь манаджить свою задачу и сроки. Это краеугольный камень командной работы.
Если будет видно, что человек не заперся и не бьется лбом в стену а что-то спрашивает, то задача будет или решена в срок, или о том, что она не решится в срок будет известно задолго до.
Для того, чтобы понять насколько человек умеет расставлять приоритеты вполне хватает испытательного срока, за который человек успеет решить несколько задач под усиленным присмотром, а дальше - он должен быть самостоятельным работником, который отвечает за свою область, и совершенно не важно какая квалификация нужна в данном случае.
А если senior не успеват по срокам, какие тогда действия?
Квалификация вообще не имеет значение, если разговор идет о том, что кто-то не успевает в срок. Для этого нужно чтобы человек сам сообщал о проблемах.
В диспетчере задач можно выставить affinity для процесса. Но по умолчанию все ядра доступны всем процессам, там обычно наоборот уменьшают доступ.
При выполнении программы процессор не только постоянно что-то считает, но также может ожидать ответа от различных устройств - от памяти, от клавиатуры, от микросхемы таймера и другие прерывания. В это время он не нагружен.
Например пока отрисовывается новый кадр, напрягается видекарта, а процессор простаивает. Так и у вас - процессор достаточно мощный, чтобы со своей задачей справлялся используя 33% мощности. Больше или не нужно для выполнения задачи, или тормозит другое устройство.
Николай Шепелев: Для вас много информации оказалось причиной не прочитать ничего?
Вся информация более-менее годная. Просто почитайте несколько статей и начнете ориентироваться.
В крайнем случае, могли бы поискать ваш вопрос прямо тут на тостере. Только за последние 2 месяца видел его раза два-три. С готовыми ответами.
Много тяжелых сложных отчетов, возможно поискать решение без sql, или оптимизировать сами запросы.
Невозможно сделать универсальную быструю CMS, все затачивается под конкретный тип использования.
Поищите удачный профайлинг и делайте нагрузочные тесты, имитируйте пользователей, увидите где затыки.