px.uz - бесплатный хостинг изображений в TAS-IX

[Aziz Madetov]

Представляю вам личный проект — px.uz ) бесплатный хостинг изображений в TAS-IX (http://px.uz).

Имеется возможность удаленной загрузки изображений и загрузки "пачкой" ≤ 20 штук.

Максимальный загружаемый объем: не более 3 мегабайт.

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

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

Предупреждаю, что изображения будут удаляться без уведомления, если они не будут соответствовать правилам сервиса и/или противоречить действующему законодательству Республики Узбекистан.

Сайт бесплатный для TAS-IX и доступен из мира :)

Вроде все.. Вот адрес: http://px.uz

Приветствую критику ;)

[Aziz Madetov]

Вроде все..Да, еще: имеется опция наложения надписи на превью — как свой текст, так и размер изображения. На оригинал не накладываются никакие водяные знаки и надписи, чтобы не портить, например, фотки, которыми вы делитесь с друзьями.

[Jasur Roozmatov]

Вы для себя сделали этот ресурс? Если да, то Не плохо для 1 раза !!!!!! :clapping:


Если для всех как общедоступный ресурс .... то ..... "тю-ту", я б сказал: "Что за х...!?" :shok:


С Уважением .. :187:

[Aziz Madetov]

Если для всех как общедоступный ресурс .... то ..... "тю-ту", я б сказал: "Что за х...!?"Вы не могли бы давать более развернутые комментарии?

[JackDaniels]

Неплохой сайт, но я сделал бы так —

https://img.uforum.uz/images/lxmomxa2667407.jpg

[Aziz Madetov]

Неплохой сайт, но я сделал бы такСпасибо ) может быть, когда достигну нужного уровня ;)

[Андрей Андреев]

ммм...а галереи нету чтоли??? =(((

[Aziz Madetov]

ммм...а галереи нету чтоли??? =(((Нет, так как в основном подобные ресурсы используются для форумов или просто обмена фотками. Может быть, в будущем, будет допилена галерея. Может быть.

[Андрей Андреев]

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

[Aziz Madetov]

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

[Андрей Андреев]

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

[Dolphin]

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

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

[Aziz Madetov]

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

[Evgeniy Sklyarevskiy]

Вроде работает! Вот загрузил:

http://px.uz/images/2012-01/30/d40tsb5w0lrz7a5d2pgcgyb1u.jpg

[JackDaniels]

Неплохой сайт, но я сделал бы такСпасибо ) может быть, когда достигну нужного уровня ;)

Если интересно, давайте пообщаемся в скайпе/аське, с удовольствием помогу, чем смогу.
А так, каждый новый сайт в Тасиксе — событие.

[Vazgen Sarkisov]

Хороший сервис, ничего лишнего, минимализм радует.

[Vazgen Sarkisov]

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

[Aziz Madetov]

Я бы посоветовал сделать личный кабинет пользователя, где сохраняются все его загрузки, думаю удобнее, чем сохранять ссылки.Могу сделать отправку ссылок на email. На таких ресурсах регистрация пользователей вообще не должна присутствовать, имхо.

[Evgeniy Sklyarevskiy]

Я бы посоветовал сделать личный кабинет пользователя, где сохраняются все его загрузки, думаю удобнее, чем сохранять ссылки. Тогда надо ограничение прав на просмотр, просмотр в разных размерах, рейтинги, оценки, комментарии, избранное, фото дня, друзья... и получим Пиксленд :-0)

Особенно приятно что Aziz Madetov, госслужащий, делает сервисы бесплатные для людей, уважаю. Хороший пример тем, кто смотрит футбол или чатится в Фейсбуке или бездарно читает форум :-0))) Когда вы умрете на панихиде скажут: ах, как хорошо он смотрел футбол! :-0)))

[Ильясов Алишер]

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

[Concerned]

А вот вы говорите что фотки будут удаляться если их долго не просматривают. Каким образом ваша система это определяет? ведь просматриваться они будут не на вашем сайте... %) но обращаться за файлами картинок же будут к px.uz

[Андрей Андреев]

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

[Ильясов Алишер]

