big bond wrote:
> Я прочел раз шесть наверное )
> А смысл в том, что когда у толстого приложения пик, оно съедает свои
> бекенды и залезает на дополнительные, у тощих приложений критичность
> низкая, им можно и лагать иногда, толстое же - флагман, оно должно
> всегда быть на высоте.

Так и отдайте ему все бекенды, пусть оно там живет. Если проблема в том,
что бекендов не хватает на пики обоих приложений и нужно приотеризацию
сделать, то тогда это не подходит, но и проверка бекенда GET-ом у
железного балансировщика тоже это не решит. Тут можно разве что лимитом
коннектов поиграться, но скорее все же тут нужен умный бекенд, который
будет принимать соединения на тяжелое приложение с приоритетом.


> Кроме всего прочего, способ проверки живости
> бекенда путем GET'а определенного URL имеет и другую полезную
> особенность - можно проверить живость и отклик не только веб-бекенда, а
> целиком системы appserver+dbserver, дёрнув нужный URI.

Ну для этого есть системы мониторинга, которые должны проверять эти и
другие вещи и что-то делать - от пометки бекенда мертввым то его ребута.




_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru