Help - Search - Member List - Calendar
Full Version: Личные баннеры
АК-форум > Главный форум > Рейтинг Комиксов > Новости рейтинга
Swamp Dog
У авторов, зарегистрировавших свои комиксы и переводы в рейтинге, появилась возможность размещать на страничке "Баннеры" баннеры собственного изготовления. Все желающие могут писать заявки на e-mail. Пример того, как это будет выглядеть можно посмотреть здесь.
Kaita
Йее) Спасибо, кстати)
Swamp Dog
Обращайся. Извини, что так долго
carte
Есть такая идея: почему бы не сделать кнопочки, на которых будет отображаться позиция комикса в рейтинге.

То бишь, чтобы можно было зайти в нужный раздел рейтинга, копировать оттуда код и вставить в нужное место на свой сайт или в блог. При открытии страницы сайта или блога с кнопочкой идет запрос к ТОПу и оттуда возвращается картинка с номером позиции. Как счетчики ливинтернета и подобных.

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

Вот такие кнопки участники могли бы использовать в качестве баннеров для голосования.

Может быть, как доп возможность, участники могли бы предоставить свой шаблон баннера с пустым местом для числа.
carte
А идею про баннеры на странице http://top.a-comics.ru/banners.php?cid=11 я не понял...

У большинства участников рейтинга, скорее всего, есть свои кнопки. Они используют их на своих сайтах.
Какой смысл размещать код добавления этой кнопки здесь?
Чтобы кто-то из других посетителей топа мог их добавить к себе на сайт?
Swamp Dog
Сделано по просьбе Каиты smile.gif
1) Хостинг.
2) Автоматически генерируется код и можно его просто копировать
3) Давать ссыли другим людям

Насчёт кнопки с текущим рейтингом - у нас всё-таки не отдельный сервер под сайт выделен, мощности, по моим прикидкам, не слабые нужны... Или хитрая оптимизация. Рейтинг ведь позицию комикса не хранит где-то в таблице, а высчитывает каждый раз.
Kaita
QUOTE(carte @ Oct 8 2009, 23:33)
Какой смысл размещать код добавления этой кнопки здесь?


Складывается такое ощущение, что когда делается нечто для дополнительного удобства, это внезапно обязывает всех срочно им воспользоваться.
Swamp Dog
Подозреваю что вопрос изначально связан с тем, что я тратил время на это а не на что-нибудь /другое/.
cart
Kaita

Вопрос связан только с желанием во всем искать смысл. Смысл найден. Спасибо smile.gif

QUOTE(Swamp Dog @ Oct 9 2009, 00:45)
Насчёт кнопки с текущим рейтингом - у нас всё-таки не отдельный сервер под сайт выделен, мощности, по моим прикидкам, не слабые нужны... Или хитрая оптимизация. Рейтинг ведь позицию комикса не хранит где-то в таблице, а высчитывает каждый раз.



А почему, кстати, позиция высчитывается каждый раз?

Сколько обращений в сутки на просмотр страницы рейтинга?
-- Уже 12 тысяч хитов. Значит в сутки 15-20 тысяч.
А сколько подается голосов в сутки?
-- на данный момент 243. Допустим, в активный день их 500 или даже 1000. Достаточно пересчитывать позицию только после каждого нового голоса --- и это снизит нагрузку в 20-40 раз.

Да и после каждого голоса позиция не так уж произвольно меняется: только один комикс может всплыть пузырьком на пару позиций повыше. Так что и пересчет при добавлении голосов должен быть небольшим.

* *

А вот когда позиция комикса будет храниться в таблице и получаться одним запросом к базе данных, нагрузка на сервер должна быть не такая уж и большая.

* *

Хотя я рассуждаю не зная 1) на сколько дольше выполняется запрос к БД по сравнению с запросом просто к картинке на вашем сервере.
2) На сколько будет нагружать сервер скрипт, который будет генерировать картинку с номером позиции.
Так что, возможно, выводы не точны.

Если нагрузку на сервер будет создавать именно пункт 2 (скрипт генерации), то, как вариант, можно было бы предложить этот скрипт размещать у себя желающим заиметь кнопку. Тогда
а) Все равно нужно будет посылать запрос на сервер top'а, чтобы получить номер позиции.
б) Это подойдет не всем, так как понадобится доступ к серверу с возможностью размещать скрипты. Но это вряд ли проблема: я бы, например, рискнул разместить такой скрипт у себя, если бы к каждой кнопке прилагалась ссылка на мой сайт.


Приписка:
Как другой вариант можно было бы вообще не генерировать картинку, а выдавать текст со вставленным нужным номером.
cart
Понял одну ошибку в своих рассуждениях: Счетчики, видимо, на весь сайт, а не только на страницы рейтинга. Так что число просмотров страницы именно с рейтингом мне не известно.

А сколько этих просмотров?
Duke
QUOTE(cart @ Oct 9 2009, 17:59)
А вот когда позиция комикса будет храниться в таблице и получаться одним запросом к базе данных.
Не будет ли слишком грубо если я скажу РТФМ, точнее предложу поглубже изучить теорию баз данных? Такая таблица - это денормализация схемы, что в переводе на русский означает "очень, очень плохо". Правильный ответ в данном случае - вьюха. И делать ли ее материализованной или нет (кстати не разу не сталкивался с материализованными вьюхами в мускле) чтоб думать об её оптимизации - не такой вопрос, который можно прикинуть на пальцах по количеству хитов. Надо смотреть план запроса, кардинальность-стоимость-селективность. Сам запрос, опять-таки оптимайзить.