мда... а к какому серверу будут идти запросы ? Да понятно что к серверу px.uz. Только изображение тянется не через скрипт (к примеру: http://px.uz/get_img.php?img=12345) а на прямую http://px.uz/images/2012-01/31/qibxchsm2ul3j71wqn9a37iyr.jpg. Каким образом идет подсчет просмотров? сорри возможно глупый вопрос...

[Aziz Madetov]

А вот вы говорите что фотки будут удаляться если их долго не просматривают. Каким образом ваша система это определяет? ведь просматриваться они будут не на вашем сайте...Да понятно что к серверу px.uz. Только изображение тянется не через скрипт (к примеру: http://px.uz/get_img.php?img=12345) а на прямую http://px.uz/images/2012-01/31/qibxc...wqn9a37iyr.jpg. Каким образом идет подсчет просмотров? сорри возможно глупый вопрос...Простая серверная проверка прямого запроса картинки и реферралов. Про access.log слышали?

[Андрей Андреев]

Каким образом идет подсчет просмотров?
логи запросов к файлу на сервере же хранятся, вот по ним и ведётся учёт

[Ильясов Алишер]

Простая серверная проверка прямого запроса картинки и реферралов. Про access.log слышали? Да слышал :) Спасибо теперь понял

[JackDaniels]

Про access.log слышали?
логи запросов к файлу на сервере же хранятся, вот по ним и ведётся учёт
Наверно самый кривой способ анализировать лог.

[Aziz Madetov]

Наверно самый кривой способ анализировать лог.:) Я не говорил, что анализ ведется именно так. Человек спросил, как можно проследить доступ к картинке, я ответил )

[JackDaniels]

Наверно самый кривой способ анализировать лог.:) Я не говорил, что анализ ведется именно так. Человек спросил, как можно проследить доступ к картинке, я ответил )

Понимаю, просто кто-то прочтет и сделает на основе анализа логов.

1 картинка — 1 запись в базе с датой последнего доступа к ней и всем прочим, выдавать картинку по запросу к скрипту.
Запускать раз в час (сутки) по Cron-у скрипт/чистильщик и удалять мертвые.

[German Stimban]

1 картинка — 1 запись в базе с датой последнего доступа к ней и всем прочим, выдавать картинку по запросу к скрипту.
Запускать раз в час (сутки) по Cron-у скрипт/чистильщик и удалять мертвые.
Руслан, а если кто-то поставил ссылку на картинку не в виде хттп://сайт/show.php?image=example.jpg а хттп://сайт/example.jpg
Как тогда анализировать?

[JackDaniels]

1 картинка — 1 запись в базе с датой последнего доступа к ней и всем прочим, выдавать картинку по запросу к скрипту.
Запускать раз в час (сутки) по Cron-у скрипт/чистильщик и удалять мертвые.
Руслан, а если кто-то поставил ссылку на картинку не в виде хттп://сайт/show.php?image=example.jpg а хттп://сайт/example.jpg
Как тогда анализировать?

А зачем давать реальный адрес картинки?

Вполне достаточно сделать чтобы «удобный» для пользователя адрес http://img.site.com/pictures.jpg на самом деле обрабатывался как http://img.site.com/?image=pictures.jpg

[German Stimban]

А зачем давать реальный адрес картинки?

Вполне достаточно сделать чтобы «удобный» для пользователя адрес http://img.site.com/pictures.jpg на самом деле обрабатывался как http://img.site.com/?image=pictures.jpg
1. Я обычно кликаю правой кнопкой мыши и беру "копировать URL изображения"
2. Не все форумы корректно обрабатывают такие картинки по урлу

[BoDHuk]

Что-то у меня не пашет сайт :blink:
(мтс-3g)

[Janbolat]

This webpage is not available
The connection to px.uz was interrupted.


Узнет

[Denis Shlyapnikov]

А зачем давать реальный адрес картинки?

Вполне достаточно сделать чтобы «удобный» для пользователя адрес http://img.site.com/pictures.jpg на самом деле обрабатывался как http://img.site.com/?image=pictures.jpg
1. Я обычно кликаю правой кнопкой мыши и беру "копировать URL изображения"
2. Не все форумы корректно обрабатывают такие картинки по урлу

Никогда не сталкивался с такой задачей, но вижу только одно решение:

Используется реврайты
http://img.site.com/pictures.jpg - на самом деле будет исполняться как script.php?file=xxx.jpg

А вот куда лучше сохранять дату последнего вызова этого файла - вопрос ))

[JackDaniels]

1. Я обычно кликаю правой кнопкой мыши и беру "копировать URL изображения"
Так УРЛ и будет http://img.site.com/pictures.jpg :)

