Простите - это цена за что, за кусок пластика с неясным статусом?
А ларчик просто закрывался...
А вот хамить мне не надо. Отдохните пока.
Во-первых, этой теме нечего делать в разделе "Яндекс".
Во-вторых, не надо нести чушь про "вот фишинг и до России добрался". Такие или другие письма идут постоянно - как пользователям Яндекс.Денег, так и пользователям 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 разных изданий "Руслана и Людмилы", объясняя, что вот тут первая буква иначе нарисована, бумага для печати из разных партий, а вот это издание держал в руках лично директор библиотеки.