QUOTE
можно было бы предложить этот скрипт размещать у себя желающим заиметь кнопку. Тогда
а) Все равно нужно будет посылать запрос на сервер top'а, чтобы получить номер позиции.
Мда уж, мрак в технологиях у вас, cart, мрак. Работа с базой происходит только с локального хоста. Давать доступ к базе из инета - да еще и открытый - капитальная угроза безопасности. Ладно еще умельцы ДДосят веб-сервера, тут можно будет сам сервис базы уронить банально нагрузкой. И это еще не говоря о том, что у нас виртуальный хостинг, т.е. на физическом хосте и совсем другие сайты крутятся, никто нам не даст базу в инет высунуть.
QUOTE
Как другой вариант можно было бы вообще не генерировать картинку, а выдавать текст со вставленным нужным номером.

Я не против на самом деле и gd заюзать, картинкой так картинкой.

А по поводу нагрузки решается эта задача банально - кеширование. Грубо говоря, картинка будет генерится не на каждый хит, а раз в полчаса, и если время refresh-a еще не пришло - браться из кеша.
cart
Давайте рассуждать спокойно и по пунктам.
Во-первых, я несомненно не читал это факин мануал. Да я и не утверждаю ничего. Я задаю вопрос: а почему бы не сделать так? А если не так, то эдак?

QUOTE(Duke @ Oct 9 2009, 21:34)
Не будет ли слишком грубо если я скажу РТФМ, точнее предложу поглубже изучить теорию баз данных? Такая таблица - это денормализация схемы, что в переводе на русский означает "очень, очень плохо".



"Плохо" в моем понимании, это когда что-то становится плохо. А плохо, потому что что-то там как-то называется --- это догма, в которую надо свято верить.

Я же не призываю, как-то переделывать вашу БД, внося туда лишние данные или изменяя структуру. А вот добавить _вспомогательную_ таблицу ИД_комикса - позиция_в_рейтинге не понимаю, как может повредить структуре.

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

QUOTE(Duke @ Oct 9 2009, 21:34)
Мда уж, мрак в технологиях у вас, cart, мрак. Работа с базой происходит только с локального хоста. Давать доступ к базе из инета - да еще и открытый - капитальная угроза безопасности. Ладно еще умельцы ДДосят веб-сервера, тут можно будет сам сервис базы уронить банально нагрузкой. И это еще не говоря о том, что у нас виртуальный хостинг, т.е. на физическом хосте и совсем другие сайты крутятся, никто нам не даст базу в инет высунуть.



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


Duke
QUOTE(cart @ Oct 10 2009, 03:20)
В базах данных не специалист
Именно об этом я и говорю. Есил вы не разбираетесь в впоросе, то сами того не понимая говорите совершеннейшие глупости.

Так или иначе, как уже сказал выше, я не против заюзать gd и сделать такие картинки. Уж в технических вопросах производительности разберусь и вам, как клиентам рейтинга по-моему даже задумываться о них не стоит. С изначальным высказыванием Энта "ой, это такая нагрузка, не-не-не" я не согласен.

Потребудется картинка с пустым местом для числа.
cart
Давайте, не будем доказывать мне, что я ничего не понимаю в БД, раз уж я уже с этим согласился.

А если на это счет мы сошлись, то не могли бы вы пояснить по какой причине пересчет позиции рейтинга динамически на каждый запрос на просмотр оказывается лучше (быстрее, безопаснее, экономичнее...), чем хранить список позиций и подправлять при появлении новых голосов? Уверен, суть проблемы можно описать в нескольких предложениях.
Duke
Потому что хранение одной и той же информации в разных местах может привести к логическим ошибкам и потере целостности.
Нормализация
Вьюхи
Swamp Dog
Ну вы ещё подеритесь, горячие финские парни... Конструктивные предложения с обоих сторон воспринял, возможности реализации обдумаю.
cart
QUOTE(Duke @ Oct 11 2009, 15:50)
Потому что хранение одной и той же информации в разных местах может привести к логическим ошибкам и потере целостности.
Нормализация
Вьюхи



В этой дискуссии вы первый использовали слово "кэш". Так вот кэш - это типичные избыточные данные:

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


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


Серьезные ошибки могут возникнуть, если считать и основную базу и временное хранилище позиций одинаково авторитетными. Если же авторитетные данные хранятся только в нормализованной БД, а временное хранилище играет сугубо вспомогательную роль и используется лишь для ответа на частые запросы о порядке позиций в рейтинге (и время от времени обновляется данными из главной базы), то проблем быть не должно.
Duke
Я имею против этого вьюху с этими данными.
Меня попросили не продолжать эту дискуссию. Если хотите, обсудим в другом месте.
cart
Не продолжать мне не трудно, но и в другом месте продолжить не против.
Я просто кинул идею, которая кажется интересной и от которой я лично ничего не выигрываю. Соответственно стало непонятно, почему получил такой агрессивный ответ без какой-либо внятной аргументации.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2024 Invision Power Services, Inc.