[0zz]

где сайт? у меня TPS, вроде, если что..

[Evgeniy Sklyarevskiy]

У меня тоже неоткрывашка. И картинка, которую я загрузил тут http://uforum.uz/showthread.php?p=685226&postcount=14 не видна????

[Islom Djamalov]

И картинка, которую я загрузил тут
не видна. MTS, TPS и Sarkor Telecom.

[Aziz Madetov]

Что-то у меня не пашет сайт
(мтс-3g)где сайт? у меня TPS, вроде, если что..У меня тоже неоткрывашка. И картинка, которую я загрузил тут http://uforum.uz/showthread.php?p=685226&postcount=14 не видна????не видна. MTS, TPS и Sarkor Telecom.
Мы в данное время расширяем интернет-канал, в связи с этим меняется IP адрес. Явление временное, просьба отнестись с пониманием ;) В ближайшее время сайт заработает в штатном режиме на более высокой скорости доступа.

[German Stimban]

1. Я обычно кликаю правой кнопкой мыши и беру "копировать URL изображения"
Так УРЛ и будет http://img.site.com/pictures.jpg :)

Это если с .htaccess мутить?

[JackDaniels]

1. Я обычно кликаю правой кнопкой мыши и беру "копировать URL изображения"
Так УРЛ и будет http://img.site.com/pictures.jpg :)

Это если с .htaccess мутить?

Ну да.

[Ильясов Алишер]

Никогда не сталкивался с такой задачей, но вижу только одно решение: Используется реврайты http://img.site.com/pictures.jpg - на самом деле будет исполняться как script.php?file=xxx.jpg А вот куда лучше сохранять дату последнего вызова этого файла - вопрос ))

Да я тоже считаю это самым разумным решением, использовать мод реврайт.


Вполне достаточно сделать чтобы «удобный» для пользователя адрес http://img.site.com/pictures.jpg на самом деле обрабатывался как http://img.site.com/?image=pictures.jpg Это выглядит менее красиво

[JackDaniels]

Никогда не сталкивался с такой задачей, но вижу только одно решение: Используется реврайты http://img.site.com/pictures.jpg - на самом деле будет исполняться как script.php?file=xxx.jpg А вот куда лучше сохранять дату последнего вызова этого файла - вопрос ))

Да я тоже считаю это самым разумным решением, использовать мод реврайт.


Вполне достаточно сделать чтобы «удобный» для пользователя адрес http://img.site.com/pictures.jpg на самом деле обрабатывался как http://img.site.com/?image=pictures.jpg Это выглядит менее красиво

Что менее красиво?
Адрес картинки вида: http://img.site.com/pictures.jpg ? :)
И как его «украсить»?

[Ильясов Алишер]

Что менее красиво? Адрес картинки вида: http://img.site.com/pictures.jpg ? И как его «украсить»? Нет я имел введу это http://img.site.com/?image=pictures.jpg
(http://img.site.com/?image=pictures.jpg)

[JackDaniels]

Что менее красиво? Адрес картинки вида: http://img.site.com/pictures.jpg ? И как его «украсить»? Нет я имел введу это http://img.site.com/?image=pictures.jpg
(http://img.site.com/?image=pictures.jpg)

Так пользователь будет видеть: http://img.site.com/pictures.jpg
А движок как http://img.site.com/?image=pictures.jpg

[Ильясов Алишер]

Да и я об этом же :)

[Denis Shlyapnikov]

Так как же вы будете хранить информацию о последнем запросе выдачи изображения, чтобы потом кроном (?) удалять "устаревшие"

[JackDaniels]

Так как же вы будете хранить информацию о последнем запросе выдачи изображения, чтобы потом кроном (?) удалять "устаревшие"

Вопрос к кому?

[Aziz Madetov]

Так как же вы будете хранить информацию о последнем запросе выдачи изображения, чтобы потом кроном (?) удалять "устаревшие"

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

Второй способ заключается в том, что, как все наверное уже заметили, загруженные картинки хранятся в папках по датам, типа /2012/02/01/image.jpg - так вот, в папках каждый день создается индекс содержимого с указанием даты создания и последнего доступа, которая перезаписывается скриптом при запросе. Далее все просто :)

[JackDaniels]

