Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 60
Хм. я думал тут будут поститься интересные статьи про разработку.
Посмотрите extjs (если не смотрели еще), как там реализован грид с редактированием, с сортировкой и фильтрами. Суперскоростью эта библиотека не славится, но придумана для такого рода задач.
Посмотрите extjs (если не смотрели еще), как там реализован грид с редактированием, с сортировкой и фильтрами. Суперскоростью эта библиотека не славится, но придумана для такого рода задач.
webdev_faq - это вопросы и ответы по веб-разработке, имхо
за extjs спасибо, но вопрос был в другом. у нас уже есть готовая форма заточенная под наши нужды, дело лишь за организацией стабильного соединения.
спасибо
за extjs спасибо, но вопрос был в другом. у нас уже есть готовая форма заточенная под наши нужды, дело лишь за организацией стабильного соединения.
спасибо
вы с самого начала начали изобретать велосипед — давно уже существуют JavaScript frmaework'и на любой вкус.
там есть и evalJSON, и onException, и прочее.
там есть и evalJSON, и onException, и прочее.
Вы счастливчик, что вам нужно работать только с ИЕ :) однако, у меня есть вопросы. Вы не думали о будущем? ведь, как тут ниже уже написали, Вы изобретаете велосипед. Как я понял опыта у Вас немного с javaScript, поэтому это должно было подтолкнуть к мысли найти готовые решения. я например предпочитаю prototype.js. А о будущем не подумали почему - тратите зря время на то что можно взять готовое и использовать. Вы не получите хоть сколько бы то ни было сравнимого результата с существующими open source наработками. + используя популярный open source вы можете расчитывать что они протестированы достаточно качественно, а это, по крайней мере, придаст Вам уверенности в плане совместимости. Или у Вас один проект на всю жизнь? будет следующий - нужен будет AJAX тот же. захотят эффекты. вы их тоже сами делать будете? захотят кросс-браузерность, хотя бы на Mozilla 2+, IE 6,7 & Opera 9+. сколько времени понадобится на то чтобы переписать все под них?
Теперь по вашим вопросам, по существу:
1. Ошибка 504. Вам не кажется что проблема не в AJAX а в нагрузке на сервер? Если процессор нагружен на 100%, как я понял из-за больших вычислений в БД, то мне кажется сбоит не javascript, а проблема действительно на стороне сервера
2. Неправильный порядок ответов. Вот если бы Вы использовали популярные наработки Open source, то знали бы о сущзествовании синхронных и асинхронных запросов :) и не было бы проблем с потерянными запросами по неизвестной причине и неправильного порядка ответов.
3. Советы: поставьте FireBug, Web Developer плагины для FireFox. Я понимаю что Вы используете IE, но эти вещи возможно помогут Вам выявлении причин неправильно работы
4. По реализации "Connection pool". Я не знаю как в двух словах описать алгоритм всего что Вам нужно. Но могу сказать что Вам придется активно исользовать setTimeOut с маленькими значениями для реализации асинхронных запросов. Стейты и некоторого рода инспекторы, которые будут за всем этим следить. Если есть более конкретные вопросы, я готов помочь чем смогу. Однако настоятельно Вам рекомендую использовать готовые, проверенные решения :) мне кажется Вам будет проще заменить свой велосипед на тот же prototype везде где нужно, чем сейчас и потом бороться со всеми этими проблемами :)
не поймите мой пост неправильно, я просто хочу дать Вам совет, и старался привести доводы, почему так лучше. а пользоваться им или нет - Ваше личное дело.
Теперь по вашим вопросам, по существу:
1. Ошибка 504. Вам не кажется что проблема не в AJAX а в нагрузке на сервер? Если процессор нагружен на 100%, как я понял из-за больших вычислений в БД, то мне кажется сбоит не javascript, а проблема действительно на стороне сервера
2. Неправильный порядок ответов. Вот если бы Вы использовали популярные наработки Open source, то знали бы о сущзествовании синхронных и асинхронных запросов :) и не было бы проблем с потерянными запросами по неизвестной причине и неправильного порядка ответов.
3. Советы: поставьте FireBug, Web Developer плагины для FireFox. Я понимаю что Вы используете IE, но эти вещи возможно помогут Вам выявлении причин неправильно работы
4. По реализации "Connection pool". Я не знаю как в двух словах описать алгоритм всего что Вам нужно. Но могу сказать что Вам придется активно исользовать setTimeOut с маленькими значениями для реализации асинхронных запросов. Стейты и некоторого рода инспекторы, которые будут за всем этим следить. Если есть более конкретные вопросы, я готов помочь чем смогу. Однако настоятельно Вам рекомендую использовать готовые, проверенные решения :) мне кажется Вам будет проще заменить свой велосипед на тот же prototype везде где нужно, чем сейчас и потом бороться со всеми этими проблемами :)
не поймите мой пост неправильно, я просто хочу дать Вам совет, и старался привести доводы, почему так лучше. а пользоваться им или нет - Ваше личное дело.
1) я знаю про нагрузку на сервер, моя задача - сделать устойчивый клиент, который мог бы работать с перегруженным сервером и плохой связью
2) я знаю о существовании синхронных запросов. думаю от них отказаться, так как Firefox они подвешивают намертво до прихода ответа, а это порой до полуминуты, а в IE особо от асинхронных не отличаются, так как пользователь всё равно может работать с сайтом.
3) FireBug я использую для отладки и тестирования и лишь потом проверяю работоспособность кода в IE.
4) сам уже понял, что скорее всего придётся использовать таймеры.
а толку от prototype? он перестанет терять запросы? у него есть готовый connection pool? он умеет обходить обрыв соединения? чтобы перейти на чужой framework мне потребуется время, и не факт, что он будет лишён проблем. скорее, он добавит проблем по подгонке готового кода под него. или вы предлагаете взять из него только объект для отправки (а)синхронного запроса?
2) я знаю о существовании синхронных запросов. думаю от них отказаться, так как Firefox они подвешивают намертво до прихода ответа, а это порой до полуминуты, а в IE особо от асинхронных не отличаются, так как пользователь всё равно может работать с сайтом.
3) FireBug я использую для отладки и тестирования и лишь потом проверяю работоспособность кода в IE.
4) сам уже понял, что скорее всего придётся использовать таймеры.
а толку от prototype? он перестанет терять запросы? у него есть готовый connection pool? он умеет обходить обрыв соединения? чтобы перейти на чужой framework мне потребуется время, и не факт, что он будет лишён проблем. скорее, он добавит проблем по подгонке готового кода под него. или вы предлагаете взять из него только объект для отправки (а)синхронного запроса?
было у меня такое
еще в 2001 году разрабатывли для одной конторы тонкого клиента для торговли на форексе.
Тогда еще аджакса не было, как термина, но был ИЕ 5.0 и 5.5 и в нем был XMLHTTP
Собственно - его как раз и задействовали вместе с бихейвьерами и немодпльными диалогами.
Были объекты(сервисы), которые только получали инфу (например - котировки), били объекты, которые отправляли и получали инфу (напрмиер формы выставления ордеров). Так вот, сначала все работало независимо: каждый объект сам общался с сервром (например пользователь в форме создает лимит ордер клацает на ОК, и форма сама все постит на сервер и получает ответ , то есть типа реалтайм) Но потом, при большой нагрузке полезли такие же грабли, как описано в посте.
Мы решили проблему так: организовали очереди сообщений, принадлежащих сервисам - входящие и исходящие. Все объекты , например, формы, которым требовалось запостить данные, складывали их в очередь. И был глобальный обработчик , который по таймеру, скажем раз в секунду, сначала брал все, что готово к отправке на сервер, пулял это все на сервер поочереди, получая при этом подтверждение, после чего сообщение из очереди удалял. Ну и если подтверждения приема не было, то он отсылал из других очередей, а потом пытался перепослать то, что не получилось . При этом была главная системная очередь, в которой сообщения имели наивысший приоритет, и обрабатывались в первую очередь. Ну и сервер точно так же формировал очереди у себя и отдавал их поочереди при очередных запросах обработчика, которые эти ответы складывал в соответсвующие входящие очереди и выставлял евенты для сервисов.
Вообщем - написал сумбурно, но, надеюсь, идея понятна.
еще в 2001 году разрабатывли для одной конторы тонкого клиента для торговли на форексе.
Тогда еще аджакса не было, как термина, но был ИЕ 5.0 и 5.5 и в нем был XMLHTTP
Собственно - его как раз и задействовали вместе с бихейвьерами и немодпльными диалогами.
Были объекты(сервисы), которые только получали инфу (например - котировки), били объекты, которые отправляли и получали инфу (напрмиер формы выставления ордеров). Так вот, сначала все работало независимо: каждый объект сам общался с сервром (например пользователь в форме создает лимит ордер клацает на ОК, и форма сама все постит на сервер и получает ответ , то есть типа реалтайм) Но потом, при большой нагрузке полезли такие же грабли, как описано в посте.
Мы решили проблему так: организовали очереди сообщений, принадлежащих сервисам - входящие и исходящие. Все объекты , например, формы, которым требовалось запостить данные, складывали их в очередь. И был глобальный обработчик , который по таймеру, скажем раз в секунду, сначала брал все, что готово к отправке на сервер, пулял это все на сервер поочереди, получая при этом подтверждение, после чего сообщение из очереди удалял. Ну и если подтверждения приема не было, то он отсылал из других очередей, а потом пытался перепослать то, что не получилось . При этом была главная системная очередь, в которой сообщения имели наивысший приоритет, и обрабатывались в первую очередь. Ну и сервер точно так же формировал очереди у себя и отдавал их поочереди при очередных запросах обработчика, которые эти ответы складывал в соответсвующие входящие очереди и выставлял евенты для сервисов.
Вообщем - написал сумбурно, но, надеюсь, идея понятна.
А разбираться в причинах этой проблемы никто не пробовал? На каком именно этапе "теряются" запросы, и по какой причине?
Ведь это не UDP, HTTP бегает через TCP, а там есть ACK-пакеты. Иными словами, клиент всегда знает, получил сервер его запрос, или нет. По какой причине потребовалось на высоком уровне, ручками, реализовывать перепосылку запросов (т.е. по сути - дублировать функциональность TCP)?
Ведь это не UDP, HTTP бегает через TCP, а там есть ACK-пакеты. Иными словами, клиент всегда знает, получил сервер его запрос, или нет. По какой причине потребовалось на высоком уровне, ручками, реализовывать перепосылку запросов (т.е. по сути - дублировать функциональность TCP)?
Клиент значет что сервер не получил его запрос - и что дальше. Вешаться ?
Простите, в каком смысле? Когда клиент не может отправить запрос на сервер, он обычно либо повторяет запрос, либо сообщает о проблеме пользователю. Ни о какой организации сложных очередей, равно как и о "неожиданно потерявшемся" 4-м запросе из 5-ти речь не идёт.
он обычно либо повторяет запрос, либо сообщает о проблеме пользователювот в этом и вопрос, как всё это дело получше организовать, так как клиенту из бухгалтерии сообщение об ошибке 504, например, ничего не даст, а только напугает его.
Ни о какой организации сложных очередейвероятно, вы либо не сталкивались с такой проблемой, либо очень удачно разработали службу сообщений.
запросы теряются по-разному. иногда просто из-за долгого ответа сервера, иногда совершенно неожиданный обрыв связи (это в основном в FF, в IE такое очень редко бывает)
то сервер вроде бы отвечает, но json_string складывается ошибочно - не совсем ясно, почему. я уж думал контрольную сумму как-нибудь передавать или что-то в этом роде.
иногда клиент не получает данных, если продублировать запрос - всё нормально.
причины разные.
задача организовать соединение так, чтобы клиент мог стабильно работать при плохой связи и с перегруженным сервером, пусть медленней, но чтобы работал.
то сервер вроде бы отвечает, но json_string складывается ошибочно - не совсем ясно, почему. я уж думал контрольную сумму как-нибудь передавать или что-то в этом роде.
иногда клиент не получает данных, если продублировать запрос - всё нормально.
причины разные.
задача организовать соединение так, чтобы клиент мог стабильно работать при плохой связи и с перегруженным сервером, пусть медленней, но чтобы работал.
Да, я с такой проблемой не сталкивался, Вы правы. Я много лет активно работаю со сложным асинхронным I/O, но с AJAX не сталкивался пока (но в планах он есть, поэтому и интересуюсь темой, на будущее, так сказать).
Мне кажется не совсем адекватной сама постановка вопроса: "стабильная работа с перегруженным сервером и при плохой связи". Я обычно требую надёжности в любых условиях (в т.ч. при перегруженном сервере и плохой связи), что выражается в том, что данные не должны молча теряться, например. Но требовать стабильной работы ... странно. Такое требование подразумевает, что перегруженный сервер и плохая связь - норма. А это не должно быть нормой!
Надо либо оптимизировать код на сервере, либо делать кластер. А не выдумывать сложные очереди на клиентах - ведь эти очереди увеличивают кол-во отправляемых запросов на сервер, при том, что он и без этого не справляется с обработкой! Это тупик.
Что касается "плохой связи" то я вообще не понял, о чём идёт речь. Если это глюки FF, требующие каких-то workaround на клиенте - один разговор. Если это те же последствия перегруженного сервера, только в профиль - см. предыдущий абзац: сервер чинить надо. На мой взгляд, "плохая связь" это либо проблемы у провайдера приводящие к сильным потерям пакетов, либо обрывы модема у клиента, либо другие подобные проблемы. В этих условиях любой софт будет работать нестабильно, и требование стабильной работы в этих условиях разумно только если Вы во-первых пишете достаточно критичный софт и во-вторых уверены что проблема "плохой связи" действительно актуальна для Ваших пользователей (что не является типовым случаем в наши дни).
Я пока так и не понял, существует ли реально проблема, которую действительно правильно решать ручной организацией очередей в клиенте.
Мне кажется не совсем адекватной сама постановка вопроса: "стабильная работа с перегруженным сервером и при плохой связи". Я обычно требую надёжности в любых условиях (в т.ч. при перегруженном сервере и плохой связи), что выражается в том, что данные не должны молча теряться, например. Но требовать стабильной работы ... странно. Такое требование подразумевает, что перегруженный сервер и плохая связь - норма. А это не должно быть нормой!
Надо либо оптимизировать код на сервере, либо делать кластер. А не выдумывать сложные очереди на клиентах - ведь эти очереди увеличивают кол-во отправляемых запросов на сервер, при том, что он и без этого не справляется с обработкой! Это тупик.
Что касается "плохой связи" то я вообще не понял, о чём идёт речь. Если это глюки FF, требующие каких-то workaround на клиенте - один разговор. Если это те же последствия перегруженного сервера, только в профиль - см. предыдущий абзац: сервер чинить надо. На мой взгляд, "плохая связь" это либо проблемы у провайдера приводящие к сильным потерям пакетов, либо обрывы модема у клиента, либо другие подобные проблемы. В этих условиях любой софт будет работать нестабильно, и требование стабильной работы в этих условиях разумно только если Вы во-первых пишете достаточно критичный софт и во-вторых уверены что проблема "плохой связи" действительно актуальна для Ваших пользователей (что не является типовым случаем в наши дни).
Я пока так и не понял, существует ли реально проблема, которую действительно правильно решать ручной организацией очередей в клиенте.
это всё хорошо и правильно, в теории.
на практике, мне нужно написать стабильного клиента, который мог бы работать в условиях любой загрузки сервера. оптимизацией кода на сервере занимаются другие люди.
на практике, мне нужно написать стабильного клиента, который мог бы работать в условиях любой загрузки сервера. оптимизацией кода на сервере занимаются другие люди.
Вы внимательно прочитали то, что я писал про тупик? Если сервер перегружен, то никакими ухищрениями на клиенте эту проблему решить невозможно. Вы можете доказать обратное?
мне не нужно что-то доказывать или решать проблему перегруженности сервера. моё дело - оранизовать стабильную работу клиента, чтобы пользователь не впадал в панику при ошибках связи или медленной реакции сервера.
>Ведь это не UDP, HTTP бегает через TCP, а там есть ACK-пакеты.
Это HTTP, ответ приходит, но статус ответа не 200.
Это HTTP, ответ приходит, но статус ответа не 200.
т.е. вы организовали отправку сообщений по таймеру, а не сразу, как их сгенерирует какой-нибудь объект на странице.
опрос сервера на предмет сообщений был тоже по таймеру? тогда это уже не совсем тот аякс, что у меня. у меня аякс-объект получает параметры, линк, евенты onComplete, onError и делает запрос. когда приходит ответ, он вызывает onComplete или onError в случае ошибки.
я планирую ставить сообщения в очередь. если очередь пуста, то отправлять сразу. отправку следующего сообщения в очереди планирую сделать после получения положительного ответа на предыдущее сообщение. при возникновении ошибки думаю перепосылать его несколько раз.
потом возникает вопрос, что делать с сообщениями, которые послать не удалось - придётся как-либо отменять пользовательские действия на странице, по типу того, как это реализовано в gmail: "oops.. an error is occurred. please try again later"
т.е. в очереди сообщений регистрировать не только сообщения серверу, но и действия пользователя генерировавшие эти сообщения, с возможностью их отмены.
опрос сервера на предмет сообщений был тоже по таймеру? тогда это уже не совсем тот аякс, что у меня. у меня аякс-объект получает параметры, линк, евенты onComplete, onError и делает запрос. когда приходит ответ, он вызывает onComplete или onError в случае ошибки.
я планирую ставить сообщения в очередь. если очередь пуста, то отправлять сразу. отправку следующего сообщения в очереди планирую сделать после получения положительного ответа на предыдущее сообщение. при возникновении ошибки думаю перепосылать его несколько раз.
потом возникает вопрос, что делать с сообщениями, которые послать не удалось - придётся как-либо отменять пользовательские действия на странице, по типу того, как это реализовано в gmail: "oops.. an error is occurred. please try again later"
т.е. в очереди сообщений регистрировать не только сообщения серверу, но и действия пользователя генерировавшие эти сообщения, с возможностью их отмены.
Тормоза скорее связаны с серверной логикой. Или ошибочной реализацией самого интерфейса (отправка вместо одного двух запросов или чего подобного).
Вообще, Ajax призван наоборот разгрузить сервер, обновляя лишь часть данных а не полную страницу и как правило так и получается.
Со своей стороны могу предложить версию Ajax от Дмитрия Котерова в случае, если Вы работаете с 4 php, или же версию от mootools при работе с 5 веткой php. Вообще, есть довольно много решений, упрощающих работу с Ajax и делающих работу более кроссбраузерной.
Вообще, Ajax призван наоборот разгрузить сервер, обновляя лишь часть данных а не полную страницу и как правило так и получается.
Со своей стороны могу предложить версию Ajax от Дмитрия Котерова в случае, если Вы работаете с 4 php, или же версию от mootools при работе с 5 веткой php. Вообще, есть довольно много решений, упрощающих работу с Ajax и делающих работу более кроссбраузерной.
про проблемы с серверной логикой я знаю, над этими проблемами работают другие программисты. моя задача реализовать браузерного клиента так, чтобы ему были нипочём тормоза, чтобы он не выдавал ошибок при обрывах и задержках.
Мне кажется тут единственно, что можно порекомендовать - доработку серверной части. Если даже после доработки невозможно сделать быстрые серверные скрипты, то следует подумать над самим клиентским интерфейсом - возможно, потребуется разграничить некоторые действия, чтобы задачи на сервер отправлялись порционно, не нагружая сервер в полной мере.
А сделать клиента, которому нипочем тормоза - тут надо просто во время тормозов вставлять тетрис например или арканоид, чтобы чел не замечал :)
А сделать клиента, которому нипочем тормоза - тут надо просто во время тормозов вставлять тетрис например или арканоид, чтобы чел не замечал :)
В хабракат уберите, пожалуйста.
может просто коннект плохой до сервера?%)
А не надо было браться за серьезную работу до изучения предметной области, тем более что если вы веб-разработкой не занимались. Не надо было писать на этих тенологиях, не надо было брать этот веб-сервер. Надо было писать через тесты, надо было брать другую базу данных, брать учебники и их читать.
Теперь надо потихому спрыгнуть с проекта и попытаться сохранить отношения с заказчиком. И воспринимать историю как очень хороший опыт на котором учатся, а код выкинуть и никогда больше не открывать его.
Теперь надо потихому спрыгнуть с проекта и попытаться сохранить отношения с заказчиком. И воспринимать историю как очень хороший опыт на котором учатся, а код выкинуть и никогда больше не открывать его.
Ну начну "с упокоя" - коннект до сервера всегда плохой. И если у когот то хороший, то у другого юзера Инета он обязательно будет плохой. У него все может тормозить из-за этого, но должно работать.
Что касаемо "здравия".
1. Нагрузка на сервер. Это давно известный факт, что почти любое тестирование грузит сервер в десятки раз меньше, нежели реальная работа. Вызвано это в первую очередь тем, что при тестировании идет попадание в кеш. Тем более в описаной вами логике работе.
2. Насчет AJAX - сначало простое. Броузер высылает запросы на сервер в правильной последовательности. Но получает ответы от сервера асинхроно. При нагруженом сервере, слабом канале легко может 4-ый запрос прийти после 5-го. Т.е. прием ответов следующий 1 2 3 5 4 (числа говорят о номере при отправке). Не отправлять следующий запрос, пока не пришел ответ на предыдущий. Можно, но слишком напряжно для юзера. И черевато глюками в javascripte при нештатных ситуациях - ну сколько раз надо долбать по серверу и когда сообщать юзеру, что канал навернулся ичто будет в этом случае юзер далать и т.п.
Выход, менять логику так, что бы было неважно, в какой последовательности пришли ответы от сервера.
Примеры.
Поменяли ячейку, отправили ее на сервер. Получили ответ что на сервере сохранено и изменили всю ячейку в броузеру. Не получили ответ - сообщили юзеру, что не сохранено. ВСЕ - другие ячейки не касаемся.
Или - после изменения надо перерисовать график. Тогда после любого прихода ОТ СЕРВЕРА инфы о сохранении перерисовываем график (послыаем запрос на обновление фрайма с графиком).
3. Сбои аякса и сбор данных. Ну вы же прогер, а не скриптовик. Так нафига эти библиотеки AJAX?
ПРоще самому их написать. Два основных метода - вызов с сервера функции javascript делается через добавление в какой нить div нового javascript. Примерно так
var obstr='scrip_t_'+addr.slice(0,addr.indexOf('.'));
var addr1=addr.replace('.htm','-'+Math.random()+'.htm' );
if (g('div_'+obstr)==null) {g('divrunJS').innerHTML+='';};
g('div_'+obstr).innerHTML='.'+obstr+' ';
setTimeout(function()
{
var scr=g('div_'+obstr).getElementsByTagName('script')[0];
scr.language='javascript';
if(scr.setAttribute) scr.setAttribute('src',addr1); else scr.src=addr1;
}
,200);
Навешиваете свои проверки и забываете о глюках библиотек. Все уже в ваших руках (библиотеки удобны, когда вы можете сделать все внутри этих библиотек. Когда библиотека не удовлетворяет, то сразу пиши сам).
И второй способ - в iframe - используется что бы сохранить что то на сервер методом POST.
Конечно надо решить вопросы:
а) сбои при сохранении (т.е. как узнать о сбое).
б) Опера - что ни делай на сервере, но при одном имени файла, и разных query строках - для оперы это один файл в кеше. Лечится тем, что на сервер вызов идет в формате NAME-randon.js
в) Передача русских букв в query из явы. (в основном состыковка сервера с UTF внутри javascript).
г) проблем с одновременным запуском (не окончанием) двух запросв нет - javascript однопоточный. Только не надо глупить, например использовать один фрайм для нескольких сохранений.
д) битость ответов (и потеря ответов) - просто легко проверяете любую контрольную сумму. Но думаю, что процент битых ответов будет мал - проблема больше в другом, например в последовательности приема ответов или просто в потери ответов и отсутствия на это правильной реакции (я вообще предпочитаю что бы от этого не зависило, просто делаю так, что бы у юзера было ощущение, что кнопка не нажалась - к примеру, сохранение перед закрытием формы - закрываю форму только после получения ответа о сохранении инфы на сервере. Никаких месаг об ошибках вгоняющих юзера в ступор не надо.)
е) в случае необходимости все же проверять наличие ответа, просто одновремено с запросом ставьте таймер на 3 сек. По таймеру проверяйте, пришел ли ответ или нет. Если нет 0 то повтор запроса. Но логика работы должна быть такая, что бы повторный запрос не вызвал бы нифига плохого.
Да, при этом правильнее было бы в интерпретаторе на сервере сделать фугкцию, которая бы превращала любой html текст в javascript строку (там и апострофу, и слова scritp и т.п.).
В ИТОГЕ - вы пишите на javascript. Вам нужно в броузер вывести что нить с сервера. Вы просто пишите что то типа RunServerJavascriptFunction(имя файла=функции). И у вас эта функция выполняется в броузере у клиента. Без глюков с последовательностью и другой херней библиотек AJAX.
Да, если какая то Ля меня заминусует, то обязуюсь больше не писать на хабр.
Что касаемо "здравия".
1. Нагрузка на сервер. Это давно известный факт, что почти любое тестирование грузит сервер в десятки раз меньше, нежели реальная работа. Вызвано это в первую очередь тем, что при тестировании идет попадание в кеш. Тем более в описаной вами логике работе.
2. Насчет AJAX - сначало простое. Броузер высылает запросы на сервер в правильной последовательности. Но получает ответы от сервера асинхроно. При нагруженом сервере, слабом канале легко может 4-ый запрос прийти после 5-го. Т.е. прием ответов следующий 1 2 3 5 4 (числа говорят о номере при отправке). Не отправлять следующий запрос, пока не пришел ответ на предыдущий. Можно, но слишком напряжно для юзера. И черевато глюками в javascripte при нештатных ситуациях - ну сколько раз надо долбать по серверу и когда сообщать юзеру, что канал навернулся ичто будет в этом случае юзер далать и т.п.
Выход, менять логику так, что бы было неважно, в какой последовательности пришли ответы от сервера.
Примеры.
Поменяли ячейку, отправили ее на сервер. Получили ответ что на сервере сохранено и изменили всю ячейку в броузеру. Не получили ответ - сообщили юзеру, что не сохранено. ВСЕ - другие ячейки не касаемся.
Или - после изменения надо перерисовать график. Тогда после любого прихода ОТ СЕРВЕРА инфы о сохранении перерисовываем график (послыаем запрос на обновление фрайма с графиком).
3. Сбои аякса и сбор данных. Ну вы же прогер, а не скриптовик. Так нафига эти библиотеки AJAX?
ПРоще самому их написать. Два основных метода - вызов с сервера функции javascript делается через добавление в какой нить div нового javascript. Примерно так
var obstr='scrip_t_'+addr.slice(0,addr.indexOf('.'));
var addr1=addr.replace('.htm','-'+Math.random()+'.htm' );
if (g('div_'+obstr)==null) {g('divrunJS').innerHTML+='';};
g('div_'+obstr).innerHTML='.'+obstr+' ';
setTimeout(function()
{
var scr=g('div_'+obstr).getElementsByTagName('script')[0];
scr.language='javascript';
if(scr.setAttribute) scr.setAttribute('src',addr1); else scr.src=addr1;
}
,200);
Навешиваете свои проверки и забываете о глюках библиотек. Все уже в ваших руках (библиотеки удобны, когда вы можете сделать все внутри этих библиотек. Когда библиотека не удовлетворяет, то сразу пиши сам).
И второй способ - в iframe - используется что бы сохранить что то на сервер методом POST.
Конечно надо решить вопросы:
а) сбои при сохранении (т.е. как узнать о сбое).
б) Опера - что ни делай на сервере, но при одном имени файла, и разных query строках - для оперы это один файл в кеше. Лечится тем, что на сервер вызов идет в формате NAME-randon.js
в) Передача русских букв в query из явы. (в основном состыковка сервера с UTF внутри javascript).
г) проблем с одновременным запуском (не окончанием) двух запросв нет - javascript однопоточный. Только не надо глупить, например использовать один фрайм для нескольких сохранений.
д) битость ответов (и потеря ответов) - просто легко проверяете любую контрольную сумму. Но думаю, что процент битых ответов будет мал - проблема больше в другом, например в последовательности приема ответов или просто в потери ответов и отсутствия на это правильной реакции (я вообще предпочитаю что бы от этого не зависило, просто делаю так, что бы у юзера было ощущение, что кнопка не нажалась - к примеру, сохранение перед закрытием формы - закрываю форму только после получения ответа о сохранении инфы на сервере. Никаких месаг об ошибках вгоняющих юзера в ступор не надо.)
е) в случае необходимости все же проверять наличие ответа, просто одновремено с запросом ставьте таймер на 3 сек. По таймеру проверяйте, пришел ли ответ или нет. Если нет 0 то повтор запроса. Но логика работы должна быть такая, что бы повторный запрос не вызвал бы нифига плохого.
Да, при этом правильнее было бы в интерпретаторе на сервере сделать фугкцию, которая бы превращала любой html текст в javascript строку (там и апострофу, и слова scritp и т.п.).
В ИТОГЕ - вы пишите на javascript. Вам нужно в броузер вывести что нить с сервера. Вы просто пишите что то типа RunServerJavascriptFunction(имя файла=функции). И у вас эта функция выполняется в броузере у клиента. Без глюков с последовательностью и другой херней библиотек AJAX.
Да, если какая то Ля меня заминусует, то обязуюсь больше не писать на хабр.
частично согласен. никогда не понимал всеобщей истерии по поводу фреймворков. да, они снижают время разработки и упрощают жизнь, но влекут за собой появление массы недопрограммистов (раньше так было с CMS - любой, способный поставить phpNuke мнил себя веб-мастером). кроме того, имхо, использование фреймворков в high-load системах это смерть
Отвечаю сразу на два коммента (так как идиотская функция не дает мне писать два коммента в течении 5 минут)
2korchasa - вот имено, блокировать ячейки, пока не закончиться сохранения одной из них? Вы себе представляете это? Вы хотите блокировать работу пользователя, что бы не нагружать сервер! Это покруче, чем на хабре один коммент в 5 минут.
Переносить что то на клиента - гениальная идея. Вот только ни мне ни вам неизвестно, воможно ли это. А если неизвестно, то ценость совета нулевая.
2drone
Фреймворки - это фигня, хуже чем байсик в офисе у мелкомягких. И самое плохое то, что создается код, который можно будет выкинуть после смены фраймворка.
Но вы затронули интересный момент - развитие серверного ПО в России. Это же просто пипец - когда большинство серверов работаю на фришных скриптах и никто нифига не пишет сам. Конечно, большинство систем типа физитки фирмы должно работать на станддартном серверном софте. Но вот беда, что увы, кроме 10 сайтов (Яндекс, LI) все остальные не пишут ничего нового и интересного. И по этому параметру, РуНет в ж.опе планеты всей, что соответствует нормальному месту и в других отраслях промышлености. И после этого кто то будет говорит, что в РуНет деньги не идут к тем, кто прикрутил аж 10 скриптов, нагнал порнухи, накриутил счетчики и т.п.
Хотя Хабр в Хабре. И здесь все Гики, все на УНИХ и все минусуют (читай - затыкают) тех, кто не тащится от идиотизма симентатической верстки в три колонки.
2korchasa - вот имено, блокировать ячейки, пока не закончиться сохранения одной из них? Вы себе представляете это? Вы хотите блокировать работу пользователя, что бы не нагружать сервер! Это покруче, чем на хабре один коммент в 5 минут.
Переносить что то на клиента - гениальная идея. Вот только ни мне ни вам неизвестно, воможно ли это. А если неизвестно, то ценость совета нулевая.
2drone
Фреймворки - это фигня, хуже чем байсик в офисе у мелкомягких. И самое плохое то, что создается код, который можно будет выкинуть после смены фраймворка.
Но вы затронули интересный момент - развитие серверного ПО в России. Это же просто пипец - когда большинство серверов работаю на фришных скриптах и никто нифига не пишет сам. Конечно, большинство систем типа физитки фирмы должно работать на станддартном серверном софте. Но вот беда, что увы, кроме 10 сайтов (Яндекс, LI) все остальные не пишут ничего нового и интересного. И по этому параметру, РуНет в ж.опе планеты всей, что соответствует нормальному месту и в других отраслях промышлености. И после этого кто то будет говорит, что в РуНет деньги не идут к тем, кто прикрутил аж 10 скриптов, нагнал порнухи, накриутил счетчики и т.п.
Хотя Хабр в Хабре. И здесь все Гики, все на УНИХ и все минусуют (читай - затыкают) тех, кто не тащится от идиотизма симентатической верстки в три колонки.
Не стоит ставить себя в зависимость от всяких Ля :)
1. не совсем понял про кеш. при тестировании я каждый раз жму ctrl+r и отменил, где можно кеш, так как сперва мешала привычка браузера тянуть устаревшие версии файлов из кеша. да и обмен идёт в основном, через аякс.
2. очерёдность как раз важно, но логику всё равно придётся менять, чтобы просто не посылать ненужные запросы (2-5), пока не вернулся ответ на 1 в случае переключения фильтра, а потом послать 5. с ячейками придётся посылать каждый запрос в строгой очерёдности, так как от изменения одной ячейки зависят значения многих других ячеек (как видимых в данный момент на экране, так и невидимых, на нижних уровнях - например, имеешь табличку по годам, при изменении значения в 2007, меняются значения на нижнем уровне, для ноября и декабря)
3. не совсем понял про загружаемые функции с сервера, все фукнкции у меня находятся в js-файлах, которые я загружаю в самом начале. есть ещё вариант, чтобы переложить часть вычислений с сервера на клиент, но это уже дело следующего апгрейда системы (система разрабатывается уже больше года, заказчиком постоянно вносятся новые требования к функциональности, а начиналось всё с одной странички в экселе :))
вопросы:
б) Опера отпадает сразу, как и Firefox. У заказчика на всех компах установлен IE6 без возможности устанавливать сторонний софт. Это так и не обсуждается.
в) русского языка, слава богу, не предвидится
г) однопоточность javascript - сомнительный плюс, так как при синхронных запросах весь браузер, включая другие табы и вообще весь интерфейс замирает на несколько секунд, особенно firefox
Д) да, придётся проверять. "кнопка не нажалась" - плохой вариант. я думаю перепосылать потерянные или битые запросы.
е) с таймером сложнее, иногда время реакции составляет меньше секунды, иногда три минуты :) особенно если сохранение делать на самом верхнем уровне, когда приходится пересчитывать данные на нескольких уровнях ниже, а это может быть примерно 160х30х30 таких форм.
спасибо за подробный текст.
1. не совсем понял про кеш. при тестировании я каждый раз жму ctrl+r и отменил, где можно кеш, так как сперва мешала привычка браузера тянуть устаревшие версии файлов из кеша. да и обмен идёт в основном, через аякс.
2. очерёдность как раз важно, но логику всё равно придётся менять, чтобы просто не посылать ненужные запросы (2-5), пока не вернулся ответ на 1 в случае переключения фильтра, а потом послать 5. с ячейками придётся посылать каждый запрос в строгой очерёдности, так как от изменения одной ячейки зависят значения многих других ячеек (как видимых в данный момент на экране, так и невидимых, на нижних уровнях - например, имеешь табличку по годам, при изменении значения в 2007, меняются значения на нижнем уровне, для ноября и декабря)
3. не совсем понял про загружаемые функции с сервера, все фукнкции у меня находятся в js-файлах, которые я загружаю в самом начале. есть ещё вариант, чтобы переложить часть вычислений с сервера на клиент, но это уже дело следующего апгрейда системы (система разрабатывается уже больше года, заказчиком постоянно вносятся новые требования к функциональности, а начиналось всё с одной странички в экселе :))
вопросы:
б) Опера отпадает сразу, как и Firefox. У заказчика на всех компах установлен IE6 без возможности устанавливать сторонний софт. Это так и не обсуждается.
в) русского языка, слава богу, не предвидится
г) однопоточность javascript - сомнительный плюс, так как при синхронных запросах весь браузер, включая другие табы и вообще весь интерфейс замирает на несколько секунд, особенно firefox
Д) да, придётся проверять. "кнопка не нажалась" - плохой вариант. я думаю перепосылать потерянные или битые запросы.
е) с таймером сложнее, иногда время реакции составляет меньше секунды, иногда три минуты :) особенно если сохранение делать на самом верхнем уровне, когда приходится пересчитывать данные на нескольких уровнях ниже, а это может быть примерно 160х30х30 таких форм.
спасибо за подробный текст.
1. Я не о тестировани говорил. И Опере часто даже контрл Р не помогает. для Оперы 8 точно не помогает.
3. Я рассказал, как часть функций (особено если их неограниченое множесто) грузить сервера. Т.е. превратить прогерство на AJAX в прогерство на javascript. С С простотой javascript и возможностями ajax
---
б) и в) - не увидел вопроса.
г) однопоточность минус для работы, но упрощение при разработке своих решений, причем огромное. Вспомни синхронизацию и отладку поток в Дельфи.
Замирания не по этой причине. Броузер многопоточный. А вот выполнение javascript идет в один поток. ПРичем это не поток системы, а имено один поток javascript!
А ФФ вообще отстой. Особено если попробовать симентатически верстать. Стандарты стандартами, а вот когда идет что то спорное (неописаное в стандартах...) то ФФ ведет себя страно. Не говоря уже о висах. И на пустом месте и когда например жмешь ссылку с шифтом, то все копии ФФ замирают на 10-60 сек (если не удалял в последние 2 дня историю операций).
д) я имел ввиду нестандартное решение. Подробнее- просто надо изменить какое нить поле. Юзер жмет закрыть. Окно закрываешь когда пришел ответ о успешном сохранении. Если неуспешное сохранение, то юзер сам нажмет кнопку еще раз. (это не исключает автоматической перепосылки данных, но многие делают так - шлют три раза данные. при этом окно поле ввода с изменениями закрывают и юзер даже не может в буфер запихнуть набитый текст).
е) я говорил про таймер только как о проверке того, получен ли ответ с сервера или нет. Т.е. проверка ушла ли команда на сервер. Если пришел ответ, то таймер заканчивает работу. Если не пришел ответ, то таймер посторяет данные.
Таймер и перерисовку данных я не обсуждал совместно.
3. Я рассказал, как часть функций (особено если их неограниченое множесто) грузить сервера. Т.е. превратить прогерство на AJAX в прогерство на javascript. С С простотой javascript и возможностями ajax
---
б) и в) - не увидел вопроса.
г) однопоточность минус для работы, но упрощение при разработке своих решений, причем огромное. Вспомни синхронизацию и отладку поток в Дельфи.
Замирания не по этой причине. Броузер многопоточный. А вот выполнение javascript идет в один поток. ПРичем это не поток системы, а имено один поток javascript!
А ФФ вообще отстой. Особено если попробовать симентатически верстать. Стандарты стандартами, а вот когда идет что то спорное (неописаное в стандартах...) то ФФ ведет себя страно. Не говоря уже о висах. И на пустом месте и когда например жмешь ссылку с шифтом, то все копии ФФ замирают на 10-60 сек (если не удалял в последние 2 дня историю операций).
д) я имел ввиду нестандартное решение. Подробнее- просто надо изменить какое нить поле. Юзер жмет закрыть. Окно закрываешь когда пришел ответ о успешном сохранении. Если неуспешное сохранение, то юзер сам нажмет кнопку еще раз. (это не исключает автоматической перепосылки данных, но многие делают так - шлют три раза данные. при этом окно поле ввода с изменениями закрывают и юзер даже не может в буфер запихнуть набитый текст).
е) я говорил про таймер только как о проверке того, получен ли ответ с сервера или нет. Т.е. проверка ушла ли команда на сервер. Если пришел ответ, то таймер заканчивает работу. Если не пришел ответ, то таймер посторяет данные.
Таймер и перерисовку данных я не обсуждал совместно.
Народ. Может кто подскажет, как в standards-compliant mode получить scrollTop?
Или с эмулировать.
Т.е. надо вывести инфу в том месте длиной страницы, где сейчас находится пользователь. Как получить куда он страницу перемотал?
Или с эмулировать.
Т.е. надо вывести инфу в том месте длиной страницы, где сейчас находится пользователь. Как получить куда он страницу перемотал?
если doctype strict (не уверен), то можно вывести картинку по абсолютным экранным (а не страничным) координатам, будет не совсем там, куда пользователь отмотал страницу, но точно на экране поверх всего.
я так выводил разные системные сообщения
я так выводил разные системные сообщения
Я уже себе пообещал, что никаких стандартов симентатической верстки я не буду пытаться придерживаться на 100%. Буду делать так, как проще и как совместимее и как правильнее для решения задачи исходя из реальностей, а не идио...идеальных представлений. (а то достало на глазок определять сементатическую верстку - то там что то вылезло не туда, то там залезло, здесь явно хотели три колонки, но одна ушла вниз, то надо переключиться с ФФ на ИЕ, а то семантики намудрили так, что только ИЕ и берет)
Судя по всему прийдется взять за правило работать в режиме совместимости...
Судя по всему прийдется взять за правило работать в режиме совместимости...
Подумайте как работают ваши пользователи, и как у вас вычисления связаны друг с другом. И основываясь на этом уберите лишние обращения к серверу.
Бессмысленно, например, пересчитывать каждый раз сумму в столбце, если пользователь меняет одно из значений. Проще это сделать на стороне клиента (не такая уж тяжелая операция).
Если ваши вычисления зависят от нескольких ячеек, то можно, например, при после изменения одной из них, блокировать все остальные. Или реализовать паттерн Command и посылать все изменения таких ячеек скопом, по истечению определенного интервала после правки на одной из них.
Или проводить какие-то промежуточные вычисления, и изредка сравнивать "верхние" (контрольные) значения, если клиент насчитал неправильно.
Вариантов море, но тяжело что-то сказать конкретное из вашего описания приложения. Вместо рассказа о его судьбе, лучше бы функционал расписали, и персонажей обрисовали.
Бессмысленно, например, пересчитывать каждый раз сумму в столбце, если пользователь меняет одно из значений. Проще это сделать на стороне клиента (не такая уж тяжелая операция).
Если ваши вычисления зависят от нескольких ячеек, то можно, например, при после изменения одной из них, блокировать все остальные. Или реализовать паттерн Command и посылать все изменения таких ячеек скопом, по истечению определенного интервала после правки на одной из них.
Или проводить какие-то промежуточные вычисления, и изредка сравнивать "верхние" (контрольные) значения, если клиент насчитал неправильно.
Вариантов море, но тяжело что-то сказать конкретное из вашего описания приложения. Вместо рассказа о его судьбе, лучше бы функционал расписали, и персонажей обрисовали.
да, вы правы, часть вычислений нужно переносить на клиента, но это сложно, так как пересчёт идёт не только для видимых значений, но и на всех уровнях ниже, которые хранятся в базе, и на базе которых строятся графики. спрева нужно реализовать стабильную систему сообщения клиента с сервером.
ваши коментарии мне очень помогли.
спасибо.
ваши коментарии мне очень помогли.
спасибо.
Графики можно строить и на клиенте. Очень понравилась в свое время FusionCharts. Бесплатных высокого уровня когда искал (год назад) не нашел. Были какие-то наработки у какого-то JS-фреймворка (возможно YUI), на основе SVG, но подробностей уже не помню.
да, была идейка делать графики на флеше
Прежде чем вы потратите на flash/js charting заметное время я хочу поделиться своим опытом - недавно проводил исследования (по работе) и в результате выяснил что применимость их очень ограничена, т.к все эти решения очень сильно загружают браузер и уже при паре сотен значений в серии практически невозможно работать с регулярными обновлениями. По крайней мере это так с готовыми (и коммерческими и опен сорс) библиотеками. В общем дальше демок всё плохо. Так же типичны проблемы с кастомизацией внешнего вида.
Кстати если у кого-то есть реальный положительный опыт использования какого-либо готового инструментария - большая просьба поделиться.
Кстати если у кого-то есть реальный положительный опыт использования какого-либо готового инструментария - большая просьба поделиться.
http://extjs.com/deploy/dev/examples/grid/edit-grid.html
Извите за прямоту, сильно не пинайте.
Но по мне аякс нужно использовать для связи с бд, т.е. серверная часть должна уметь только выбирать, обновлять, вставлять и удалить данные из бд. Если реализовать все эти функции правильно, то нагрузка на сервер будет минимальная.
По поводу графиков, мне кажется как то не рационально перестараивать все графики сразу при изменении. Если условие что допустим с данными работает 10 человек одновременно, получается что при каждом сохранении ячейки перестраивается график... Часный случай которого может никогда и не возникнет это все 10 клиентов одновременно нажмут сохранить. Упростим все и будем считать что запрос и обработка займет 1 секунду, т.е. в нашем случае получится что сервер 10 раз перестроит график. Вопрос а для чего? Когда можно раз в эту же секунду просто запускать скрипт генерации графика, получается что сервер будет не будет делать одну и туже работу 10 раз а сделает однократно.
Это моё личное мнение которого я придерживаюсь. Я пишу сайты именно так. Сервер работает с БД все остальное делает клиентская часть.
Но по мне аякс нужно использовать для связи с бд, т.е. серверная часть должна уметь только выбирать, обновлять, вставлять и удалить данные из бд. Если реализовать все эти функции правильно, то нагрузка на сервер будет минимальная.
По поводу графиков, мне кажется как то не рационально перестараивать все графики сразу при изменении. Если условие что допустим с данными работает 10 человек одновременно, получается что при каждом сохранении ячейки перестраивается график... Часный случай которого может никогда и не возникнет это все 10 клиентов одновременно нажмут сохранить. Упростим все и будем считать что запрос и обработка займет 1 секунду, т.е. в нашем случае получится что сервер 10 раз перестроит график. Вопрос а для чего? Когда можно раз в эту же секунду просто запускать скрипт генерации графика, получается что сервер будет не будет делать одну и туже работу 10 раз а сделает однократно.
Это моё личное мнение которого я придерживаюсь. Я пишу сайты именно так. Сервер работает с БД все остальное делает клиентская часть.
серверную часть разрабатывают примерно полтора года, вся логика там реализована давно и уже практически отлажена.
понадобилось прикрутить аякс-морду, чтобы не перезагружать страницу после каждого изменения. переводить всю логику с сервера на клиент - это ещё месяца три работы.
графики перестраиваются опционально, но можно считать, что при каждом изменении, так как клиент хочет видеть изменения сразу, как в екселе. графики грузятся браузером в отдельном iframe, на аякс никак не влияют.
каждому клиенту сервер показывает свой вариант графиков, так как каждый клиент, скорее всего, будет работать со своей частью данных. клиенты работают независимо друг от друга. соприкасаются только если начинают редактировать данные по одному отделу, или подотделу. но конфликтов быть не должно, на сервере предусмотрена блокировка отдельных "файлов", "папок" и "подпапок", назову их так.
понадобилось прикрутить аякс-морду, чтобы не перезагружать страницу после каждого изменения. переводить всю логику с сервера на клиент - это ещё месяца три работы.
графики перестраиваются опционально, но можно считать, что при каждом изменении, так как клиент хочет видеть изменения сразу, как в екселе. графики грузятся браузером в отдельном iframe, на аякс никак не влияют.
каждому клиенту сервер показывает свой вариант графиков, так как каждый клиент, скорее всего, будет работать со своей частью данных. клиенты работают независимо друг от друга. соприкасаются только если начинают редактировать данные по одному отделу, или подотделу. но конфликтов быть не должно, на сервере предусмотрена блокировка отдельных "файлов", "папок" и "подпапок", назову их так.
Посмотрите в сторону паттерна Observer.
1) сделайте айди каждого обращения к серверу
2) серверный скрипт пусть регистрирует действие и возвращает что-то типа ОК, транзакция поставлена в очередь (например, текстом). На примитивном уровне (например, через shared memory) проследите за загрузкой сервера в даный момент и ждите пока ресурсы освободятся для дальнейшей обработки.
3) по таймауту аяксом делайте запрос к серверному скрипту на предмет выполнения и если транзакция завершена - забирайте результат (т.е. сервер отдает вам данные только в случае 100% гарантии его выполнения)
4) серверный скрипт удаляет результат транзакции из сессии/бд/шаред мемори где хранит результат вычислений до вашего запроса
технически я описал практическую реализацию в вашем случае, подробней о паттерне здесь
http://en.wikipedia.org/wiki/Observer_pattern
Все вышеописанное можно реализовать без особых заморочек, но с точки зрения проектирования приложения такой ситуации не должно было возникнуть. Т.е. пусть программист серверной части оптимизирует свои скрипты.
1) сделайте айди каждого обращения к серверу
2) серверный скрипт пусть регистрирует действие и возвращает что-то типа ОК, транзакция поставлена в очередь (например, текстом). На примитивном уровне (например, через shared memory) проследите за загрузкой сервера в даный момент и ждите пока ресурсы освободятся для дальнейшей обработки.
3) по таймауту аяксом делайте запрос к серверному скрипту на предмет выполнения и если транзакция завершена - забирайте результат (т.е. сервер отдает вам данные только в случае 100% гарантии его выполнения)
4) серверный скрипт удаляет результат транзакции из сессии/бд/шаред мемори где хранит результат вычислений до вашего запроса
технически я описал практическую реализацию в вашем случае, подробней о паттерне здесь
http://en.wikipedia.org/wiki/Observer_pattern
Все вышеописанное можно реализовать без особых заморочек, но с точки зрения проектирования приложения такой ситуации не должно было возникнуть. Т.е. пусть программист серверной части оптимизирует свои скрипты.
В первую очередь - тюнинг вебсервера и установка реверс прокси, если этого еще не сделано.
отсутствие опыта программирования интерфейсов сказывается.
всё у вас получится, только нужно немного времени (-:
всё у вас получится, только нужно немного времени (-:
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
AJAX: проблемы стабильности и надёжности при большой нагрузке на сервер