In the time it took me to log into SEN I managed to install four applications and crack one. Why does SEN take a whole three minutes to process my login request?

I only get long logins when I have cleared all of my browsing history.

Maybe you're just super far from where the host server is located.

I really don't think the problem has to do with distance to SEN. Pages load instantly for me after I have logged in, it's just the process of actually logging in that seems to cause SEN to become unloadable for an intolerable amount of time.

Once you are logged in there is no lag, Its just the log in process that does that. i don't know why it happens but once you set it to permanent log in the site doesn't lag at all. I have the same problem but an interesting thing is if you click on a link to another page on the site you will jump there logged in. Its one way so work around the log in time.

It's a known bug already, yet I'm not sure what causes it, especially as it is rather random: some do lag, some don't.

If by some draconian block of terrible code it's iterating through each member starting with mid=1, a member with high ID could take a long time to log in while someone like DTBK with a 2-digit ID would require less than 1/100ths as many SQL queries. I highly doubt that retrieving a member ID given name would be implemented this poorly, but it's a potential cause.

AFAIK, you can just search the username with only one SQL query. (I hope that's how it's done ) People like me would take 5006 query just to log in.

Exactly, that's why I was so baffled by this ridiculous slowdown. But considering IP...

*shudders*

This was discussed before and the same potential problem was thought up. Since it wasn't fixed, I assume that isn't it.

.... seriously.
The high member id got absolutely nothing to do with the lag. SELECT * FROM table_name WHERE name={$_POST['name']}. Similar to this, SEN's fetching for login is coded. As you can see, the ID has nothing to do with it.

And "considering IP..."... dude, you are not even long enough here to know him or his coding for real, lol.

That was supposed to be a compliment

Edit:
Also, just to clarify, the lag could have been caused by a loop going through all the members IDs one after the other and verify the username which would have caused the page to take a way longer loading time for members with a higher ID.

Post has been edited 1 time(s), last time on Aug 18 2010, 5:31 pm by Apos.

There is no ridiculous code for looking up which member is logging in.
The slow-down stems to be security-related and anti-proxy measures and was on IP's personal to-do list. (and I don't intend on touching it because he would understand it way better than me in addition to having coded it himself)

Perfect fix: stay logged in.

Oh, and can you remember the time when people somehow logged in as another persons and post in their name?
Be happy that isn't the case anymore.

Not only that, but I believe MySQL uses Hash Tables, which brings the search time to practically nil, compared with others

You're not alone.
http://www.staredit.net/topic/11908/0/

Ah now I remember, I even posted in that topic, too. Silly me.

On a separate note:




...is what happens when I try viewing SEN. The site is functional in this state, but still, really?

EDIT> Seems like this was temporary, the site is back to normal now. What did you guys do? O.o

It's called CSS. When uploading a new CSS the old one gets removed and then the new one gets uploaded, when you load SEN in exactly that time you get these errors, it's the same with PHP.