Второй способ заключается в том, что, как все наверное уже заметили, загруженные картинки хранятся в папках по датам, типа /2012/02/01/image.jpg - так вот, в папках каждый день создается индекс содержимого с указанием даты создания и последнего доступа, которая перезаписывается скриптом при запросе. Далее все просто
Это очень медленно, не заморачивайтесь даже.
Через 2-3 года и +100 000 картинок сервер будет просто «умирать» на этом месте. :)

[Denis Shlyapnikov]

Второй способ заключается в том, что, как все наверное уже заметили, загруженные картинки хранятся в папках по датам, типа /2012/02/01/image.jpg - так вот, в папках каждый день создается индекс содержимого с указанием даты создания и последнего доступа, которая перезаписывается скриптом при запросе. Далее все просто
Это очень медленно, не заморачивайтесь даже.
Через 2-3 года и +100 000 картинок сервер будет просто «умирать» на этом месте. :)

Хочется отметить, что первый способ будет не лучше, постоянные запросы mysql со временем отправят сервер в даун.
Хотя есть более быстрые DB, но все равно это постоянная нагрузка на сервере будет.

[JackDaniels]

Второй способ заключается в том, что, как все наверное уже заметили, загруженные картинки хранятся в папках по датам, типа /2012/02/01/image.jpg - так вот, в папках каждый день создается индекс содержимого с указанием даты создания и последнего доступа, которая перезаписывается скриптом при запросе. Далее все просто
Это очень медленно, не заморачивайтесь даже.
Через 2-3 года и +100 000 картинок сервер будет просто «умирать» на этом месте. :)

Хочется отметить, что первый способ будет не лучше, постоянные запросы mysql со временем отправят сервер в даун.
Хотя есть более быстрые DB, но все равно это постоянная нагрузка на сервере будет.

Глупости.

Смотрите сами —

При запросе картинки, например http://img.site.com/pictures.jpg
Ваш движок получает в переменную ее имя: $image=pictures.jpg

На каждую картинку в таблице всего несколько полей — "ID владельца", "Дата загрузки", "Размер", "EXIF данные", "Дата последнего запроса", "Публична/Приватна", "Имя картинки", "Размер X", "Размер Y", "Теги", "Тип", "Ну и еще какие ни будь полезности"

Все столбцы, по которым возможен запрос типа SELECT загоняем в Индекс, полный путь (исходная, миниатюра) принять постоянным для всех, чтобы не записывать отдельно (например "/mini/", "/orignl/").
Поле "Дата последнего запроса" даже не обязательно обновлять PHP-скриптом, можно пойти на хитрость, и выполнять холостой UPDATE-запрос, тогда выбрав тип TIMESTAMP мы возложим это на сам MySQL, который пробъет текущую дату.

Таким вот макаром получаем, что запрос картинки из MySQL на простеньком самодельном сервере будет занимать всего 0.003—0.005 с.

Профит:
Имеем гибкую структуру для поиска по различным признакам (размер, тип, автор, EXIF, и тд…)

Запуская раз в сутки, например в 5 утра, когда все спят, по Крон-у скрипт, который выполнит что-то типа SELECT * FROM img WHERE last_date >= cur_date+60 дней, находим просроченные.
И спокойно скриптом-удалялкой хлопаем по порядку все, что нашлось не нужное и из базы и с диска.

И все будет прекрасно работать и со 100 000 и с 500 000 и даже с 5 000 000 элементов.

А почему постоянные запросы к MySQL должны «отправить сервер в даун» — я вообще не понял.
С какой радости?
Ради приличия, можно после удаления ненужных запускать оптимизацию: OPTIMIZE TABLE `img`

:)

[Denis Shlyapnikov]

Это очень медленно, не заморачивайтесь даже.
Через 2-3 года и +100 000 картинок сервер будет просто «умирать» на этом месте. :)

Хочется отметить, что первый способ будет не лучше, постоянные запросы mysql со временем отправят сервер в даун.
Хотя есть более быстрые DB, но все равно это постоянная нагрузка на сервере будет.

Глупости.

Смотрите сами —

При запросе картинки, например http://img.site.com/pictures.jpg
Ваш движок получает в переменную ее имя: $image=pictures.jpg

На каждую картинку в таблице всего несколько полей — "ID владельца", "Дата загрузки", "Размер", "EXIF данные", "Дата последнего запроса", "Публична/Приватна", "Имя картинки", "Размер X", "Размер Y", "Теги", "Тип", "Ну и еще какие ни будь полезности"

