Pull to refresh
3
0
ivertex @ivertex

User

Send message
Ок, все вроде так офигенно, но… Данный паттерн используется повсеместно и, к сожалению не является серебрянной пулей. Такие решения применяются для более узконаправленных типов данных, что как бы обоснованно (на основе данных профилированния). Но если говорить о строках, ребята настолько разнообразно ими пользуются, что сделать серьезно эффективнее чем strcmp или strcpy (ок, плюсовые варианты) ну нет, чудес не бывает. Либо память, либо такты. Ну либо более специализированные варианты, которые привели выше.
Я для краулера использовал librcd, либа давала очень хорошие результаты и работало шустро (принцип работы видимо тот же). Написал обертку к php и пользовал.
Где бы можно было применить этот продукт?

Например студентам показывать как не нужно писать на c++ ;)
Я бы поигрался с возможностью трансляции в другие языки (например c -> php/python).
А вообще интересно было бы проследить сколько протяните в режиме «все сам» ;)
)))) что есть, то есть
Не совсем понимаю о чем вы, в выдаче все треки имеют прямую ссылку на скачивание. Т.е. никаких редиректов и т.п. если вы об этом.
Все как было, ничего не меняли вроде)
tagoo.ru — медийный поисковик
А так? ;)
Не проапдейтили подсказки еще, это да, эт плохо.
tagoo.ru хех, молодцы ;)
Странно, ведь даем инструмент, возможно интересный для пользователей вашего проекта. Это не выгодно для вебмастера? Гнать траф таким образом, не договорившись с вебмастером было бы очень нагло… На счет встроенной рекламы, мы работаем над этим. В любом случае, спасибо за отзыв ;)
Кармы, чтобы запостить в Я пиарюсь не хватило ;)
Пробуйте tagoo.ru. А бороться с вконтакте бесперспективно конечно, да и не нужно, как написали выше.
Все тут упирается в вопрос, как вы масштабируетесь. Если вы покупаете вместо виртуального хостинга выделенный сервер, это одно (для этого половина ваших советов не принципиальна). Если к выделенному серверу покупаете еще один под базу, то почти все ваши советы (кроме оптимизации запросов и модреврайтов на статику) не принципиальны. Если вы масштабируете двух серверную архитектуру, то правила у вас уже будут другие)).
Про индексы, как уже высказывались, вы не правы. Тот же InnoDB спасает по вопросам лока.
А про кэш — это опять же говорили уже, отдельная и весьма объемная тема.

Вывод: давать такие советы нужно в контексте архитектуры, чтобы понятна была среда (сколько серверов, где мускуль, есть ли распределенная бд или фс, сколько даунлоадеров или все это просто один виртуальный хостинг).
Да, кэширование мускуля то же самое делает. Если мускуль на другом сервере, может немного сэкономите на сети. По факту же, скорее всего ток проиграете на таком кэшировании. Слежка за изменениями таблицы тоже требует запросов (не важно тригеры это или просто кверики проверяющие количество или стампы).
Файловое кэширование тут накладнее, как в разработке, так и в процессинге. Если вы имеете ввиду регенерацию файлов кэша при заходе пользователя, то тупить будет для множества пользователей. Если апдейтить все кэш файлы раз в час например, то это гораздо накладнее, чем пересобрать таблицу. Согласен, что будь все это готовыми закэшированными блоками было бы еще быстрее, но пользы от кэш таблиц как правило больше, потому что на них могут опираться сразу множество утилит. Нафига листинг — этот вопрос решают обычно не разработчики ;). Мое мнение, каталог есть каталог, хоть 100 тысяч, хоть миллион.
Когда делали mp3.ru, лечили кэш таблицами. Варианты с листингом ста тысяч треков постранично с сортировкой даже по одной таблице уже тупит ближе к концу, а если джойнить то работать будет до первой тысячи посетителей. Крон тулзы, собирают кэши каждые 5,10,30 минут, заранее отсортированными и денормализованными и все ок ;).
1

Information

Rating
Does not participate
Location
Россия
Date of birth
Registered
Activity