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?
None.
Maybe you're just super far from where the host server is located.
None.
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.
None.
Magic box god; Suck it Corbo
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.
Please report errors in the Staredit.Network forum.
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.
None.
I order you to forgive yourself!
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.
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
)
Exactly, that's why I was so baffled by this ridiculous slowdown. But considering IP...
*shudders*
None.
Relatively ancient and inactive
This was discussed before and the same potential problem was thought up. Since it wasn't fixed, I assume that isn't it.
None.
.... 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.
Please report errors in the Staredit.Network forum.
I order you to forgive yourself!
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)
I do stuff and thingies... Try widening and reducing the number of small nooks and crannies to correct the problem.
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.
.... 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.
Not only that, but I believe MySQL uses Hash Tables, which brings the search time to practically nil, compared with others
None.
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
None.
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.
Please report errors in the Staredit.Network forum.