Все столбцы, по которым возможен запрос типа SELECT загоняем в Индекс, полный путь (исходная, миниатюра) принять постоянным для всех, чтобы не записывать отдельно (например "/mini/", "/orignl/").
Поле "Дата последнего запроса" даже не обязательно обновлять PHP-скриптом, можно пойти на хитрость, и выполнять холостой UPDATE-запрос, тогда выбрав тип TIMESTAMP мы возложим это на сам MySQL, который пробъет текущую дату.

Таким вот макаром получаем, что запрос картинки из MySQL на простеньком самодельном сервере будет занимать всего 0.003—0.005 с.

Профит:
Имеем гибкую структуру для поиска по различным признакам (размер, тип, автор, EXIF, и тд…)

Запуская раз в сутки, например в 5 утра, когда все спят, по Крон-у скрипт, который выполнит что-то типа SELECT * FROM img WHERE last_date >= cur_date+60 дней, находим просроченные.
И спокойно скриптом-удалялкой хлопаем по порядку все, что нашлось не нужное и из базы и с диска.

И все будет прекрасно работать и со 100 000 и с 500 000 и даже с 5 000 000 элементов.

А почему постоянные запросы к MySQL должны «отправить сервер в даун» — я вообще не понял.
С какой радости?
Ради приличия, можно после удаления ненужных запускать оптимизацию: OPTIMIZE TABLE `img`

:)

Т.е. вы считаете правильным держать записи Всех 5 миллионов картинок в mysql, к которому постоянно будут идти запросы.

Допустим что так и сделали, и у нас имеется 100.000 картинок. Все они, к пример, располагаются на нескольких посещаемых сайтах. Далее, к примеру - на одной странице одного из этих сайтов располагается 30 картинок - это уже 30 запросов (на 1 пользователя). А если там будут выкладывать типа сборника Демов или еще чего наподобие )) то и 30 картинок далеко не предел. Или просто на посещаемый форум вобьют в подпись картинки.
По факту получится же -
1 картинка - 1 запрос от одного пользователя, а сколько их будет?)

Поэтому, на мой взгляд хранить в таком виде картинки - не есть хорошо.

[Denis Shlyapnikov]

А нет, ошибся, простите. Там не 1 запрос на 1 картинку, а 2
1 - выборка
2 - update
=\

[JackDaniels]

Т.е. вы считаете правильным держать записи Всех 5 миллионов картинок в mysql, к которому постоянно будут идти запросы.

Допустим что так и сделали, и у нас имеется 100.000 картинок. Все они, к пример, располагаются на нескольких посещаемых сайтах. Далее, к примеру - на одной странице одного из этих сайтов располагается 30 картинок - это уже 30 запросов (на 1 пользователя). А если там будут выкладывать типа сборника Демов или еще чего наподобие )) то и 30 картинок далеко не предел. Или просто на посещаемый форум вобьют в подпись картинки.
По факту получится же -
1 картинка - 1 запрос от одного пользователя, а сколько их будет?)

Поэтому, на мой взгляд хранить такой в таком виде картинок - не есть хорошо.
Дело не во взглядах, просто это удобный и правильный метод.
Изобретете что-то новое — пишите.

Чтоже до нагрузки, то даже если допустить, что при каждом посещении каждой страницы каждого сайта зарегистрированного на www.uz пользователь запросит 1 картинку (согласно статистики http://www.uz/ru/catalogue/stat/ это около 4 миллионов хитов за сутки), получается в районе 45 запросов в секунду, а при затратах времени на один запрос даже в 0.01 с, вы во много раз перекрываете потребность.

Быстрее заглохнет PHP, канал и дисковая система на отдачу самой картинки. :)

Подумайте сами, данных в базе на одно изображение: 1-2 кбайта, а сама картинка может быть и 2 и 5 мбайт.

:)

[JackDaniels]

А нет, ошибся, простите. Там не 1 запрос на 1 картинку, а 2
1 - выборка
2 - update
=\

при затратах времени на один запрос даже в 0.01 с,
Учел, как видите ;)

Да, еще ни кто не мешает использовать фронтэнд и кеш. :)

Вот только сильно сомневаюсь, что какой либо картинко-хостинг в узнете сможет похвалиться 4-мя миллионами хитов в сутки ;)

[Denis Shlyapnikov]

Ну тогда и сервер надо ставить по мощнее )))

