1) несколько нагруженных социальных сетей, это сколько загрузок в день?
2) машинка была куплена с огромным количеством оперативной памяти для кеширования и не одним процессором + никто не говорит, что машинка одна
3) я вас уверяю запустив глючной код на любом количестве машин он будет тормозить
4) главный вопрос, вы никогда не пробовали создавать популярные сервисы за СОБСТВЕННЫЕ ДЕНЬГИ?
Под купить машинку я подразумевал покупку сервера, а не его аренду
Под качественными программистами я имел ввиду не студентов, а людей со большим ОПЫТОМ работы. Насчет простенького сервера не знаю, не давно покупали сервер стоимостью где-то в районе 6-8 тыс. $ для проекта с высокой посещаемостью. Чаще всего весь код оптимизировать не надо, не все сценарии работы с системой являются часто используемыми. А для остального есть профайлер. Можно выяснить узкие места и заострить внимание на них
В свое время занимался такой штукой
рассматривал как источник alexa.com, там есть нереатор скриншотов по урлу
Однако если целью является написание программы, которая делает все сама, можно легко найти нужное в исходниках kde
А что вам мешает в БД создать два поля, дата создания записи в кеше и дата изменения записи
По поводу использования кеша, вы можете создавать кеш с устареванием, если данные кеша устарели, то пересоздать запись
ну стоимость 1 машинки соизмерима со стоимостью 2 месяцев работы хорошего программиста. Может лучше прооптимизировать приложение. Более того вы не учитываете оплату места в стойке, оплату питания и т.д.
Полностью с вами согласен, насчет того что узкие места в приложении это БД и коммуникации с другими сервисами.
Однако не стоит забывать и про скриптовую часть, а именно алгоритм реализации. Не даром же господин Кнут написал 3 том "Сортировка и поиск", более 10 видов сортировки, он же не написал, забейте на все...используйте сортировку методом пузырька, а когда будет тормозить - купите машинку
При загрузке страницы необходимо проверять, создан для нее кэш. если да, показываем из кеша (под кешом можно понимать какое-либо хранилище), если нет создаем в кеше
Кэширование может быть разным. например если страницы с неизменяемым контентом, перед веб-сервером можно поставить какой-нибудь кэширующий прокси, либо создавать прегенерированные страницы (в случае если такой страницы нет, то , например, ее создает перехватчик ошибки 404), либо сохранять в каком-нибудь другом хранилище
1) старые записи можно кэшировать спрятав web-сервер за каким-нибудь proxy (например squid). Либо
по поводу первого сомнительно, чтобы коннект к mysql-серверу, был быстрее чем коннект к memchache-серверу. Однако, если выборка маленькая, можно сохранять и в памяти
По поводу второго, ничто же не мешает учитывать сохраняемых размер данных внутри класса обертки и описать сборщик мусора самостоятельно
По описанию проблемы не понятно ваша ситуация соответственно предлагаемые решения будут пустыми. Опишите детально средний размер файлов и количество необходимых загрузок файлов за один запрос к веб-серверу
Всё хорошо. Однако к Yahoo данный сервис имеет весьма интересное отношение.
Внизу страницы читаем все права принадлежат Weather Channel (http://www.weather.com)
Там тоже можно зарегистрироваться, получить subscriberId и также получать погоду.
по-моему в sim-icq и плагине ForecastFox данные берутся именно таким способом.
А так мне кажется стоит информацию относящуюся к одной группе сделать объектом.
Например , данные по ветру, данные по атмосфере и т.д.
2) машинка была куплена с огромным количеством оперативной памяти для кеширования и не одним процессором + никто не говорит, что машинка одна
3) я вас уверяю запустив глючной код на любом количестве машин он будет тормозить
4) главный вопрос, вы никогда не пробовали создавать популярные сервисы за СОБСТВЕННЫЕ ДЕНЬГИ?
Под качественными программистами я имел ввиду не студентов, а людей со большим ОПЫТОМ работы. Насчет простенького сервера не знаю, не давно покупали сервер стоимостью где-то в районе 6-8 тыс. $ для проекта с высокой посещаемостью. Чаще всего весь код оптимизировать не надо, не все сценарии работы с системой являются часто используемыми. А для остального есть профайлер. Можно выяснить узкие места и заострить внимание на них
рассматривал как источник alexa.com, там есть нереатор скриншотов по урлу
Однако если целью является написание программы, которая делает все сама, можно легко найти нужное в исходниках kde
По поводу использования кеша, вы можете создавать кеш с устареванием, если данные кеша устарели, то пересоздать запись
Полностью с вами согласен, насчет того что узкие места в приложении это БД и коммуникации с другими сервисами.
Однако не стоит забывать и про скриптовую часть, а именно алгоритм реализации. Не даром же господин Кнут написал 3 том "Сортировка и поиск", более 10 видов сортировки, он же не написал, забейте на все...используйте сортировку методом пузырька, а когда будет тормозить - купите машинку
Кэширование может быть разным. например если страницы с неизменяемым контентом, перед веб-сервером можно поставить какой-нибудь кэширующий прокси, либо создавать прегенерированные страницы (в случае если такой страницы нет, то , например, ее создает перехватчик ошибки 404), либо сохранять в каком-нибудь другом хранилище
1) старые записи можно кэшировать спрятав web-сервер за каким-нибудь proxy (например squid). Либо
По поводу второго, ничто же не мешает учитывать сохраняемых размер данных внутри класса обертки и описать сборщик мусора самостоятельно
поменял
автор статьи написал, а я не проверил. Речь идет о методе save
а зачем вам это, может обойти с использованием другого решения?
а зачем вам это, может обойти с использованием другого решения?
ты на вход подаешь параметры запроса, а кеш определяет были ли такие и выдает контент
Внизу страницы читаем все права принадлежат Weather Channel (http://www.weather.com)
Там тоже можно зарегистрироваться, получить subscriberId и также получать погоду.
по-моему в sim-icq и плагине ForecastFox данные берутся именно таким способом.
А так мне кажется стоит информацию относящуюся к одной группе сделать объектом.
Например , данные по ветру, данные по атмосфере и т.д.