если можно, думаю, точно должен быть более оптимальный вариант
простой счетчик обращений:





цель - оптимизация с целью уменьшения нагрузки на сервер, сорри за каламбур

ЗЫ: заранее благодарю за ответы

Это сообщение отредактировал(а) PROme2 - 14.2.2006, 21:39

1. @ не там ставишь Вообще их убрать лучше, а вырубить вывод ошибок через .htaccess, к примеру.


ТО он у тебя как строка, то потом, как число...
Что это у тебя за переменная? Отсюда можно будет кое-что улучшить.

на mysql_query типа можно не ставить?


угу, но мне ваще надо бы чтобы их выводило... можно как-то только ошибки, связанные с бд отключить? ну в смысле сообщения о них


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


?


ну типа количество запросов с id таким-то

пасиба

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


Вообще-то все-таки важно.


Я бы на твоем месте == 0 проверял. Или <1.

угу, но в данном случае своя специфика есть



ну можно, хотя особой разницы не вижу
вообще меня больше волнует сторона БД

ну ладно, смотрю что особо ничего и сделать нельзя, если будет напрягать, тогда будем делать статистику посуточную, а не в риалтайме
пасиба за помощь

CTAPbIuMABP, земляк, спасибо
кстати, что делает оператор "==="? уже второй раз встречаю... суть ясна, а именно?

и что касается



и



мое большое ИМХО, мой вариант таки быстрее должен работать, обязательно устрою тестирование и отрапортую по результатам
аналогично и по UPDATE запросу, просто мне не ясно кто будет проводить инкремент, php или mysql?

такс, устроил тест по модифицированному инсерту, после 100 прогонов результаты:

минимум
среднее
максимум

мой вариант:

[34.2705]
[35.1326]
[36.1185]

модификация CTAPbIuMABP:

[30.9217]
[33.2995]
[34.1928]

что ж, скромный прирост, но резон провести такую примитивную модификацию есть, 5% на дороге не валяются, худший результат оказался даже чуть лучше моего лучшего

далее идет апдейт, я, кстати, вначале был немного невнимателен, ясен пень что в модифицированном варианте инкремент выполняет mysql

мой вариант:

[70.1257]
[72.4921]
[74.8306]

модификация CTAPbIuMABP:

[71.0656]
[72.8688]
[74.7647]

отличия нечтожны... а вот модификация апдейта - `count`=`count`+1 вызвала у меня желание убрать $CUR_ART_VIEW_COUNT, а для проверки наличия соотв. id в табличке применить mysql_num_rows... к сожалению, опять же ничтожное приемущество, доли процентов, можно сослаться на погрешность эксперементов... просто селект забирал порядка 95-97% времени, что уж тут поделаешь...?

также добавление к апдейту убранного LIMIT 1 ничего явного не принесло, снова доли процентов, полагаю это заслуга структуры бд - UNIQUE KEY `article_id`

ЗЫ: CTAPbIuMABP еще раз благодарю за помощь

Это сообщение отредактировал(а) PROme2 - 22.2.2006, 03:07

Наздоровье) если не жаль репутации подкинь ;)

Оператор === читается как эквивалентно тоесть, если у тебя строка


и ты не знаеш зарание будет ли $var string или integer можно писать так


тоже самое, если у тебя

можно писать


Добавлено @ 12:35
кстати на форуме dklab.ru меня научили еще более извращенному приему



но вот так нельзя



потосму что константу сравнивать можно, а присвоеть значение ей нельзя

Это сообщение отредактировал(а) CTAPbIuMABP - 22.2.2006, 12:37

для этого надо минимум 100 постов иметь...

if (FALSE==$var) так нельзя? почему это? можно же...

это я немного увлекся))) конечно можно)))

PS кажется, если не можеш сам, можно модера просить))))

Это сообщение отредактировал(а) CTAPbIuMABP - 22.2.2006, 18:42

CTAPbIuMABP, выпрашивать репу нельзя !