I am attempting to import 1,477 pages. The import is hanging.I've been debugging for hours. Here's what I know --I was getting the JS pop-up on the import page saying the server stopped responding. So, I disabled this in ImportPage.aspx by pushing out the JS timer value.After this, the page just stopped responding at a certain point. The page just freezes.The page on which it hangs is always different. It usually happens around page 100 (though, once it got to 300+).This same import file works on another installation, so I believe the import file is fine. I have reduced the import to just pages -- I imported the page types and categories separately, so there are no dependencies.There is nothing on the event log of the server on which the install is running.I set up logging on the server. It appears to show that the thread just hangs. The last thing I see is a call to the "editSavePageVersionData" stored proc to save some page to the database. Then no more log entries with that thread appear in the log. Other threads continue logging fine.The log also confirms that the import fails on a different page each time.I'm starting to suspect that the problem isn't with EPiServer, and rather something is wrong with the SQL Server. It seems odd that the thread would just die like that, and it always seems to die right after a call to this stored proc. (However, the EPiServer install continues to respond. It I open another browser tab, I can bring up Edit Mode just fine.)Could it be that the relentless SQL I/O of an import is revealing an underlying SQL problem? (I've noticed that this import runs much slower than the dev install on my local laptop, and this is running on a "true" server with a remote SQL instance. It should be faster.)Are there any other diagnostics I can run here? Or have I tapped out my options?My only other way to get this imported is to break up the import into smaller imports, but if I'm only getting 100 out of 1,477 in, I'm going to need to find a way to break it up into 15-ish smaller imports without any overlap and make sure they piece together correctly when I'm done.
Hm. Lots of things that can go haywire.
Weird problems always seem to be network related. It could be that the network that is the bottleneck since it actually works better on your dev-machine. You might be running out of available connections to your SQL machine. So fire up your network monitoring tool of choice.
I doubt it's the stored procedure since the thread simply stops responding. But you could always head into SQL Mordor with Management Studio and see if/how/why the SP breaks.