Очередной вопрос о выборе скрипта

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

Никакой не вытянет - проверено.
И не верь производителям, которые кричат об обратном.

в принципе, все зависит от настроек сервера, то есть от админа. у меня FET спокойно держал 150K, при том что на сервере еще был дополнительный траф почти 800К.

Morphius писал:

Никакой не вытянет - проверено. И не верь производителям, которые кричат об обратном.

Бред

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

Kildoozer писал:

Бред

твой нормально держит 100k?

CjPro в свое время держал такой траф...

ТТТ у меня держал 80К без проблем.
Протон, думаю, выдержит.

интересный чел...

если умеешь разгонять и держать такой траф - бери платный скрипт. Окупится мгновенно и многократно. Зачем велосипед изобретать?

Да ну вас в баню, ребята.
Чё как кто тут вам рассказывает, что фришные скрипты, MySQL не держат траф (падают имеется в виду, а не плохо трейдят)?
Ничего подобного. Если рассмотреть все популярные фришные скрипты, то проблем с нагрузками у них категорически нет.
Топикстартер, как именно "аврора умерла при 60к"?
У тебя что за сервер? Если виртуал, то никакой платный скрипт тебе не поможет. А все эти вопли о том, что де у нашего скрипта своя БД, MySQL мы не пользуемся - не более, чем маркетинговый ход. Разработка БД лучшей, чем MySQL стоит побольше, чем суммарный доход участников этого форума за месяц минимум. Кроме того, сложность разработки подобного продукта заключаются не только в материальной составляющей, но и в интелектуальной. Для того, чтобы разработать алгоритмы на подобие MySQL нужно время специалистов, не худших, чем в MySQL, а это уже может и не получиться купить за деньги.
Вобщем выбирай CJ скипт не по анонсам объёмов трейда, а по функционалу. После этого ищи нормального админа, который тебе покажет, где узкое место твоего сиджа. Голову даю на отсечение, что узкое место скорее всего не в скрипте, то бишь работе PHP фактически, а в графике, плохо распределённой нагрузке на БД, в канале в конце концов.
Про аврору могу сказать, что она то как раз существенно быстрее других скриптов, потому как не нагружена излишним функционалом. Другое дело, что есть места, где можно было бы сделать понадёжнее, погрешив быстродейсвием, но и без этого вобщем то скрипт более, чем удачный. Никакой гарантии, что у тебя точно так же на её месте не грохнется сидж за k сотен баксов нет.

Farik писал:

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

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

Хренодер совершенно прав...


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

Цитата:

как именно "аврора умерла при 60к"?

Неверно начала отображаться статистика по аутам за 24 часа. Ауты с предыдущего часа начали переноситься на аут текущего, из-за этого скрипт переставал слать на трэйд считая что он уже норму выслал, из-за чего перестали функционировать форсы. Постоянное, ежечасное обнуление тумбокрута, что вызвало понижение проды. Трафф начал падать и скатился до 10к.
Стояло всё на дедике, загрузок у сервака не было.
По поводу покупки платных скриптов, то я вроде писал что мне за раз надо создать как минимум 4 сиджа. А это уже больше 1к денег. Операцию затеял довольно рискованную, поэтому вкладываться так не особо хочется. Это при условии что всё таки есть фришные которые держат столько траффа, если их нет то видимо вложиться прийдётся.

netzhizni писал:

твой нормально держит 100k?

Без проблем.

Kildoozer писал:

Без проблем.

Подтверждаю. Проверенно электроникой (с) NoBoDy

Proton держит!

Цитата:

Proton держит!

был бы рад взглянуть на урлы

Цитата:

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

Xrenoder, я просто знал, что ты тут появишься после моей месаги 8)
То, что используется в скриптах CJ вместо MySQL некорректно называть СУБД, надеюсь почему - объяснять не надо. Это просто вообще никакого отношения к базам данных не имеет. Да, действительно, в случае конкретной реализации вопрос написания подобной системы управления данными(в первую очередь реализации статистической модели) может ускорить работу скрипта. Но только за счёт удобства написания. Очевидно, что все операции работы CJ запихивать в БД - удобно, но медленно. Корректное разделение функций БД и моделью управления статистической информацией сиджа не может сделать его работу медленнее. Другое дело, что сиджу получается нужна и БД и модуль управления статистической моделью.
Вобщем сухой остаток такой - не MySQL делает работу скриптов медленнее работы твоего, а неграмотная реализация разделения функционала между MySQL и моделью управления статистической информацией. При грамотном разделении MySQL только ускорит быстродействие.

