Печально. Попробуте все же погонять на виртуалке с одним ядном, минимумом памати и подобным софтовым набором. Не исключено что тормозить тоже не будет. Я не замечал большого оверхеда на хранении списков и высоких накладных расходов по доступу к элементам в JS. А вот всякие попытки упаковки/распаковки для минимизации объема харнимых данных однозначно увеличат расходы на доступ к элементам при сомнительном выигрыше с объеме хранения.
Ой не знаю, не знаю. Это гейзенбаг какой-то. У меня как только открываю FB чтобы посмотреть почему комент не уходит он тут-же исчезает. Т.е. при открытой панели FB я его не наблюдаю. Но когда, решив что все ок, firebug закрывается баг недетерминированно возвращается. До следующей попытки выяснить в чем дело.
N.B.: в Home Basic больше 8Gb RAM не напыжевать. И если для бухгалтера/секретарши это не имеет значения, то все равно следует об этом помнить. Мало-ли, вдруг программистам больше понадобится.
А нет, погуглил — две точки нужны, но так как сказал alexxxst.
Теперь про то что где-то это не работает. А какой длинны ответ с куками возвращается? Не навешиваете ли вы их одновременно с редиректом?
А попробуйте добавить точку в конце. Сейчас уже не вспомню откуда в голове крутится эдакое «правило двух точек», но почем-то кажется что для печенек между двумя доменами обязательно наличие именно двух точек. При чем добавление точки в начало делает печеньку доступной только для субдоменов, но не основного. а вот в конце, должно сделать ее доступной для всех. Типа «site.ru.»… возможно это бред, но кажется меня это когда-то выручило, возможно с тех пор и поселился этот бред в голове.
Настоятельно советую раздобыть книгу по MS SQL и тщательно изучить вопросы индексов и хранения данных в соотвутствующих версиях. Производительность вставок и чтений может очень сильно зависеть не только от того какие индексы построены но и от того как они построены и как хранятся данные. Т.е. и просто индексы могут сильно вам помочь, но если сделать все правильно (а рычагов за которые можно «покрутить» там достаточно) то можно получить гораздо больше.
www.notebookcheck-ru.com/Obzor-noutbuka-Dell-Vostro-3750.54763.0.html
Вот, обзор нашел. Тоже на монитор кивают. Хотя если сравнисть с v13 то они почи одинаковые. Сказать чтобы разница в засветке была особо заметна не могу, ни жену ни меня при серфинге и работе с документами не раздражает. Про фотошоп не скажу, он на нем не запускался. Но вам оно вроде и не к чему. судя по заявленым задачам.
Мне он понравился аллюмниевым корпусом, который очень похож на v13 моей жены. Теоретически должен лучше отводить тепло и, соответсвенно, меньше греться. По железу он тоже очень даже ничего. В указанные вами рамки можно попробовать всунуть модель с i7 на борту, что весьма приятно.
>Как сейчас?
Брал dv7-3110er, как раз за примерно такую сумму как вы указали. Год было все нормально, затем сдохла батарея, а сейчас и все USB вылетели. Я HP больше не куплю. :/
Ах да. В интернетах пишут, что у них тоже возможны неравномерности подсветки. К сожалению в магазине я такой не нашел чтобы пощупать, поэтому если эта модель заинтересует, имейте в виду — обязательно посмотреть на него вживую, вдруг разонравится.
Вот черт, ерунда какая-то запостилась. o_0
А вообще хотел спросить есть ли какие подвижки? Какой скорости удалось добиться через EF? Какие результаты показывает мой вариант в вашем окружении?
У меня канал через stunnel переживал короткие разрывы, хотя утвердать не буду, может мне так только казалось. Еще замечал, что неплохо переживают разрывы соединения через openvpn (через UDP), когда физически канал падал, но тунель еще какое-то время выглядел «живым». Если за это время канал возвращался, соединения не обрывались. Может действительно попрбуйте, как советуют ниже, завернуть соедиение в UDP? Хотя бы посредством того-же openvpn…
Только что проверил, открыл в putty сессию с сервером через openvpn, запустил top. Отрубил WiFi, подождал пару секунд, включил WiFi. Сессию не порвало, хотя putty обычно очень болезненно на обрывы реагирует. Правда живет он до ~10секунд, потом все-таки отваливается с network error, видимо таймауты такой метод не отменяет :(
как-то так pastebin.com/QDRSu2X1
перед выкладной специально проверил транзакции. Если рожать по транзакции на каждую строку, то получается ~3сек/1000 строк.
Поиграл с настройками соединения. Существенное (x10) замедление наблюдается если запретить pooling соединений. Если разрешить использовать пулл коннектов, то даже закрыте конекта после вставки каждой строки замедляет всего в 1.5 раза. А вот если запретить пул и на каждую строку использовать новое подключение получается 4.2 сек на 1000 строк. Не так плачевно как у Вас, но все-же.
З.Ы.: а загляните-ка в базу, покажите CREATE statement для таблицы. Может EF чего жуткого накрутил?
В memory/heap 1000 строк пихается за 0.25-0.3сек. Заподозрил, было, неладное с MyISAM, думал 1000 строк на диск не сбрасывается, или еще что (уж больно к MEMORY результаты близкие), но 10k строк успешно пыжует за 3.5-3.7сек.
Ой, не знаю, не знаю. Специально проверил. Через банальный MySqlCommand у меня 1000 2двухкилобайтных строк вставляется 0.42сек. MySql пришлось качать и ставить на ноут. В визарде сказал что машинка девелоперская, как следствие настройки оно предложило скромные.
Mysql 5.5.16 + .Net Connector 6.4.3 движок таблицы MyISAM.
Win7 x64 @ i7-Q720, 4Gb RAM
P.S.: в нетюниговыный INNODB при прочих равных вставка 1000 строк занимает 2.42сек.
