винда и линукс в одной сети? надо сделать, чтобы в винде стоял в качестве default gateway - линукс, а на линуксе через iptables и NAT все разрулить.
А какого рода сервис на винде? HTTP? Не достаточно ли ему для определения ip клиента было бы X-Forwarded-For?
Надо смотреть, на что в вашем сайте идет основная нагрузка. Это место оптимизировать или добавить недостающих ресурсов (обычно +память или HDD->SDD). По мере роста проекта далее придется вынести базу данных на отдельный сервер и при необходимости создать несколько web-серверов с распределением нагрузки по ним (load balancer, round robin dns). Потом опять оптимизируете (memcached). Если и дальше не будете справляться с нагрузкой, то придется из базы данных делать кластер - разносить на несколько серверов и думать о дальнейшем пересмотре архитектуры проекта и его переписывании.
whois 178.154.161.29
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: this output has been filtered.
% To receive output for a database update, use the "-B" flag.
% Information related to '178.154.160.0 - 178.154.161.255'
% Abuse contact for '178.154.160.0 - 178.154.161.255' is 'abuse@yandex.ru'
inetnum: 178.154.160.0 - 178.154.161.255
netname: YANDEX-178-154-160
status: ASSIGNED PA
country: RU
descr: Yandex enterprise network
Это не претендент.
server {
listen 80;
server_name domain.com;
rewrite ^/(.*)$ https://domain.com/$1 permanent;
}
listen 443 ssl;
...
http://dev.maxmind.com/geoip/geoip2/javascript/
http://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites
http://www.joelonsoftware.com/items/2006/09/01.html
У меня всё работает.
Так не бывает, чтоб не переделывать "с самого начала". Поскольку Вы не знаете, с какими проблемами Вы можете столкнуться, то и написать сразу так, как нужно будет в будущем под неизвестные потребности - невозможно. Когда-то Вы все равно возьмете свой "пластилиновый комок", обросший костылями и выкинете вон. Либо умрете под грузом рефакторинга.
Отнеситесь к проекту пока как к прототипу. Сделайте первую версию проекта силами хорошего архитектора и дешевых разработчиков. Когда набьете шишки получите опыт - перепишете.
Масштабируемые проекты должны безболезненно горизонтально масштабироваться (т.е. производительность системы должна расти в идеале линейно в зависимости от количества серверов). На каком языке написан функционал - в большой степени не важно, а важно лишь, чтобы в систему была изначально заложена возможность горизонтального масштабирования. Т.к. оптимизацией ЯП вы всего-лишь сэкономите на количестве серверов, на ЗП программистам на экзотических технологиях вы вложите больше денег, чем на увеличение числа серверов.
Если проект взлетит так, что стоимость серверов начнет перевешивать затраты на программирование, код перепишете хоть на С++ - у вас уже будут для этого возможности :)
Вы имеете ввиду parallax scrolling?
