И пример с конфигами конечно вообще
Какие затраты на парсинг конфигов, вы о чём вообще? У вас конфиг ЭВМ на атомных станциях или форум с интернет-магазином? Вы вообще на каком языке сайты пишите, скажите мне? Он сам по себе есть расход лишней памяти и ресурсов в угоду простоты написания кода.
Всегда лежит у всех в кэше, при изменении перетряхивается кэш. Хоть в json, хоть xml, хоть текстом, хоть в ноликах с единичками хранить: отдаётся то массивом из кеша всегда. У того же ZF к слову в ядре методы для работы с любым типом конфига.
Скажи мне, какого хрена она в дефолте на "HelloWorld" схавала у меня 20 метров памяти?
И это не сделав ни единого запроса в БД, просто выведя в контроллере фразу "Привет мир".
А что будет дальше?
Ну это извечная проблема. Пишем мало ручками: памяти на поддержку всего хозяйства больше. Пишем всё ручками - ресурсы железа затрачиваются такие как мы хотим. В нормальных FV и ZF в частности нужно просто оптимизировать правильно всё хозяйство: отдавать статикой используя кое-где статические экшены, задействовать кеширование, оптимайзер в конце концов. И тогда всё там нормально работает и лишнего не кушает. Что-то кушает конечно, но плюсы минусы покрывают. А если разница в том что он просто памяти ест на 20 или 50 мб (при условии конечно, что это не баг и не течёт память) больше чем велосипед, то хрен с ними с этими мегабайтами! Проще поставить лишнюю плашку памяти и сосредоточить усилия на том, что действительно надо писать ручками, чем пилить свой велосипед неделями.
Понятно что "бла-бла-бла крупные проекты под хайлоад надо писать руками или отказыватсья на хайлоад коде от всяких FV" (мб проект вообще не для пыха тогда?), но на том же ZF сделана та же Magenta, а это весьма серьёзное решение и популярное для коммерческого хайлоада (за бугром по крайней мере).
В продолжении задачи.
Позже выяснилось, что таких параметров, как weight, для которых нужна группировка, оказывается ещё 2.
Не нашёл ничего лучше, как сделать отдельные запросы с их подсчётом чтобы не городить огород:
минус понятен: склеивание массивов в пыхе для дальнейшего обхода.
weight_3,' (',count(0),')')AS weight_3_sep FROM tbl_name WHERE weight_3 != 0
GROUPBY post_id, weight_2
) ws
GROUPBY post_id
Плюс в том что в этих запросах можно исключить нулевые значения WHERE weight_3 != 0, в отличии от первого запроса ибо там !=0 использовать нельзя чтобы банально получить все post_id.
Ну это всё рассуждения и тп о том что лучше и как лучше было бы по феншую, а из практики вот могу сказать, - федеральный проект, воркеры пишутся на пыхе на готовой обвязке и мастере и работают без каких либо проблем. И предпочитают расход лишних 10 мб памяти вместо того чтобы писать и поддерживать код на нескольких языках для простых регулярных задач.
Нод юзается для своих задач но никак не для указанных.
ну демоны и воркеры на ПХП ИМХО не самая лучшая идея. тот же сокет сервер на ноде куда продуктивней. но помниться DeepVarvar запускал демон и он стабильно работал
Приплыли. А на чем вы воркеров будете писать для регулярных задач по серьёзному проекту с посещяемостью, на плюсах чтоли всё?
Есть тот же счетчик просмотров поста, вы что с контроллера будете в редис просмотры записывать при запросе страницы поста чтоли? У вас тогда при любом сбое ложится просмотр поста. И что вы для этого будете нод поднимать на отдельной железке или на плюсах писать воркера и потом поддерживать всё это хозяйство? Я вам отвечу - не будете. Разве что для своей поделки но не для серьёзного проекта под который просто так вы для такой задачи сервер не получите и тем более вам не дадут крутить нода на боевом сервере. Потому что для этого вам нужен в штате программист на плюсах и под нод. А с последним только тривиальные задачи решаются просто, уверяю вас. Там такие могут быть закидоны с утечками памяти с которыми чтобы разобраться нужно быть разрабочтиком на серверном js и знать node глубже чем по общему ману.
Вполне нормально решаются на пыхе такие задачи. Рассылки уведомлений, создание событий и т.д.
Здравствуйте форумчане. Я уже поднимал похожую тему, но столкнулся с тем что записывать IP в базу и привязывать к нему уникальность нет смысла, потому как например у нас с соседом один IP и получается проголосовать может кто то один из нас, это если организовывать какую то уникальность при просмотрах или голосовании.Куку ставить,тоже можно их стереть да и накрутить просмотры. Какие может еще есть варианты? сразу скажу что привязки к аккаунту нет, даже обычные посетители могут голосовать. Спасибо заранее за советы.
От накрутки нас может спасти только авторизация. Всё остальное технически не сложно накрутить. Пишите ip - массовую накрутку школьниками это усложнит и только. Авторизацию на сайте к слову использовать совершенно не обязательно: используйте идентификацию через соцсети - нормальное решение.
Если уж стали делать названия на латинице то делайте без цифр зачем вам они:
articles/nazvanie-statii
А вообще ерунда это всё и баловство. Адреса у гугла видели?
Короткий url по возможности не глубже двойной вложенности и нормально. Главное уяснить что само по себе articles/1-nazvanie-statii articles/nazvanie-statii-1 или articles/nazvanie-statii совершенно никак не влияет на ваши seo-показатели. В общем смысле если число не часть названия то в url включать его не нужно.
Нет NN они.
Примерно к такому и пришёл только исключив вес '0'.
Тут окончательно можно судить об эффективности только агрегируя большой лог. Потестирую на бою, посмотрим что покажет.
Изначально когда только ставилась задача был против такой структуры. Ибо имхо тут в разы проще хранить просмотры по весам в отдельной таблице, а осталньые статусы просто суммируя с группировкой по id. Единственный минус это join конечно будет.
Пусть есть таблица просмотров поста юзерами на определённом статусе. Задача получить количество просмотров поста по статусам. при этом для всех статусов при просмотре в лог пишется 0 или 1 и их считаем простым sum, а для учета веса юзеров смотревших пост (1 - 40) в таблицу просто пишется сам вес (1-40) и нужно в агрегированной записи выборки получить сгрупированные значения просмотров: "вес (кол-во)" по каждому имеющемуся для поста весу
+--------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+--------+-------------+------+-----+---------+-------+
| post_id | int(11) | YES | | NULL | |
| current_week | int(2) | YES | | NULL | |
| status1 | int(1) | YES | | NULL | |
| status2 | int(1) | YES | | NULL | |
+--------+-------------+------+-----+---------+-------+
даёт выборку:
'210', '5', '0', '15(0), 0(0), 20(0), 1(0), 15(0), 20(0)'
Соответственно вместо '(0)' и дублирующихся значений веса хотелось бы получить их количество максимально лаконичным способом.
Кроме этажных подзапросов ничего не приходит в голову.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 2118
