Во-первых, этой теме нечего делать в разделе "Яндекс".
Во-вторых, не надо нести чушь про "вот фишинг и до России добрался". Такие или другие письма идут постоянно - как пользователям Яндекс.Денег, так и пользователям PayPal, eBay, Amazon и т.д. - любых систем, где можно что-то сделать с деньгами через веб-интерфейс.
Что, предлагаете на сайте Яндекса написать про подобные вещи? Тот факт, что вы это предлагаете, ярче всего доказывает, что такое писать бесполезно.
#Никогда не открывайте сайты по ссылкам, потому что существует множество способов фальсифицировать адрес. Вместо этого введите URL (адрес сайта) напрямую в адресную строку вашего браузера; #Платежный пароль можно вводить только на сайте Яндекс.Денег. Проверяйте адрес в адресной строке браузера.
Вы этого не прочли - но считаете своим правом давать советы Яндексу, что ему где написать. Что, так хочется почувствовать себя умным после того, как ввели платежный пароль на левом сайте?
T.R.O.N: Отказаться , в особо нагруженных задачах, от скриптов, переведя часть кода в исполняемые(бинарные) файлы.
У меня есть ощущение, что бинарники будут работать не на порядок быстрее, чем прекомпиленный код php-скрипта с Апачем. Тем более, что на время ответа mysql, например, это мало повлияет.
Гораздо эффективнее может оказаться переход с mod_php на FCGI-решение.
FixGuitar: Всё верно, это один из путей снижения нагрузки. Но как говориться, одно другому не мешает. Наша тема о том какие варианты снижения нагрузки существуют/доступны, а какие из них выбрать это уже дело владельца сайта. А Вы, я так понимаю, сейчас ищите оптимальный метод снижения нагрузки. Не об этом у нас речь.
Ладно, открою большую тайну менеджеров. Если в процессе эксплуатации сайта вдруг выясняется, что написанный некоторое время назад код не позволяет серверу выдержать нагрузку и причина действительно именно в коде или архитектуре софта, которая не позволяет его масштабировать - разработчика сервиса надо расстрелять, а сервис выбросить.
В остальных случаях проще и дешевле масштабировать сервис и использовать прозрачные для кода серверные решения.
Например:
Для MySQL:
- увеличение буферов.
- построение индексов.
- отслеживание long-queries.
- включение кэша запросов.
Для Апача + PHP
- установка любого из акселераторов. Рекомендую XCache.
- поддержка keep-alive.
- разумные таймауты.
- gzip. Нагрузка на процессор растет не очень сильно, а вот время отдачи=время существования процесса сильно уменьшается.
- вынос всей статики из-под апача - пусть nginx ее отдает, он маленький и быстрый.
- вынос всех скриптов и стилей из кода, генерируемого апачем, в отдельные файлы - пусть это отдает nginx.
Очень рекомендую memcached - правда, скрипт должен уметь с ним работать.
Дальше можно говорить о масштабировании - например, вынести mysql-сервер на отдельную машину. Наладить репликацию баз и использовать реплицированную базу для некритичных операций. Ну, например, на этом форуме можно среплицировать базу и весь поиск проводить только на реплике.
По мере роста проекта увеличить число веб-серверов и поставить перед ними load balancer или хотя бы round-robin DNS настроить.
Короче, есть еще масса способов выдерживать нагрузку, не трогая код.
Сообщу также, товарищ программист, что ваша тема вами же размещена в разделе "Администрирование серверов" - поэтому, извините, но говорить здесь мы будем о настройках серверов, а не о переписывании проектов.
Поэтому для него есть только один способ - сесть и начать переписывать код.
А такие скромные меры, позволяющие учетверить переносимую нагрузку, как оптимизация размеров буферов mySQL, включение Query Cache, установка разумных Expires для статических элементов страниц и так далее - это все слишком просто. Нормальные герои всегда идут в обход.
DrJeans: Т.е. другими словами - это плюс Яндекса, т.к. он зафильтровал дубли?
Нет. С точки зрения пользователя, эти результаты однозначны - все они содержат одно и то же словарное описание термина.
Причем на первой странице Google сообщает о 162 результатах, а на второй - о 15. Все остальные, видимо, даже для Гугла одинаковые.
Artisan: Вы предлагаете сжечь лишние книги в которых есть одинаковые слова?
Я предлагаю не говорить чушь. Если пользователь приходит в библиотеку за стихами Пушкина, это не повод выдавать ему 50 разных изданий "Руслана и Людмилы", объясняя, что вот тут первая буква иначе нарисована, бумага для печати из разных партий, а вот это издание держал в руках лично директор библиотеки.
Знакомый, который к SEO вообще отношения не имеет
А ларчик просто закрывался...
А вот хамить мне не надо. Отдохните пока.
Во-первых, этой теме нечего делать в разделе "Яндекс".
Во-вторых, не надо нести чушь про "вот фишинг и до России добрался". Такие или другие письма идут постоянно - как пользователям Яндекс.Денег, так и пользователям PayPal, eBay, Amazon и т.д. - любых систем, где можно что-то сделать с деньгами через веб-интерфейс.
Что, предлагаете на сайте Яндекса написать про подобные вещи? Тот факт, что вы это предлагаете, ярче всего доказывает, что такое писать бесполезно.
Потому что это там ДАВНО НАПИСАНО:
#Платежный пароль можно вводить только на сайте Яндекс.Денег. Проверяйте адрес в адресной строке браузера.
то что есть интернетом назвать нельзя: открывается только Яндекс, этот сайт
Я вас попрошу... А что еще ценного в интернете есть?
Отказаться , в особо нагруженных задачах, от скриптов, переведя часть кода в исполняемые(бинарные) файлы.
У меня есть ощущение, что бинарники будут работать не на порядок быстрее, чем прекомпиленный код php-скрипта с Апачем. Тем более, что на время ответа mysql, например, это мало повлияет.
Гораздо эффективнее может оказаться переход с mod_php на FCGI-решение.
Всё верно, это один из путей снижения нагрузки. Но как говориться, одно другому не мешает.
Наша тема о том какие варианты снижения нагрузки существуют/доступны, а какие из них выбрать это уже дело владельца сайта.
А Вы, я так понимаю, сейчас ищите оптимальный метод снижения нагрузки. Не об этом у нас речь.
Ладно, открою большую тайну менеджеров. Если в процессе эксплуатации сайта вдруг выясняется, что написанный некоторое время назад код не позволяет серверу выдержать нагрузку и причина действительно именно в коде или архитектуре софта, которая не позволяет его масштабировать - разработчика сервиса надо расстрелять, а сервис выбросить.
В остальных случаях проще и дешевле масштабировать сервис и использовать прозрачные для кода серверные решения.
Например:
Для MySQL:
- увеличение буферов.
- построение индексов.
- отслеживание long-queries.
- включение кэша запросов.
Для Апача + PHP
- установка любого из акселераторов. Рекомендую XCache.
- поддержка keep-alive.
- разумные таймауты.
- gzip. Нагрузка на процессор растет не очень сильно, а вот время отдачи=время существования процесса сильно уменьшается.
- вынос всей статики из-под апача - пусть nginx ее отдает, он маленький и быстрый.
- вынос всех скриптов и стилей из кода, генерируемого апачем, в отдельные файлы - пусть это отдает nginx.
Очень рекомендую memcached - правда, скрипт должен уметь с ним работать.
Дальше можно говорить о масштабировании - например, вынести mysql-сервер на отдельную машину. Наладить репликацию баз и использовать реплицированную базу для некритичных операций. Ну, например, на этом форуме можно среплицировать базу и весь поиск проводить только на реплике.
По мере роста проекта увеличить число веб-серверов и поставить перед ними load balancer или хотя бы round-robin DNS настроить.
Короче, есть еще масса способов выдерживать нагрузку, не трогая код.
Сообщу также, товарищ программист, что ваша тема вами же размещена в разделе "Администрирование серверов" - поэтому, извините, но говорить здесь мы будем о настройках серверов, а не о переписывании проектов.
Н-да, форум сдох...
Не понял вашей дурацкой реплики...
Вы будете смеяться
Он не будет смеяться, он программист.
Поэтому для него есть только один способ - сесть и начать переписывать код.
А такие скромные меры, позволяющие учетверить переносимую нагрузку, как оптимизация размеров буферов mySQL, включение Query Cache, установка разумных Expires для статических элементов страниц и так далее - это все слишком просто. Нормальные герои всегда идут в обход.
Т.е. другими словами - это плюс Яндекса, т.к. он зафильтровал дубли?
Нет. С точки зрения пользователя, эти результаты однозначны - все они содержат одно и то же словарное описание термина.
Причем на первой странице Google сообщает о 162 результатах, а на второй - о 15. Все остальные, видимо, даже для Гугла одинаковые.
Вы предлагаете сжечь лишние книги
в которых есть одинаковые слова?
Я предлагаю не говорить чушь. Если пользователь приходит в библиотеку за стихами Пушкина, это не повод выдавать ему 50 разных изданий "Руслана и Людмилы", объясняя, что вот тут первая буква иначе нарисована, бумага для печати из разных партий, а вот это издание держал в руках лично директор библиотеки.
greenwood, а в чем сакральный смысл показать пользователю в 40 раз больше одинаковых результатов?