Цитата:

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

Ладно, согласен, фабула Аврора - самый надёжный скрипт, не выдерживает критики. Статистика с предыдущего часа стала переностится из за конкрентной недоделки в виде отсутсвия проверки обнуления таблицы с часовыми статами. При большой нагрузке на БД за счёт того, что это обнуление происходит с директивой LOW PRIORITY оно не всегда успевает произвестись. Это вобщем то баг конечно. По поводу тумбокрута - вобщем то ты его забесплатно не найдёшь толковый. Исключением наверное является GB. В протоне и фете тумбокрутов просто нет(вроде как).
Урлы:
_http://proton-cj.com/features.html
_http://gbscript.com/
_http://fetcj.com/ru/

Стукнись в асю, покажу свой сиджик. 103-468-856
Чужие сиджы показывать не буду, ибо обязался не разглашать подобную инфу.

Farik писал:

Xrenoder, я просто знал, что ты тут появишься после моей месаги 8)

Ай шаман

Farik писал:

То, что используется в скриптах CJ вместо MySQL некорректно называть СУБД, надеюсь почему - объяснять не надо. Это просто вообще никакого отношения к базам данных не имеет. Да, действительно, в случае конкретной реализации вопрос написания подобной системы управления данными(в первую очередь реализации статистической модели) может ускорить работу скрипта. Но только за счёт удобства написания. Очевидно, что все операции работы CJ запихивать в БД - удобно, но медленно. Корректное разделение функций БД и моделью управления статистической информацией сиджа не может сделать его работу медленнее. Другое дело, что сиджу получается нужна и БД и модуль управления статистической моделью. Вобщем сухой остаток такой - не MySQL делает работу скриптов медленнее работы твоего, а неграмотная реализация разделения функционала между MySQL и моделью управления статистической информацией. При грамотном разделении MySQL только ускорит быстродействие.

А я вроде и не называю "то, что используется вместо MySQL" термином СУБД.
Как раз наоборот - я утверждаю, что любая СУБД на месте "того, что используется вместо" будет работать хуже, именно в силу того что СУБД призвана управлять "абстрактной базой", а моя система - совершенно конкретной.
Быстродействие за счет универсальности - стандатный размен, в данном случае на 100% оправданый.
Дальше, утверждение что "все операции CJ запихивать в БД удобно но медленно" - все как раз наоборот. Не так удобно, но гораздо быстрее, именно потому, что есть возможность с максимальной эффективностью встроить все необходимые вычислительные процессы непосредственно в процессы "ворошения данных" - это как минимум означает, что многие данные не надо будет шевелить (точнее, блокировать) дважды.
Так что интеграция БД и вычислителя - это еще один выигрыш специализированой БД перед СУБД, конкретно перед мусклем.
Поэтому вывод из этого остается прежним: на том же железе, с тем же функционалом система с мусклем проиграет 100%.

Цитата:

Поэтому вывод из этого остается прежним: на том же железе, с тем же функционалом система с мусклем проиграет 100%.

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

Тут вообще много можно спорить, все равно в конце концов все упрется в возможности настроить под себя сервер.

хм... ребят спорить насчёт мускуля и БД в этом топике насамом деле нестоит, лучше давайте подскажем лучший вариант скрипта человеку !
Думаю что FET выдержит такой наплыв, хотя лучше пообщаться с производителем !

Меня интересует ATS - как он в плане надежности ? В связи с тем, что в нем есть ротатор(в Протоне и фете нет) и база хранения данных своя. А то создатель его что-то в полемику не вступает.

Stek писал:

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

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

Vorug писал:

По поводу покупки платных скриптов, то я вроде писал что мне за раз надо создать как минимум 4 сиджа. А это уже больше 1к денег. Операцию затеял довольно рискованную, поэтому вкладываться так не особо хочется. Это при условии что всё таки есть фришные которые держат столько траффа, если их нет то видимо вложиться прийдётся.

Мнда. Раскрутить 4 сиджа до 100К каждый это не кисло. У меня что платные что стоящие на моих собственных поделках больше 35К не хотят подниматься. И разницы особой в эффективности трейда я не вижу кстати. Платный больше грузит сервак только...