[Андрей Андреев]

сервер надо ставить по мощнее
интересно а у px.uz какой сервер стоит =)))

[JackDaniels]

Ну тогда и сервер надо ставить по мощнее )))

Ну это само собой :)

[Denis Shlyapnikov]

Ну тогда и сервер надо ставить по мощнее )))

Ну это само собой :)
кнопка www.uz (счетчик) частенько бывает недоступен ))

[JackDaniels]

Ну тогда и сервер надо ставить по мощнее )))

Ну это само собой :)
кнопка www.uz (счетчик) частенько бывает недоступен ))

Да, не раз уже обсуждалось.

[Aziz Madetov]

интересно а у px.uz какой сервер стоит =)))HP ProLiant ML110 G6 (http://h10010.www1.hp.com/wwpc/ru/ru/sm/WF25a/15351-15351-241434-3328424-3328424-3984625.html?dnr=1)

http://h10010.www1.hp.com/wwpc/images/emea/hp-proliant-ml110-g6-server-series_190x170.jpg

Процессор Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 4 Гб памяти, под www выделено 200 Гб. Общий объем всех жестких дисков: 2 Тб, объединенные в RAID-массив.

[Talgat Ravilov]

Процессор Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 4 Гб памяти, под www выделено 200 Гб. Общий объем всех жестких дисков: 2 Тб, объединенные в RAID-массив.
Нехило, только один ресурс крутится на сервере?

[Aziz Madetov]

только один ресурс крутится на сервере?Нет, конечно. Сервер в первую очередь используется для собственных нужд Совета Министров. Вторая задача — бесплатный хостинг сайтов органов государственного управления Республики Каракалпакстан и некоторых других сайтов.

[Evgeniy Sklyarevskiy]

Ну это само собой :)
кнопка www.uz (счетчик) частенько бывает недоступен ))

Да, не раз уже обсуждалось.


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

[JackDaniels]

кнопка www.uz (счетчик) частенько бывает недоступен ))

Да, не раз уже обсуждалось.


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

Не решена. Как раз вчера, когда все это описывал не смог посмотреть Общую статистику - "Сайт перегружен", пришлось выискивать на форуме свое старое сообщение, чтобы прикинуть суточное количество хитов. :(

Да и до сих пор лежит:

https://img.uforum.uz/images/kksrxdk5485883.png


И плиз, почините прозрачность в PNG, белый стал альфой :)

[Андрей Андреев]

Не решена
сегодня в течении минут 20 опять не грузилось изображение счётчика на сайте... =(((
https://img.uforum.uz/images/vxrwbjp6699212.png

[Evgeniy Sklyarevskiy]

Спасибо за активность, просьба перепостить в раздел замечаний по www.uz http://uforum.uz/showthread.php?p=678875#post678875 - разработчики там реагируют на все замечания.

[Максуд Нишанов]

Цитата: Сообщение от Руслан Худяков Посмотреть сообщение Не решена Оффтоп: сегодня в течении минут 20 опять не грузилось изображение счётчика на сайте... =(((

Данная ситуация возникла во время перезагрузки сервера, на котором находится база данных НИПС, при перезагрузки сервера ему понадобится немного времени для запуска mysql.
Мы всегда стараемся чтобы такие ситуации больше не возникали.

[Aziz Madetov]

Мы в данное время расширяем интернет-канал, в связи с этим меняется IP адрес. Явление временное, просьба отнестись с пониманием В ближайшее время сайт заработает в штатном режиме на более высокой скорости доступа.Расширили Интернет-канал. Скорость доступа к сайту должна быть ~2 Мбит/сек в Tas-IX и ~1.5 Мбит/сек извне. Проверьте, пожалуйста, и отпишитесь.

[Talgat Ravilov]

Скорость доступа к сайту должна быть ~2 Мбит/сек в Tas-IX
Надо еще расширить, по опыту знаю что этого будет очень мало. Нужно не менее 8мбит/с.

[Aziz Madetov]

Надо еще расширить, по опыту знаю что этого будет очень мало. Нужно не менее 8мбит/с.В данное время это все, что нам может предоставить ЦРБ АК "Узбектелеком". К сожалению. Итак вынудили подключить HDSL.

[Андрей Андреев]

Нужно не менее 8мбит/с.
а если будет пользоваться популярностью ресурс то и эти 8 мбит/с не спасут =((